I now have some more data
This time the remote system is running Solaris, i believe;same sort
of scenario as before (netscape used to ftp from the server to mypc)
Again, observed the same magic number of backlogged packets in
the recv Q (57) and same state i.e CLOSE_WAIT
The only difference is that unlike NEWS_OS solaris doesnt
send any more FIN packets -- so solaris is clean. OTOH, Linux is stuck now
for the last few days in this state.
The only way i could kill the connection i posted about was by re-booting.
Not good.
(those packets kept coming and Linux kept responding when it shouldnt
have). Seems like the app is not notified.
============ Previous message starts here ----------------
This is definetly a bug and it appears to be the remote end.
Here is an infinite loop of packets (infinite because they are there for
hours if not days).
mypc is a linux box (2.0.*) the remote end is running NEWS-OS6.1.*
---- begin loop ----
11:05:06.217066 inetfw.sonycsl.co.jp.ftp > mypc.1155: F 0:0(0) ack 1 win
52560 (DF) [tos 0x10]
11:05:06.217066 mypc.1155 > inetfw.sonycsl.co.jp.ftp: . ack 1 win 31744
11:05:06.717066 inetfw.sonycsl.co.jp.ftp > mypc.1155: . ack 1 win 52560
(DF) [tos 0x10]
---- end loop----------
===================
[@mypc /root]# netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 57 0 mypc:1155 inetfw.sonycsl.co.j:ftp CLOSE_WAIT
===============
It looks like a bug from NEWS-OS because it keeps sending these FINs; It
looks like a bug from Linux because it keep ACKing the FINs in the
CLOSE_WAIT state when it should be ignoring them(according to RFC793 as
well as from the quick perusal of the code). It looks more like a bug from
Linux because it never gets out of the CLOSE_WAIT state; it should after
the application closes (ftp in this case). I wonder when the app is told
to close. It is even more interesting because the receive
Q has 57 packets(?)
I think i have seen this behavior before not sure if i can reproduce it
though. I ftp'ed something using Netscape4.0.* client; the
remote side runs Netscape1.12 server.
I would probably have tried to resolve this but iam extremely busy at work
(totaly non-Linux) so the best i could do is report it.
Any takers? Alan?
cheers
jamal
PS:- I have seen this behavior before, i thing in the CLOSING or LAST_ACK
state; also someone in my Linux user group had
reported it for the LAST_ACK state.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu