Question on multinet 5.1A and TCP FIN

Richard Whalen

2007-08-28 20:55:52 UTC

The problem corrected by KERNEL-UPDATE-151_A051 would be observed when
the MultiNet system is transmitting data, not receiving data. Often it
would be observed during an FTP transfer as FTP presents large data
packets to the TCP layer and the TCP layer breaks these packets up into
the interface's MTU sized packet. The problem arises when the addition
of options (such as timestamp) pushed the packet over the MTU size and
it was re-adjusted. If this happened such that the last packet now
required two packets, then both of the last packets would be sent with
the FIN bit set.

-----Original Message-----
From: Michael Anderson [mailto:***@comcast.net]
Sent: Tuesday, August 28, 2007 12:41 PM
To: info-***@process.com
Subject: Question on multinet 5.1A and TCP FIN

I am debugging a application problem in which I do not see data
returned from the other side when the following pattern occurs.

00:52:08.41 172.19.82.19.4318 > 172.30.102.11.www: S 0:0(0) win 65535
<mss 1460,,wscale 1,,,timestamp 29360128:0> (DF)
00:52:08.47 172.30.102.11.www > 172.19.82.19.4318: S 0:0(0) ack 1 win
65535 <mss 1380,,wscale 0,,,timestamp 0:0> (DF)
00:52:08.47 172.19.82.19.4318 > 172.30.102.11.www: . ack 1 win 32850
<,,timestamp 29360128:1896742912> (DF)
00:52:57.27 172.19.82.19.4318 > 172.30.102.11.www: . 1:1381(1380) ack
1 win 32850 <,,timestamp 29360128:1903099904> (DF)
00:52:57.52 172.30.102.11.www > 172.19.82.19.4318: . ack 1381 win
65535 <,,timestamp 1572864:-584777728> (DF)
00:52:57.52 172.19.82.19.4318 > 172.30.102.11.www: . 1381:2761(1380)
ack 1 win 32850 <,,timestamp 29360128:1903165440> (DF)
00:52:57.52 172.19.82.19.4318 > 172.30.102.11.www: . 2761:4141(1380)
ack 1 win 32850 <,,timestamp 29360128:1903165440> (DF)
00:52:57.59 172.30.102.11.www > 172.19.82.19.4318: . ack 4141 win
65535 <,,timestamp 1572864:-584777728> (DF)
00:52:57.59 172.19.82.19.4318 > 172.30.102.11.www: P 4141:4500(359)
ack 1 win 32850 <,,timestamp 29360128:1903165440> (DF)
00:52:57.82 172.30.102.11.www > 172.19.82.19.4318: . ack 4500 win
65176 <,,timestamp 1572864:-584581120> (DF)
00:52:57.89 172.30.102.11.www > 172.19.82.19.4318: P 1:828(827) ack
4500 win 65176 <,,timestamp 1572864:-584581120> (DF)
00:52:57.89 172.30.102.11.www > 172.19.82.19.4318: F 828:828(0) ack
4500 win 65176 <,,timestamp 1572864:-584581120> (DF)
00:52:57.89 172.19.82.19.4318 > 172.30.102.11.www: . ack 829 win 32436
<,,timestamp 29360128:1903230976> (DF)
00:56:48.09 172.19.82.19.4318 > 172.30.102.11.www: F 4500:4500(0) ack
829 win 32436 <,,timestamp 29360128:1933312000> (DF)
00:56:48.16 172.30.102.11.www > 172.19.82.19.4318: R 829:829(0) win 0

Basically data is sent by me and then a response from server followed
by immediate FIN by the server the 827 bytes returned from server I do
not seem to be able to read using recv() instead recv() returns 0
indicating shutdown. I am running this on OpenVMS 7.3-2 with Multinet
5.1A with out any patches. I have noticed a kernel patch for 5.1A that
"Correct invalid setting of FIN flag on second to last packet" is this
in any way related to the problem I am having. I may have some bug in
my C++ code but I am have not been able to find it my sockets are set
to non blocking and mostly I use select() determine if any thing is
available to read. select() is signaled and I recv() on the socket and
get the 0 bytes. I am very puzzled at this point as I have even
changes that code to a more efficient design in which I send my data
and FIN and then wait for that data from server but I have still have
problems with getting returned data.