Created attachment 474835 [details] 0:21 video showing eog failing to find printer 'hp' Description of problem: Not clear what to file this against. The problem shows up in all gtk print panels: eog, evince, thunderbird, mozilla, evince. It shows up on dual-stacked machines (IPv4 and IPv6 addresses) but does not show up on IPv4-only machines. Otherwise, printing "works" The ipp server is FC4 (yep, it's that old) and manages a NetGear P110 with an HP 965c attached to it. All that is working and has been working for ... years. What isn't working is the gtk print dialog on the new IPv6 dual-stacked machines. Version-Release number of selected component (if applicable): $ rpm -q eog eog-2.30.1-3.fc13.i686 We can figure out what other versions are here later once we figure out what component to assign this to. I can exhibit the problem with eog on any image. How reproducible: 100% Steps to Reproduce: 1. eog file.png 2. File->Print 3. see that "Getting printer information failed" for printer "hp" Actual results: shown nearby Expected results: Being able to "see" and use printer "hp" Additional info: I have three machines configured as follows status OS configuration name fails F13 IPv4+IPv6 suffragette fails F14 IPv4+IPv6 primrose works F13 IPv4 robot-hand The ipp server is FC4 (ancient) Of interest here is robot-hand which shows that my site-level printing in CUPS "works" as it has traditionally. We exhibited being able to "see" the printer named 'hp' from within gimp. The command-line variant date | lpr -Php functions on all three machines Log rotation happened last night so all the cups log files are "fresh". After an exhibition of the problem, they are still empty. $ for i in /var/log/cups/*log ; do echo $i ------------ ; sudo ls -alsd $i; sudo cat $i ; done /var/log/cups/access_log ------------ 0 -rw-------. 1 root lp 0 Jan 23 03:51 /var/log/cups/access_log /var/log/cups/cups-pdf_log ------------ 0 -rw-------. 1 root lp 0 Dec 4 03:23 /var/log/cups/cups-pdf_log /var/log/cups/error_log ------------ 0 -rw-------. 1 root lp 0 Jan 18 03:25 /var/log/cups/error_log /var/log/cups/page_log ------------ 0 -rw-------. 1 root lp 0 Jan 23 03:51 /var/log/cups/page_log ~/.xsession-errors contains nothing of interest pertaining to this incident. /var/log/messages contains nothing of interest pertaining to this incident. I exhibit the iptables nearby. This "used to work" back when I didn't have IPv6 addresses bound to this machine. There's a clue in there somewhere. printers.emerson.baker.org is FC4 and has been the print server ... since the FC4 days. However, it too was tagged by radvd with IPv6 (as expected), so I had to use DNS tricks to get "printers.example.com" to show up in IPv4 only Showing that printers->CNAME->splat $ host printers | perl -ple "s/$(hostname -d)/example.com/g" printers.sanguine.example.com is an alias for v4.splat.sanguine.example.com. v4.splat.sanguine.example.com has address 192.168.0.62 v4.splat.sanguine.example.com has address 192.168.1.7 $ host splat.emerson.baker.org | perl -ple "s/$(hostname -d)/example.com/g" splat.example.com has address 192.168.0.62 splat.example.com has address 192.168.1.7 splat.example.com has IPv6 address 2001:55c:4c15:7096:a00:46ff:fe05:d9a4 I can "see" the ipp broadcasts and that's why I can see the 'hp' printer. There are two subnets "sanguine" and "freerange" that are on the same wire here. $ sudo tcpdump -i eth0 'port ipp' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:49:10.006081 IP splat.sanguine.example.com.ipp > broadcast.sanguine.example.com.ipp: UDP, length 166 08:49:10.006296 IP splat.freerange.example.com.ipp > broadcast.freerange.example.com.ipp: UDP, length 166 08:49:41.228491 IP splat.sanguine.example.com.ipp > broadcast.sanguine.example.com.ipp: UDP, length 166 08:49:41.228715 IP splat.freerange.example.com.ipp > broadcast.freerange.example.com.ipp: UDP, length 166 I can contact ipp on printers.example.com via telnet over IPv4 but not IPv6 $ telnet splat ipp Trying 2001:55c:dead:beef:dead:beef:dead:beef... telnet: connect to address 2001:55c:dead:beef:dead:beef:dead:beef: Connection refused Trying 192.168.0.62... Connected to splat. Escape character is '^]'. /ping-pong HTTP/1.0 400 Bad Request Date: Sun, 23 Jan 2011 16:51:57 GMT Server: CUPS/1.1 Upgrade: TLS/1.0,HTTP/1.1 Connection: close Content-Type: text/html Content-Length: 101 <HTML><HEAD><TITLE>400 Bad Request</TITLE></HEAD><BODY><H1>Bad Request</H1>Bad Request</BODY></HTML> Connection closed by foreign host.
Created attachment 474836 [details] static screenshot of gtk print widget "Getting printer information failed"
Created attachment 474837 [details] /bin/ip6tables-save on the client showing port 631 is open in IPv6
Created attachment 474838 [details] /sbin/iptables-save on the client showing port 631 is open in IPv4
Created attachment 474841 [details] the gnome printer status widget thingy showing that print queueing "works" at the GNOME desktop level And to exhibit that "printing works" from this machine (suffragette) without benefit of the gtk widget. We can see the cups logfile activity and (ahem) the example printouts appear on the printer as expected. The inclusion nearby is the gnome print status widget behaving as expected. Thus: print transport from suffragette.example.com to printers.example.com is show to be "working" The issue is the gtk print widget in the gnome applications can't use printer 'hp' because it "can't get its information" $ date | lpr -Php ... see the gnome print status widget and take a screenshot of it ... $ for i in /var/log/cups/*log ; do echo $i ------------ ; sudo ls -alsd $i; sudo cat $i ; done /var/log/cups/access_log ------------ 4 -rw-------. 1 root lp 426 Jan 23 09:03 /var/log/cups/access_log localhost - - [23/Jan/2011:09:02:51 -0800] "POST /printers/hp HTTP/1.1" 200 298 Create-Job successful-ok localhost - - [23/Jan/2011:09:02:51 -0800] "POST /printers/hp HTTP/1.1" 200 260 Send-Document successful-ok localhost - - [23/Jan/2011:09:03:32 -0800] "POST /printers/hp HTTP/1.1" 200 298 Create-Job successful-ok localhost - - [23/Jan/2011:09:03:32 -0800] "POST /printers/hp HTTP/1.1" 200 260 Send-Document successful-ok /var/log/cups/cups-pdf_log ------------ 0 -rw-------. 1 root lp 0 Dec 4 03:23 /var/log/cups/cups-pdf_log /var/log/cups/error_log ------------ 0 -rw-------. 1 root lp 0 Jan 18 03:25 /var/log/cups/error_log /var/log/cups/page_log ------------ 4 -rw-------. 1 root lp 280 Jan 23 09:03 /var/log/cups/page_log hp 54 wbaker [23/Jan/2011:09:02:56 -0800] 1 1 - localhost (stdin) - - hp 54 wbaker [23/Jan/2011:09:03:06 -0800] 1 1 - localhost (stdin) - - hp 55 wbaker [23/Jan/2011:09:03:37 -0800] 1 1 - localhost (stdin) - - hp 55 wbaker [23/Jan/2011:09:03:43 -0800] 1 1 - localhost (stdin) - -
Here's a culprit ... I still believe that the issue here is with the gtk print dialog for not being smart enough to "find" the appropriate service that is being broadcast. Or not ... why not? The issue is that cups-1.1 (of the FC4 era) did not provide IPv6 accessibility, even though an FC4 host could be tagged with an IPv6 address by radvd. However, a modern IPv6 client print client (F13) seems to *require* an IPv6 cups service to function. There is a murkiness about print browsing over IPv6 that I have not yet solved, but that seems to be a cupsd configuration issue, not a gtk print dialog browsing issue. In this story, the print browsing occurs because of IPv4 broadcast; the analog IPv6 multicast in support of print browsing isn't happening. The story explaining why the gtk print dialog "doesn't work": When the print cleint, suffragette (F13, IPv4+IPv6), is browsing the printers in the gtk print dialog, the click on printer 'hp' causes a query to go out to the print server in IPv6. Of course the print server, being FC4 and cups-1.1 is not listening on IPv6 so nothing helpful comes back, immediately. Here's an actuality of the tcpdump of what happens when one clicks on 'hp' to select it in the gtk dialog box: $ sudo tcpdump -n -i eth0 'port ipp' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 07:45:49.163605 IP6 2001:55c:dead:beef:1234:5678:abcd:ef01.35474 > 2001:55c:dead:beef:ef01:abcd:1234:5678.ipp: Flags [S], seq 1086637, win 4880, options [mss 1220,sackOK,TS val 500608049 ecr 0,nop,wscale 6], length 0 07:45:49.164967 IP6 2001:55c:dead:beef:ef01:abcd:1234:5678.ipp > 2001:55c:dead:beef:1234:5678:abcd:ef01.35474: Flags [R.], seq 0, ack 1086638, win 0, length 0 Here we see suffragette (F13, IPv4+IPv6) trying to contact splat (FC3, IPv4+IPv6) to get access to its printer information. The connection can't be established because cups-1.1 of the FC4 era doesn't set up that service on IPv6. See on splat (FC4, IPv4+IPv6, cups-1.1) $ netstat -l -t | grep ipp tcp 0 0 *:ipp *:* LISTEN Here I'll introduce flirtie (F10, IPv4+IPv6, cups-1.3) and show how with cups-1.3 the service is available on both protocols; the gtk print dialog on suffragette (the client, F13, IPv4+IPv6) can see the printer, find its information and print to it, when it is served off of flirtie. This is because flirtie surfaces the cups service on IPv6, which the gtk print dialog wants to use (and won't use the IPv4 service). Separately, I showed that F10 with cups-1.3 allows the gtk print dialog "to work" by supporting IPv4-based printer browsing *as well* IPv6-based printer specification querying. The /var/log/cups/access_log on flirtie supports this. 2001:55c:dead:beef:1234:5678:abcd:ef01 - - [25/Jan/2011:07:37:46 -0800] "GET /ppd/HP-Deskjet-960c.ppd HTTP/1.1" 200 22172 - - 2001:55c:dead:beef:1234:5678:abcd:ef01 - - [25/Jan/2011:07:40:29 -0800] "GET /ppd/HP-Deskjet-960c.ppd HTTP/1.1" 200 22172 - - And on flirtie (F10, cups-1.3, IPv4+IPv6) we see ipp service on both addresses $ netstat -l -t -n | grep ipp tcp 0 0 *:ipp *:* LISTEN tcp 0 0 *:ipp *:* LISTEN $ netstat -l -t -n | grep 631 tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN tcp 0 0 :::631 :::* LISTEN The intent here was to continue with print serving off of splat (FC4, cups-1.1) because that "used to work" and ought to continue. But with IPv6 available, it does not. The intent was to have the dual-stack hosts tend towards using the IPv4 cups service as that was all that was available out of splat (FC4, cups-1.1). It seems that the IPv6-capable print clients require IPv6 for cups serving. But IPv4 is required for print browsing. I still need to understand why IPv4 broadcast is required for print browsing; why BrowseAddress @LOCAL does not broadcast (multicast) anything helpful in IPv6 to dissemenate th e printer availability in IPv6. So for dual stack hosts: IPv4 broadcast to announce the printer; IPv6 to provide print services. I'll take that up in a separate ticket.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm still getting this problem in Fedora 16. I was going to get a packet trace to confirm, but tcpdump gets a kernel oops. I ran system-config-kdump to report that, but it dies trying to find /etc/grub.conf when F16 uses grub2 by default.
I verified that printing to the same printer works fine with lp on command line. It is only the print dialog that is failing. I will try tracing on the (centos) print server to see if it is trying IPv6.
Yep, dialog fails because cups is not listening on IPv6. No. Time Source Destination Protocol Length Info 6 5.413945 2001:470:8:809:10::2 2001:4830:1659:8888::1 TCP 94 33606 > ipp [SYN] Seq=0 Win=14400 Len=0 MSS=1440 SACK_PERM=1 TSval=39004770 TSecr=0 WS=16 Frame 6: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) Ethernet II, Src: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c), Dst: Dell_3a:a6:ff (00:1a:a0:3a:a6:ff) Internet Protocol Version 6, Src: 2001:470:8:809:10::2 (2001:470:8:809:10::2), Dst: 2001:4830:1659:8888::1 (2001:4830:1659:8888::1) Transmission Control Protocol, Src Port: 33606 (33606), Dst Port: ipp (631), Seq: 0, Len: 0 No. Time Source Destination Protocol Length Info 7 5.413995 2001:4830:1659:8888::1 2001:470:8:809:10::2 ICMPv6 142 Destination Unreachable (Port unreachable) Frame 7: 142 bytes on wire (1136 bits), 142 bytes captured (1136 bits) Ethernet II, Src: Dell_3a:a6:ff (00:1a:a0:3a:a6:ff), Dst: Cisco-Li_2f:bd:0c (00:1d:7e:2f:bd:0c) Internet Protocol Version 6, Src: 2001:4830:1659:8888::1 (2001:4830:1659:8888::1), Dst: 2001:470:8:809:10::2 (2001:470:8:809:10::2) Internet Control Message Protocol v6
Please change Fedora version to 16.
I found that if I add the configuration line: Listen ::1:631 to /etc/cups/cupsd.conf the IPv6 stack works.
remove printserver IP from /etc/hosts on print server then client will work.