Hide Forgot
Description of problem: I've been running quite some time a setup with a CUPS server and workstation. Server brodcasts queue advertisements with UDP messges and client configured CUPS queues automatically without any kind of configuration. Recently this has stopped working, i suspect because of the software updates. Version-Release number of selected component (if applicable): cups-1.3.7-26.el5.x86_64 cups-1.4.6-1.fc14.x86_64 How reproducible: Always in my environment. Steps to Reproduce: 1. Configure centos5 with printer queue 2. Install fedora and cups package 3. queue should appear into Fedora Actual results: [root@f14 ~]# lpc status [root@f14 ~]# lpq lpq: error - no default destination available. Expected results: # lpc status rafael@server: printer is on device 'socket' speed -1 queuing is enabled printing is enabled no entries daemon present # Additional info: f14 # tcpdump -i eth0 port 631 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:09:16.489500 IP server.example.com.ipp > bcast.example.com.ipp: UDP, length 156 22:09:47.490307 IP server.example.com.ipp > bcast.example.com.ipp: UDP, length 156 22:10:18.490782 IP server.example.com.ipp > bcast.example.com.ipp: UDP, length 156 22:10:49.491599 IP server.example.com.ipp > bcast.example.com.ipp: UDP, length 156 I suspect that this is not a bug. Then again, if is it, someone should report it so that we can start ironing the cause of it. I have not really changed anything expect updating both systems until it broke down. Since then, nothing seems to help. Clearly those network packet's show that printer is being broadcasted as before, but for some reason f14 doesn't configure it anymore.
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.