GNOME Bugzilla – Bug 429845
gnome-print sees but won't print to network printer
Last modified: 2009-06-12 14:29:13 UTC
Please describe the problem: This is Ubuntu Feisty 7.04 beta clean install. Two printers installed, one local and one network via SMB to windows XP box. gtk-demo and other gnome applications can see and print to the local printer. Network printer appears in dialog box, but 'Print' button is grayed out. Printing works ok with other apps, such as gimp, firefox, and OOo. Steps to reproduce: 1. Configure as above 2. gtk-demo 3. Select network printer from the list. You will see Print button greyed out. Select local printer, Print will be enabled. Actual results: Can't print. Expected results: Prints. Does this happen every time? Yes. Other information: Same configure worked fine in 6.10 Edgy. Something has changed.
Moving all gnome-cups-manager bugs to new product. Filter on Kjartan's spring cleaning.
Created attachment 111695 [details] Usable printer is greyed out, so it cannot be selected
Created attachment 111696 [details] Using LPR printing is fine.
Created attachment 111697 [details] CUPS setup is fine.
Created attachment 111698 [details] CUPS see the printer alright.
Created attachment 111699 [details] Openoffice sees the printer fine. Printing works (including duplex).
Created attachment 111700 [details] Firefox sees the printer fine.
I have the same problem (Gnome 2.22.2, FreeBSD). Printing works from LPR, but doesn't from a network printer. Please see the attachments above, particularly #2 (Usable printer is greyed out).
I'm seeing this as well with Debian Lenny and Sid boxes. The most frustrating thing is that the button is greyed out, but there is no indication as to why it is disabled.
Is everyone seeing this problem using IP6 perchance? And is everyone having this issue via CUPS? (ie, Speak up if you're on an IP4 only system or if you're having this problem and don't use CUPS.)
I'm seeing the following line in my CUPS log (/var/log/cups/error_log) every time I select a printer that has a greyed out "Print" button: --------------------------------------------------------------------- W [20/Apr/2009:12:08:57 -0400] Request from "localhost" using invalid Host: field "::1" --------------------------------------------------------------------- That's with "LogLevel Info"; "LogLevel debug" gives a little more information: --------------------------------------------------------------------- D [20/Apr/2009:12:08:57 -0400] cupsdAcceptClient: 11 from localhost:631 (IPv6) D [20/Apr/2009:12:08:57 -0400] cupsdReadClient: 11 GET /printers/ricoh_aficio_2035e.ppd HTTP/1.1 D [20/Apr/2009:12:08:57 -0400] cupsdAuthorize: No authentication data provided. W [20/Apr/2009:12:08:57 -0400] Request from "localhost" using invalid Host: field "::1" D [20/Apr/2009:12:08:57 -0400] cupsdSendError: 11 code=400 (Bad Request) D [20/Apr/2009:12:08:57 -0400] cupsdCloseClient: 11 --------------------------------------------------------------------- You can ignore the "No authentication data provided" I'm pretty sure. The transaction before is getting the list of printers and it works just fine even with that same line.
Okay, I think I may have found a hack to fix this. I added the line: --------------------------------------------------- HostNameLookups Double --------------------------------------------------- to my /etc/cups/cupsd.conf near the top (after my "LogLevel" line). This tells cups to do a reverse lookup and to make sure it's not an invalid hostname. http://www.cups.org/doc-1.1/sam.html#HostNameLookups By default this is set to "Off", for performance reasons. Setting it to "On" would probably work as well as I think just the conversion from "::1" to "localhost" is what's fixing it, but "Double" is probably a little more secure from spoofing, etc. I don't know if this is a GTK bug (is it being sent wrong?) or if it's a CUPS bug (should CUPS handle the "::1" better?).... I'm also curious if this is just the fix for me, or if it's the fix for everyone who had the problem. P.S. I'm running CUPS 1.3.10.
I reported an upstream bug, they say the ip6 loopback string is invalid and marked the bug "WONT FIX". http://www.cups.org/str.php?L3162 They say that the RFC says "::1" is not the proper loopback and it should be "[::1]" instead.
::1 is a perfectly fine ipv6 address. The fact that it needs to be used as [::1] in urls and http headers is a different matter. We need to figure out how the ::1 ends up in the http request that is rejected by cups.
> We need to figure out how the ::1 ends up in the http request that is > rejected by cups. **Sigh.** I was hoping you knew.
Found the cause, it's httpSeparateURI from CUPS: http://cups.org/str.php?L3164 cups_request_printer_list_cb() at gtkprintbackendcups.c:1324 calls that with a valid URL like "ipp://[::1]:631/printers/foo" and will receive a host name like "::1" in return. It will simply pass that name to httpConnectEncrypt() where it will be stored as the host name, causing the problematic header to be set upon the next invocation of httpClearFields.
Hmm, time to reopen the cups bug :-) Of course, we should work around it in our code too...
Good find Martin!
(In reply to comment #17) > Of course, we should work around it in our code too... Upstream writes (in http://www.cups.org/str.php?L3164): The GNOME folks should NOT be reconnecting to spool directly to the server reported in the printer-uri-supported attribute - all jobs can and should go through the local server. So that's probably the direction to take, in order to use CUPS as its devs meant it to be used, and avoid future trouble.
(In reply to comment #12) > Okay, I think I may have found a hack to fix this. > > I added the line: > > --------------------------------------------------- > HostNameLookups Double > --------------------------------------------------- > > to my /etc/cups/cupsd.conf near the top (after my "LogLevel" line). > > This tells cups to do a reverse lookup and to make sure it's not an invalid > hostname. > > http://www.cups.org/doc-1.1/sam.html#HostNameLookups > > By default this is set to "Off", for performance reasons. Setting it to "On" > would probably work as well as I think just the conversion from "::1" to > "localhost" is what's fixing it, but "Double" is probably a little more secure > from spoofing, etc. > > > I don't know if this is a GTK bug (is it being sent wrong?) or if it's a CUPS > bug (should CUPS handle the "::1" better?).... I'm also curious if this is > just the fix for me, or if it's the fix for everyone who had the problem. > > > P.S. I'm running CUPS 1.3.10. > Wow, that fixed my problem. All apps could print to my remote printer except GTK apps, where the print button was greyed out. HostNameLookups Double fixed it.
I'm not sure what was fixed but in 2.26.2 this issue is fixed for me. Yay! As far as I am concerned, this bug can be closed. Note I did not edit cupsd.conf as mentioned in Comment#12.
If this bug report here is closed, a new report should be created to track the issue from comment #19. Unless someone believes that has been addressed as well, and can point out the changeset which fixed this. I don't think it has been taken care of yet.
thanks for letting us know
(In reply to comment #22) > If this bug report here is closed, a new report should be created to track the > issue from comment #19. Filed bug #585565 for this.