Re: [ECOS] network problems

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

> But my problem seems to be more general, because the host which wants to
> close the connection, don't send any packet, although any FINISH packet
> to the board running eCos. So the TCP-stack of eCos can't notice that
> the host wants to close the connection.

It looks like your host is broken and probably eCos is doing the
sensible thing in this case. Without the host sending the FIN packet,
the connection is still alive even if the host things its part way
closed. Also, since its part way and not fully closed, i expect its
responding to the keep alive packets. Hence there is no way eCos can
determine the connection is dead until it sends more data and receives
the reset message.

What is the host? I suggest you talk to the people maintaining its
TCP/IP Stack.

Humm, just found this with google:

> If everybody is following the protocol, there is a legal way to stay
> in FIN_WAIT1 state.  This state is used to indicated that the
> "local" application has either closed the socket, or has done a
> shutdown on write.  But the protocol may not be able to actually
> send out the FIN flag, if there are still data awaiting to be send.
> And the reason that data waiting in the send buffer, is becuase of
> either of congestion window restriction or if the receiving end has
> closed the window.  Either case, the side in FIN_WAIT1 state will
> remain there until maximum retries on transmit timeout.  If the
> remote peer is ack'ing the window probe, FIN_WAIT1 is going to stay
> there for a while.

Does this fit?

     Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss