I have two Fedora 9 computers called "free-spin" and "diet-anarchy". free-spin has a printer attached to it via a USB cable. I set it up in system-config-printer on free-spin and checked "Share published printers connected to this system" and "Allow printing from the Internet". When open system-config-printer on diet-anarchy, I don't see this printer in the tree under "Remote printers" even though I have "Show printers shared by other systems" checked. I'm pretty sure that when I was using Fedora 8 on diet-anarchy and Fedora 9 on free-spin, this printer would show up on diet-anarchy automatically. I also have Mac laptop, and when I connect it to the local subnet, it automatically finds the printer on free-spin with no problems. That's what should happen. Currently with Fedora 9, I have to know both the IP address of the machine the printer is connected to, and the protocol it is using. That's well beyond the capabilities of a lot of home users. I have this problem whether or not the firewalls on both free-spin and diet-anarchy are disabled. This is with system-config-printer-0.7.82.5-1.fc9 and cups-1.3.7-8.fc9.
Please use the troubleshooter to find out whether any commonly known problem is causing this. From system-config-printer, select Help->Troubleshoot from the menu bar. If you are given the opportunity to save a troubleshoot.txt file, please attach that file here.
Created attachment 312810 [details] What I get when I specify the hostname as "free-spin" I tried the troubleshooter. I selected "not listed" and then it asked me for the name and IP address of the printer. Since the use case I'm interested in is where the user does not know the IP address, I left those fields blank. This resulted in the following debugging information: Page 1 (Scheduler not running?): {'cups_connection_failure': False} Page 2 (Choose printer): {'cups_dests_available': [], 'cups_queue_listed': False} Page 3 (Local or remote?): {'printer_is_remote': True} Page 4 (Remote address): {'remote_server_ip_address': '', 'remote_server_name': ''} Page 5 (Check network server sanity): {'remote_server_name_resolves': False, 'remote_server_try_connect': ''} If I cheat a bit and tell it that the name of the computer is free-spin, I get the attached troubleshoot.txt.
The attachment was what I needed. From it I can see: * free-spin is on the same subnet as you * its printer, trip, is marked as shared So the problem is one of these: * free-spin is not sending browse packets * the client is not receiving browse packets What does running 'tcpdump udp port ipp or icmp' for a minute or two on the client show?
(9:40 ~) root@diet-anarchy: tcpdump udp port ipp or icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 09:41:15.696122 IP fs.ipp > 192.168.2.255.ipp: UDP, length 196 09:41:46.694670 IP fs.ipp > 192.168.2.255.ipp: UDP, length 196 09:42:17.693795 IP fs.ipp > 192.168.2.255.ipp: UDP, length 196 09:42:48.692375 IP fs.ipp > 192.168.2.255.ipp: UDP, length 196 (fs being an alias for free-spin)
1. What does 'iptables -n -L' say, as root, on diet-anarchy? 2. What does 'cupsctl' say, as root, on diet-anarchy?
(11:21 ~) root@diet-anarchy: iptables -n -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination (11:21 ~) root@diet-anarchy: cupsctl MaxLogSize=0 SystemGroup=sys root DefaultAuthType=Basic _debug_logging=0 _remote_admin=0 _remote_any=0 _remote_printers=1 _share_printers=0 _user_cancel_any=0
That *looks* like your firewall is blocking the packets. Can you show me the output of 'iptables -v -n -L' just to be sure?
(11:22 ~) root@diet-anarchy: iptables -v -n -L Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 346K 425M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 27 2160 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 2944 206K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 3400 712K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT 241K packets, 21M bytes) pkts bytes target prot opt in out source destination
Yes, your firewall is blocking the packets. Since you say: > I have this problem whether or not the firewalls on > both free-spin and diet-anarchy are disabled. I will reassign this to the configuration tool for the firewall.
Ah, you're right. I can get the printer to show up on its own if I drop the firewall on diet-anarchy, but I have to wait a few minutes before starting system-config-printer. Sneaky!
Please mark "Network Printing Client (IPP)" as trusted in the trusted services list in system-config-firewall. This is solving your problem.
If I do that, I can see the remote printer when system-config-printer starts up. But it doesn't solve the usability problem. Perhaps some sort of notification in the system-config-printer GUI that the firewall is blinding the machine to shared printers would be an appropriate fix.
Yes. Unfortunately that is not currently possible due to architectural issues (see bug #440469).
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
"Perhaps some sort of notification in the system-config-printer GUI that the firewall is blinding the machine to shared printers would be an appropriate fix." Considering the last few comments on bug #440469, how about just setting the IPP client port to be a "trusted service" by default?
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.