Re: [cups-devel] FYI: duplex not working ("Transport endpoint is not connected")

Martin,

My guess is that this is a bug in Qt or Chrome, although we've had no other reports of it.  The only time the CUPS APIs will try to connect directly to the device-uri for the PPD is for CUPS-shared printers that have no local PPD...


> On Jan 12, 2018, at 9:51 AM, Martin Vogt <[email protected]> wrote:
> 
> 
> Hello,
> 
> this is a follow up to an older thread:
> 
> https://lists.cups.org/pipermail/cups/2016-January/027429.html
> https://lists.cups.org/pipermail/cups/2016-February/027491.html
> 
> 
> With a new cups server and RHEL7 clients
> the problem above was still present.
> 
> - in google-chrome (cannot print in color, no ppds)
> - QT/KDE 4.x (slow startup time, no ppds)
> 
> The solution was to configure on the cups server NOT
> 
> - ipp://mfp6030.printer.domain.com:631
> 
> but
> 
> - socket://mfp6030.printer.domain.com:9100
> 
> with this the client does not:
> 
> - tries to connect the printer directly
> - does not run into a network problem (timeout)
> 
> ==> problem solved.
> 
> Additionally the qt/chrome client somehow gets a working ppd and
> works as expected.
> 
> In short: Don't use ipp:// to print from the server to an
> internal printer, only use socket://.
> 
> Is this a bug?
> Maybe in Qt/chrome?
> 
> regards,
> 
> Martin
> 
> 
> _______________________________________________
> cups-devel mailing list
> [email protected]
> https://lists.cups.org/mailman/listinfo/cups-devel

_________________________________________________________
Michael Sweet, Senior Printing System Engineer