[cups.bugs] [MOD] STR #3033: CUPS library function hang on unreachable IPP printer

Till Kamppeter till.kamppeter at gmail.com
Sat Dec 6 04:07:02 PST 2008


DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

The problem occurs in the following use case:

A user has a printer connected to his office PC and the printer has a CUPS
queue. He does not use the CUPS broadcasting facilities so that his
co-workers do not see the printer in their dialogs.

On his laptop he wants to print, too. So he creates a raw IPP queue
pointing to the printer on his PC:

lpadmin -p Laser -E -v ipp://192.168.1.100:631/printers/Laser

He sets up this queue as raw queue, so that the jobs get rendered on the
PC and the options of the PPD on his PC get shown in print dialogs on the
laptop. He sets the IPP queue as default.

Now our user travels to another place and wants to print there, for
example on a printer broadcasted by the CUPS server there. In the other
office the devices have 10.0.0.x IP addresses. Now he chooses the "Print"
function in an application and the application does not open the print
dialog but hangs.

This is due to the print dialog trying to get the properties of the
default printer (the PPD) from the remote CUPS server. As in the other
network the IP 192.168.1.100 does not exist, the appropriate CUPS library
function waits for an answer and makes the application hang for a rather
long timeout time.

To show that it is really CUPS and not the dialog, one can easily
reproduce the situation with CUPS on the command line:

1. Create a raw IPP queue to a non-existing IP:

lpadmin -p Laser -E -v ipp://192.168.123.234:631/printers/Laser

2. Try to get the options for this printer listed

lpoptions -p Laser -l

This command will hang for more than a minute.

Here the library function should do the request in a sub-process or it
should return with a rather short timeout. Or one should give the
possibility to let the library request the information in the background
and cache it and when one does the same request later and the information
arrived (or the timeout expired) one will get the information (or an
error).

Link: http://www.cups.org/str.php?L3033
Version: 1.3.9





More information about the cups-devel mailing list