Bug 456840

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.