>>>>> "J" == Jeffrey C Ollie <jeffo_at_noc.netins.net> writes:
J>
J> As of this morning, INN will stop accepting connections after a short
J> while (1-2 minutes after starting the server). Established
J> connections continue to work properly. Restarting the server and rebooting
J> the machine have no effect. Recompiling does not help either. This server
J> has been trouble free up until this morning. The server is running on
J> a DEC 3000 running OSF/1 3.0.
We've figured out what seems to be the problem. First a little more
detail on the symptoms:
Shortly after the news server was started, connections would fail.
Watching a tcpdump of the traffic showed that the connecting side was
sending the initial packets to open a TCP connection, but OSF/1 was
not responding. TCP connections to other ports were working normally.
After looking at the results of a netstat, we saw a number of entries
like this:
tcp 0 0 XXX.XXX.XXX.XXX.119 YYY.YYY.YYY.YYY.62425 SYN_RCVD
XXX.XXX.XXX.XXX is the server's IP address and YYY.YYY.YYY.YYY is the
remote computer's IP address. When there were five of these entries,
the news server would stop accepting connections (all new connections
would time out). After digging through the INN source code, sure
enough, INN was calling listen(2) with a backlog parameter of 5. The
site in question attempting to open the connection had a
malfunctioning router so the TCP opening negotiation sequence was not
completing, causing the kernel to wait for those five connections to
finish the negotiation sequence or to time out. Once the offending
site was taken care of, things went back to normal.
My question: Is this normal behavior or is this a bug in the OSF/1
TCP/IP implementation? The same problems also affected our WWW
server, but not so severely.
--
Jeffrey C. Ollie
Iowa Network Services System Administrator
Received on Mon Sep 11 1995 - 23:53:33 NZST