Bug 711201

Check your firewall configuration and make sure it is accepting "Network Printing Client (IPP)" packets.

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination      

We have centralized fw.

What does 'cupsctl' say, when run as root?

# cupsctl 
_debug_logging=0
_remote_admin=0
_remote_any=0
_remote_printers=1
_share_printers=0
_user_cancel_any=0
BrowseLocalProtocols=CUPS dnssd
DefaultAuthType=Basic
MaxLogSize=0
SystemGroup=sys root
#

I'd like to emphasize that in my understanding, cups package is set up so that it acts straight after installation as a client if it receives those advertisements. Thus i tried couple times to shut down the service, remove the package and /etc/cups directory completely. Didn't help.

Wireshark sniffing tells that those udp advertisements contain a correct ipp url to the server queue.

Server side sniffing shows that there is no packets coming from client, which implies that fedora doesn't either process those broadcasts or then fails to act to them.

Also i've checked that my network mask is correct so that kernel is really receiving those UDP broadcasts.

f14 # netstat -tunap | grep cups
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      1094/cupsd          
tcp        0      0 ::1:631                     :::*                        LISTEN      1094/cupsd          
udp        0      0 0.0.0.0:631                 0.0.0.0:*                               1094/cupsd      

shows that it correctly binds the loopback tcp sockets and udp for broadcasts (not the ipv6 that was in another bug 611213 report).

cupsd does not respond to browse packets, so that is entirely normal.  You would expect to see queues available in 'lpstat -s' on the client, though.

Try running "cupsctl LogLevel=debug2" as root, and inspecting /var/log/cups/error_log.  There may be a clue about why the browse packets are being ignored.

Created attachment 503670 [details]
error_log with cupsctl LogLevel=debug2

Attached log file after clean restart.

Presumably you left it for a minute or so in order for it to have a chance of seeing a UDP packet.  There is no indication that it saw one at all.

Next thing to try: run strace on the running cupsd process.

strace -p PID

We should see select() return when a packet arrives, and a recvfrom() attempt.

(In reply to comment #8)
> Presumably you left it for a minute or so in order for it to have a chance of
> seeing a UDP packet.  There is no indication that it saw one at all.

Actually i ran tcpdump in parallel (and now confirmed again) that machine gets a packet, but cups doesn't react to it anyhow.

> Next thing to try: run strace on the running cupsd process.
> 
> strace -p PID
> 
> We should see select() return when a packet arrives, and a recvfrom() attempt.

strace outputs this:
.
.
.
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2175, ...}) = 0
write(6, "d [08/Jun/2011:18:23:48 +0300] s"..., 79) = 79
epoll_wait(4, 

and waits. Then comes a packet, and it still stays in above.

Could you attach /etc/cups/cupsd.conf please?

Created attachment 503721 [details]
cupsd.conf configuration file

# rpm -V cups |wc -l
0
# rpm -q cups
cups-1.4.6-1.fc14.x86_64

It's a stock config, as supposed to be.

# ifconfig eth0
eth0   Link encap:Ethernet  HWaddr A4:BA:DB:F0:39:6E  
          inet addr:172.16.1.11  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a6ba:dbff:fef0:396e/64 Scope:Link

mask is correct and i can receive those broadcasts.

Now after restart, the queue is visible again. Go figure. Sorry for wasting our time.