Bug 125302 - FC2 machine sharing printer via cups broadcast causes cups client systems on local subnet to block forever on recvfrom()
FC2 machine sharing printer via cups broadcast causes cups client systems on ...
Product: Fedora Legacy
Classification: Retired
Component: cups (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Legacy Bugs
: Security
Depends On:
  Show dependency treegraph
Reported: 2004-06-04 12:01 EDT by Andrew Clunis
Modified: 2007-04-18 13:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-13 02:53:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Clunis 2004-06-04 12:01:09 EDT
Description of problem:
cups server seems to hang client cupsds on recvfrom() on local subnet

Version-Release number of selected component (if applicable):

How reproducible:

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)
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

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:
Comment 1 Andrew Clunis 2004-06-04 12:08:15 EDT
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.
Comment 2 Tim Waugh 2004-06-04 12:10:04 EDT
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?
Comment 3 Andrew Clunis 2004-06-04 12:27:27 EDT
On the FC2 machine sharing the printer:


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.
Comment 4 Tim Waugh 2004-06-04 12:37:31 EDT
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?
Comment 5 Andrew Clunis 2004-06-04 12:59:35 EDT
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.
Comment 6 Tim Waugh 2004-06-28 05:43:16 EDT
k.georgiou: do you see this problem as well?
Comment 7 Kostas Georgiou 2004-06-28 07:06:19 EDT
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.
Comment 8 Matthew Miller 2005-04-11 18:19:18 EDT
[Bulk move of FC2 bugs to Fedora Legacy. See
Comment 9 Matthew Miller 2005-04-12 00:27:44 EDT
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.
Comment 10 David Eisenstein 2005-11-08 22:16:54 EST
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, 

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.

Note You need to log in before you can comment on or make changes to this bug.