Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUPS library function hang on unreachable IPP printer #3033

Closed
michaelrsweet opened this issue Dec 6, 2008 · 3 comments
Closed

CUPS library function hang on unreachable IPP printer #3033

michaelrsweet opened this issue Dec 6, 2008 · 3 comments

Comments

@michaelrsweet
Copy link
Collaborator

@michaelrsweet michaelrsweet commented Dec 6, 2008

Version: 1.3.9
CUPS.org User: till.kamppeter

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

  1. 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).

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Dec 6, 2008

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Dec 6, 2008

CUPS.org User: till.kamppeter

Also system-config-printer:
https://fedorahosted.org/system-config-printer/ticket/117

The CUPS web interface also tries to directly access the printer's non-existent IP if one clicks on "Set printer options" on the printer management page. Here one can click the browser's "Stop" button, but a quickly appearing error message would be better.

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Dec 6, 2008

CUPS.org User: mike

This is the 5 minute TCP/IP connect timeout.

Not to be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant