Red Hat Bugzilla – Bug 109701
RHSA-2003:275 doesn't fix IPP problem
Last modified: 2007-04-18 12:59:21 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: My system has the updated cups package, and the IPP problem still exists. I end up with a ton of IPP connections in a TIME_WAIT state. Version-Release number of selected component (if applicable): cups-1.1.17-13.3.0.3 How reproducible: Always Steps to Reproduce: 1. /etc/rc.d/cups start 2. 3. Actual Results: root@olympus$ netstat Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 localhost.localdo:60990 localhost.localdoma:ipp TIME_WAIT tcp 0 0 localhost.localdo:60989 localhost.localdoma:ipp TIME_WAIT tcp 0 0 localhost.localdo:60988 localhost.localdoma:ipp TIME_WAIT This netstat output was after cups was running for about 20 seconds. I started up cups and had 12 of these after 1 minute of run time. Expected Results: Cups should work properly. Additional info:
It is normal to have TIME_WAIT connections.
It is normal for cups to spawn dozens of connections a minute when there is no printing going on on the system? If that is true, then cups is a totally useless system and needs to be replaced.
It's the little desktop panel icon thingy. It's fixed not to do that in Fedora Core 1. But the TIME_WAIT connections are harmless.
Well, it is not completely harmless: on a larger network, it can create quite a load leading to a DoS effect - see also 88393. Even CUPS internal safety checks seem to confirm that: I have seen following messages in /var/log/cups/error_log Possible DoS attack - more than 10 clients connecting from xx.xx.xx.xxx! The ip number in question was running KDE (RH9+updates).
This is probably related to bug #107787.
Which, aside from being private (oops), is fixed in rawhide. It was that cupsd wasn't closing sockets as early as it could/should.