Re: FIN_WAIT2 not working
- From: Rick Jones <rick.jones2@xxxxxx>
- Date: Wed, 26 Nov 2008 18:27:58 +0000 (UTC)
Gary R. Garrison <g.r.garrison@xxxxxxxxxxxxxxx> wrote:
I'm using an embedded Linux version 2.6.25-rc8.
All communications between the Linux machine and MSWindows machines
(WinXP pro, Vista and WinXP embedded) where the Linux machine
transmits information then calls Close() result in tcp window
updates arriving from the Windows machines after the Linux machine
has sent it's FIN.
Does the behaviour change if in the app on the Linux side you call
shutdown(SHUT_WR) on the socket and then hang in a timed select/poll
waiting for the socket to become readable, meanwhile on the Windows
side, you make certain that the Windows side calls close() after the
read return of zero? That sequence is what netperf does to be "sure"
that the receiver has received all the data.
Perhaps the Linux stack will be more "forgiving" of the window update
if the connection end-point isn't orhpaned after a close().
Communications between Windows machines also show tcp window updates
arriving from other Windows machines after we've sent them FIN.
The problem is the Linux machine sending the RST.
Well, or the Windows system sending a window update after a FIN.
Since this newsgroup keeps rejecting everything I send with a
".pcap" file attached heres a topo of the end of a capture :
the linux machine : 192.168.250.1
WinXP embedded machine 192.168.250.2
I've taken the liberty of converting the IPs to shorter things and
done some other "tightening-up" of the putput.
Time Src Dst Protocol Info
0.178455 LNX WIN [A] Seq=204430 Ack=1 Win=5840 Len=1448
0.178472 WIN LNX [A] Seq=1 Ack=204430 Win=2755 Len=0
Did the application do anything to put the Windows system into an
immediate ACK mode or is this very close to the beginning of the
connection?
0.261309 WIN LNX [A] Seq=1 Ack=205878 Win=14339 Len=0
0.261759 LNX WIN [A] Seq=205878 Ack=1 Win=5840 Len=1448
0.261881 LNX WIN [A] Seq=207326 Ack=1 Win=5840 Len=1448
0.262002 LNX WIN [F, P, A] Seq=208774 Ack=1 Win=5840 Len=1256
0.262013 WIN LNX [A] Seq=1 Ack=208774 Win=11443 Len=0
0.262102 WIN LNX [A] Seq=1 Ack=210031 Win=10187 Len=0
0.283422 WIN LNX[TCP Window Update] [A] Seq=1 Ack=210031 Win=61383 Len=0
0.283635 LNX WIN [R] Seq=210031 Win=0 Len=0
Linux client connects WinXP server, sends a block of 29 bytes
indicating the Linux machine is going to send 2500
"ArticleInformation" objects. The transfer is accomplished but at
the end, after the FIN by the Linux client, the WinXP machine sends
a window update then the Linux client sends a RST. Since windows
handles RST in realtime and the windows application hasn't yet
"taken" all of the incoming data, an error is seen in "read()".
Simple situation mais solution unknown.
If all else fails and you have the ability to change both sides of the
equation, you could have the Windows side to an application-level ack
of the data on which the Linux side waits before calling close() on
the socket. It goes one step further than the shutdown() idea above
by making sure that the Windows side has no more window updates to
send - they best be piggy-backed on that app-level ack.
rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.
- Follow-Ups:
- Re: FIN_WAIT2 not working
- From: Gary R. Garrison
- Re: FIN_WAIT2 not working
- References:
- FIN_WAIT2 not working
- From: Gary R. Garrison
- Re: FIN_WAIT2 not working
- From: Rick Jones
- Re: FIN_WAIT2 not working
- From: Gary R. Garrison
- FIN_WAIT2 not working
- Prev by Date: Re: iptables rule to block FTP-NAT-Helper-Traffic
- Next by Date: Re: VPN requirements
- Previous by thread: Re: FIN_WAIT2 not working
- Next by thread: Re: FIN_WAIT2 not working
- Index(es):
Relevant Pages
|
