ACCEPT() QUEUE BUG WITH SOCK_STREAM

ACCEPT() QUEUE BUG WITH SOCK_STREAM

Post by sl.. » Thu, 18 Jan 1996 04:00:00



I have a 486dx4-10 with 16 meg of ram and a 3c509b on an ethernet link.

The bug is this:  I have a program that accepts tcp/ip socket connections from
other hosts, but if the pipe is one way the sockets hang.
I use the accept() call to connect the socket.  A connection request arrives,
and the accept call sends out an ACK.  If the ACK never gets to the
destination, or for some reason the final ACK in the three way handshake never
arrives, the accept call refuses to accept any more connections.  The backlog
is set at three.
Usually what happens is someone tries to log on, but since the connection isnt
made they try over and over until the connection queue is full.  At this point
in time no other connections are accepted until the first person times out,
which can be on the order of 30 minutes.
Closing the socket does not fix this.  The socket remains in the SYN_RECV state
until either I kill the accepting program or the socket times out.  More often
than not the network will fix itself after ten minutes and the socket will
discover that it no longer is attached to anything.
I know that most unix machines do not do this;  However I have seen it happen
on three different versions of linux, 1.2.8, .9something, and 1.2.13 redhat.

If anyone can give me a hint on how to hack this *out of my kernel, it
would be greatly appreciated.  I can find no information on it.
Thanks in advance,
-dennisT

 
 
 

1. Accept listen queue bug... anyone?

I have a 486dx4-100 with 16 meg ram and a 3c509b-combo ethernet card, and
im running slackware version 1.2.8.

I have a mud that listens to an internet socket, that I set up with
ye olde 'listen' call, so that I have a queue of 3 pending connections.
Ordinarily, this isnt a problem, but every now and again, someone will try to
telnet to the mud and the 3-way handshake wont get through.  Soon, all three
pending requests in the queue are used up, and noone else can log on until
the connections either time out (which takes forever... seen it hang for an
hour at a time before) or until the connection finally gets the last ack back.
I know this problem still exists in linux 1.2.13, because I have seen it
occur on a machine with that version of linux also.

When I do a netstat, the hung sockets show as being in state '
Im willing to hack my kernel to fix this, but I need a little bit of help,
maybe a lot of help depending on what solution I have to take.  My first
thought was to make it so that when the socket is accepted, it is removed
from the queue even if the connection has not been made.  My second idea was
to make it so that if the last ACK isnt received in 45 seconds, it discards
the socket as broken.

I dont know if any of these will work, but if anyone out there could point
me in the right direction or if there is a kernel patch available, I would
appreciate it.

-dentin


2. Urgent News Flash

3. Wierd listen/connect: accept queue never fills up

4. gtoaster

5. Linux TCP/IP Accept Queue

6. 3ware irritation...

7. Who accepts bug reports for libc on linux?

8. Software raid HOWTO

9. bug in accept() ??

10. Sendmail does not accept my user account if it starts with an Capital, Bug???

11. ERESTARTSYS in accept() - 1.1.73 tcp/ip bug

12. Bug in accept() with threads (Sol2.4)?

13. bug in 2.4.19: USB device not accepting new address=12 (error=-110)