SYN dropped

[Smith, Gene]

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
rtems/freebsd
host is acting as a server to a single client host (whose stack is unknown).
The
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
server). 
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 (161.218.124.223). For some reason, the client (161.218.124.230)
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
problem.)  

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

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 1.54.2.7. I found some changes in
version 1.54.2.12 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.

-gene