[97] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: 1.1.9x unable to bind to port 80

daemon@ATHENA.MIT.EDU (David Hansen)
Sat Feb 18 22:41:36 1995

Date: Sat, 18 Feb 1995 17:49:11 -0800 (PST)
From: David Hansen <dhansen@networksnw.com>
To: linuxsys@ssg.com
Cc: linux-kernel@vger.rutgers.edu, linux-net@vger.rutgers.edu
In-Reply-To: <199502172224.AA00184@ssg.com>

On Fri, 17 Feb 1995 linuxsys@ssg.com wrote:

I have noticed problems with the net connections also.  I don't know if you
saw my post earlier this week or not, but I don't think anybody on the kernel
channel gives a shit.  I got tired of listening to all the gobbledook on the
linux-kernel channel (arguing over whether or not dos or msdos or pcdos or
whatever is decriptive or not descriptive enough and then who has been around
since the dark ages and lately the crap about what linux and other vendor's
code looks like --- ITS NOT RELEVANT!!!  I thought the channel was for kernel
problems, patches and announcements--NOT people's opinions and stories about
DOS from the 14th century) So I have chosen to be in the dark about all this
and unsubscribe from that channel.  The way I figure it now--if its broke
someone else will have to notice.  Or at least, listen to my complaints with
the knowledge that I'm not listening back. 

linux-kernel channel:  In the future, it would be more productive to 
redirect peoples problems to the correct channel if there is one.


<---linux-kernel people can stop reading here--->

Anyway, I don't know if you are aware of this, but somewhere along the way
from 1.1.59 (or 1.1.64) to 1.1.89, they migrated the Swansea NET code from
3.017 to 3.019.  I have looked into this code, and they made a number of
changes, too many to quickly spot the albatross.  Here is some more info on
my problem, so you can see if your problem is similar.  If so, you may want
to forward my message along with whatever you find onto someone who cares... 
Who that may be, I don't know? 

I see the problem with the printing daemon.  If you print to a remote host,
the connection doesn't close down all the way.  Upon checking the TCP states
with netstat, I saw that on the remote machine, the connection is in
CLOSE_WAIT state and on the local machine FIN_WAIT2.  This basically means
that the local side is waiting for the remote to finish closing, however, in
this case, the remote lpd daemon is still busy printing the document and
won't finish closing the connection down until printing is complete.  More
background info, when using ports < 1024, special rules apply.  As a matter
of fact, libc provides a routine rresvport that reuses ports starting at 1023
and working backwards.  Also fixed privileged ports (like port 80 or 25) may
see this same behavior.  Apparently, the tcp socket code figures FIN_WAIT2 is
good enough to reuse the port (probably since the upper layer application is
really done with it and maybe long gone).  So in both cases (NET 3.017 and
NET 3.019), the port gets reused by the next bind request.  Now here is where
I see the difference:  When the new connection is being established, the TCP
state machine starts this by sending a SYN packet.  Since the remote side,
still thinks the connection is open, it replies to this invalid packet with a
simple ACK packet.  In the old code, since this is not the right response,
the local would respond by sending an RST (reset) packet.  This would
consequently force the remote side to abort the connection.  The local would
then timeout and resend the SYN packet, at which point the remote then
accepts the connection sending a SYN ACK and continuing to open the new
connection.  The new code does not respond in this fashion, instead it just
continues to try to force the SYN packet down the remotes throat. 

What I would speculate is probably happening to you, is similar behavior. 
Your sendmail or httpd has a connection that has only partially terminated. 
The lack of the reset behavior is not forcing the clearing of the connection
and things just sit around all locked up and all. 

Of course, like I said earlier, there were a number of changes in the net
code, so this could just be shooting off at a goose when you're duck hunting. 

Good luck,
dave

PS: I have now subscribed to the linux-net channel, which is where I think
this kind of problem should be reported? 


home help back first fref pref prev next nref lref last post