SYN dropped

Smith, Gene Gene.Smith at
Tue Aug 28 01:15:25 UTC 2001

I am using the freebsd stack on the RTEMS embedded o/s. Generally, it works
very well. However, I have one problem that I cannot seem to solve. The
host is acting as a server to a single client host (whose stack is unknown).
data transfer is one directional, from the client to the server.

With the connection established and data flowing, the physical link might
break down 
temporarily for some reason, e.g., cable removed. The client soon realizes
that its data 
is not reaching the server and RSTs the connection (which is not seen by the
Shortly thereafter, it tries to reestablish the connection with SYNs.  When
the physical
link is good again (e.g., cable plugged back in) a SYN is seen by the server
which then
sends an ACK. The client then sends RST. After a short wait, the client then
sends a SYN
which kicks off a three-way handshake and reestablishes the connection. This
is the 
classic recovery from a half-open and seems to work 99%+ of the time when I
simulate it 
by removing the ethernet cable from the rtems/freebsd server.

However, sometimes after the physical link returns, the SYN sent by the
client is completely
ignored by the rtems/freebsd server. When this happens the connection does
not reestablish.
Here is a tcpdump of what happened this morning. Data was being pushed to
the rtems/freebsd
server ( For some reason, the client (
concluded that the 
connection needed to be re-established and sent SYNs which were continuously
ignored. (The
cable was not removed when this happened, so I have no idea why the client
tried to re-establish
the connection, however the lack of any response to the SYN is the real

07:14:31.160800 > P
101567529:101567609(80) ack 1 win 560
07:14:31.175092 > P
101567609:101568009(400) ack 1 win 560
07:14:31.184432 > P
101568009:101568089(80) ack 1 win 560
07:14:31.356876 > . ack 101568089
win 17520 (DF)
07:14:31.363571 > P
101568089:101568409(320) ack 1 win 560
07:14:31.376294 > P
101568409:101568649(240) ack 1 win 560
07:14:31.561738 > . ack 101568649
win 17520 (DF)
07:14:31.567685 > P
101568649:101568809(160) ack 1 win 560
07:14:31.579106 > P
101568809:101569209(400) ack 1 win 560
07:14:31.766566 > . ack 101569209
win 17520 (DF)
07:17:22.302449 arp who-has (8:0:6:1:0:5) tell
07:17:22.304596 arp reply is-at 8:0:6:1:1:2
07:17:22.309084 > S
1671798991:1671798991(0) win 0 <mss 1460>
07:17:42.303769 > S
1671798991:1671798991(0) win 0 <mss 1460>
07:18:02.307073 arp who-has (8:0:6:1:0:5) tell
07:18:02.309222 arp reply is-at 8:0:6:1:1:2
07:18:02.313642 > S
1671798991:1671798991(0) win 0 <mss 1460>
07:18:42.312840 > S
1671798991:1671798991(0) win 0 <mss 1460>
07:19:43.325024 arp who-has (8:0:6:1:0:5) tell
07:19:43.327303 arp reply is-at 8:0:6:1:1:2
07:19:43.334234 > S
1671798992:1671798992(0) win 0 <mss 1460>
07:20:03.328226 > S
1671798992:1671798992(0) win 0 <mss 1460>
07:20:23.330418 arp who-has (8:0:6:1:0:5) tell
07:20:23.332582 arp reply is-at 8:0:6:1:1:2
07:20:23.337420 > S
1671798992:1671798992(0) win 0 <mss 1460>
07:21:03.336067 > S
1671798992:1671798992(0) win 0 <mss 1460>
07:22:04.348183 arp who-has (8:0:6:1:0:5) tell

I am sure the rtems/fbsd host is still alive since it is still responding to
arps; also, I can 
connect to it and transfer data on other ports. 

I have looked at the freebsd cvs changes to tcp_input.c which, I believe,
handles the incoming SYN. 
The version of this file in rtems is I found some changes in
version which 
sounded like they *might* affect the situation, and tried that version in
rtems.  For a while it 
seemed to do the trick. But on my final cable off/on I saw almost the same
thing as above: the SYNs
sent from the client ignored by the rtems/fbsd server (the only difference
from above tcpdum
is that the client sent an RST while the cable was off).

One other observation: When I use the -e option on tcpdump, the destination
ethernet address 
always shows 0:0:0:0:0:1.  This is true for all segments including the
ignored SYN segments. There are 
switches between the client and host. Could this somehow contribute to the
ignored SYNs?

One more observation: The client always advertises a window size of zero
with its SYNs. 
Could this be a probem?

I would appreciate any ideas on how to solve this problem.


More information about the users mailing list