Red Hat Bugzilla – Bug 125302
FC2 machine sharing printer via cups broadcast causes cups client systems on local subnet to block forever on recvfrom()
Last modified: 2007-04-18 13:08:38 EDT
Description of problem: cups server seems to hang client cupsds on recvfrom() on local subnet Version-Release number of selected component (if applicable): cups-1.1.20-11 How reproducible: Unsure. Steps to Reproduce: 1. FC2 machine, with broadcasting enabled, sharing a printer. (the printer's queue is HPLaserJet2200) 2. Another, client machine, with auto-discovery enabled. Any recent distro (I tried both debian testing and FC2) 3. Actual results: FC2 machine works fine. All cups daemons clients (GNU/Linux, regardless of distro... occurs with both FC2 and Debian unstable) with cups discovery available hang on recvfrom(). Running the client's cupsd under strace -f -F reveals something like this: <...blah, blah... > time(NULL) = 1086364449 select(1024, [0 2 3 5], [], NULL, {1, 0}) = 1 (in [2], left {1, 0}) time(NULL) = 1086364449 recvfrom(2, it blocks there forever. (note this strace was taken from a client running Debian, but exactly the same behaviour occurs on an FC2 client too). As such, the app trying to use the printer (via gnome-print, etc) hangs up. Running wget http://localhost:631 does the same and hangs forever after connecting. Again, the user running on the box with the shared CUPS printer has no problems at all. Expected results: Clients would be able to print without locking up. Additional info:
small typo correction, rather than: "...occurs with both FC2 and Debian unstable)..." should have been: "...occurs with both FC2 and Debian testing)..." shouldn't really matter, but I don't want this to be confusing.
So the weird thing about this strace is that the select() result is that fd 2 is readable, but recvfrom(2,...) shows that it is not. Which glibc and kernel are running on the FC2 machine that exhibits the problems?
On the FC2 machine sharing the printer: glibc-2.3.3-27 as for, kernel, well, um, heh heh. 2.6.4, custom. Nothing too far gone, though, as I had menuconfig import the config for the original RH kernel 2.5. I built it so I could run dosemu (it got SIGILL under the original kernel that shipped with the system). Heh.. hopefully it isn't the custom kernel causing the problem... Everything else on the system works OK. :/ Machines that actually had the lock up problem when on the same network as the above box were various distros.. FC2 and deb to be precise. The one in particular that that strace came from is running 2.6.6 with glibc 2.3.2.ds1-12. The strace under the client FC2 box (I no longer have access to it... sorry. :/ ) was almost exactly the same.
What is the network path from the broadcasting CUPS daemon to the receiving (hanging) one? Also, I need to be sure that I am looking at the right code: which version of cups did that strace actually come from?
the cups daemon on the troubled client that this particular strace came from was 1.1.20final+cvs20040330-3. As for network path, they are on the same ethernet segment and ip subnet. ping, ssh, etc. work fine, and neither machine has iptables firewalling.
k.georgiou: do you see this problem as well?
No problems here so far. I am exporting printers from an FC2 machine to RHEL3 clients. I am monitoring the bug report because i don't want to have any nasty surprises in the future if it is a real bug.
[Bulk move of FC2 bugs to Fedora Legacy. See <http://www.redhat.com/archives/fedora-announce-list/2005-April/msg00020.html>.]
This has been open for half a year with no activity; the status and repeatability look vague. Does anyone have anything more conclusive on this? Thanks.
This issue has been open almost 1.5 years with no activity. Also, this does not seem to be a security vulnerability. Andrew Clunis, you reported this as an issue with cups-1.1.20-11. This version is no longer the current version. The most recent version, cups-1.1.20-11.11.2.legacy, was published with Fedora Legacy Update Advisory FLSA:163274, <http://www.redhat.com/archives/fedora-legacy-announce/2005-September/msg00000.html>. Since this bug was reported on an old version, and no update to this issue has happened in well over a year, and this is not a security issue, I suggest we close this issue WONTFIX.