Re: TCP socket close problem

In article <87wtbhqkoi.fsf@xxxxxxxxxxxxxxxxxxxxx> Staffan Ulfberg
<staffan@xxxxxxxxxx> writes:

Since my previous tcp issue was resolved by posting here, I'll try
again, this time with another TCP problem. If someone knows of a good
network programming group to post to instead, please tell me so!

I don't really know of one - comp.protocols.tcp-ip might be a good place
to take protocol issues (which this probably is, sort of), but it was a
long time since I read it, don't really know what it's like nowadays.
Your issue probably has nothing to do with FreeBSD specifically, but
people seem to post here about all kinds of things they run into while
they just happen to be running FreeBSD...

I've written a server app that listens to port 5000 on a FreeBSD
machine. Connecting works fine, and actually everything usually works
fine, except when some clients disconnect. The client's socket is
closed, and does not even show up in netstat (the clients are Windows
XP machines). On the server, however, the socket stays open, in
"ESTABLISHED" state. (Not even CLOSE_WAIT.)

It should transition to CLOSE_WAIT on receipt of FIN, and be deleted
altogether on receipt of RST AFAIK.

It would seem I'm doing something wrong, which prevents the server to
detect the closed socket, but I've added lots of trace output on the
server, and it does seem to set the client's socket descriptor in the
call to select(), but select() never returns saying that the
descriptor is readable.

The problem only happens when I client closes a "busy" socket, with
unacked data on the way to the client. And, as expected, the client
sends an RST after the FIN.

It shouldn't send RST "spontaneously" in that case, only if the client
has done a full close and more data arrives - but MS have their own
ideas...

It all looks like I'm not properly detecting that recv() returns with
0 bytes (I think the server sends it FIN after close() is called on
the socket?), but I've scratched my head now for a long time...

Well, theoretically, unless you use non-blocking I/O, your code be
blocked on send() and so never get to notice the arriving FIN via
select()/recv() (I prefer to use write()/read() on TCP sockets btw, but
I don't think that makes any difference). But I assume you would have
noticed that in your trace output, and the packet trace has other
info...

Can somesone with more TCP experience help me think of possibilities
for this happening?

15:34:13.244087 IP 81-226-237-254-no61.tbcn.telia.com.2610 >
multivac.fatburen.org.5000: . ack 699313 win 11680
15:34:13.256048 IP 81-226-237-254-no61.tbcn.telia.com.2610 >
multivac.fatburen.org.5000: . ack 702233 win 8760
15:34:13.517164 IP 81-226-237-254-no61.tbcn.telia.com.2610 >
multivac.fatburen.org.5000: F 118:118(0) ack 702233 win 8760
15:34:13.518210 IP 81-226-237-254-no61.tbcn.telia.com.2610 >
multivac.fatburen.org.5000: R 119:119(0) ack 702233 win 0
15:34:15.199721 IP multivac.fatburen.org.5000 >
81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118
win 65535
15:34:21.275374 IP multivac.fatburen.org.5000 >
81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118
win 65535
15:34:29.953937 IP multivac.fatburen.org.5000 >
81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118
win 65535
15:34:47.115708 IP multivac.fatburen.org.5000 >
81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118
win 65535
15:35:10.040407 IP multivac.fatburen.org.5000 >
81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118
win 65535

It seems clear that the server is seeing neither FIN nor RST - if it had
seen the FIN it should be ACK'ingwith 119, not 118, and if it had seen
the RST it certainly shouldn't send more data. It also seems that the
client isn't seeing the retransmits from the server, since it should
respond with RST to those (of course it may have been disconnected...).

Last time I believe you had a broken NAT device that corrupted the TCP
checksum, I suppose you have ruled out any similar (or even same)
problem now?:-) And I assume the trace is done on the server? Any local
firewall on it, that could possibly block the FIN/RST from being
delivered to the TCP/IP stack even though tcpdump sees them?

--Per Hedeland
per@xxxxxxxxxxxx

.

Relevant Pages

  • Re: Socket weirdness
    ... If RST is at the top of the stack before the ... RST is not "seen" by the client until the first ACK to client *after ... a Shutdown.Receive by the server. ... some N factor of stocks or time and closes socket. ...
    (microsoft.public.dotnet.framework)
  • Re: socket TCP_MAXSEG option and route MTU problem
    ... For particular client I need to reduce the TCP ... Does anybody has the same experience on AIX or other UNIX ... I wonder if maybe the AIX TCP is asking the socket layer to do initial ...
    (comp.unix.aix)
  • Re: socket TCP_MAXSEG option and route MTU problem
    ... For particular client I need to reduce the TCP ... Does anybody has the same experience on AIX or other UNIX ... I wonder if maybe the AIX TCP is asking the socket layer to do initial ...
    (comp.unix.programmer)
  • Re: Seeking UFFI for sockets on Linux
    ... The problem might spring from the fact that closing a TCP socket does ... will send a TCP segment with the FIN flag set and change state to ... the client will change state ...
    (comp.lang.lisp)
  • TCP socket close problem
    ... Since my previous tcp issue was resolved by posting here, ... I've written a server app that listens to port 5000 on a FreeBSD ... The client's socket is ... unacked data on the way to the client. ...
    (comp.unix.bsd.freebsd.misc)