This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: network problems


On Montag, 14. April 2003 15:45, Andrew Lunn wrote:
> > 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.

Yes, this is what I see.

>
> 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?

Yes, in my case the receiving end has all buffers full, because it can't
process the data for some reason. It just don't set the bit for the 
incomming data of the fdset for select, so it will never call read again,
if there won't be more place in my buffers.
So there is there is data in the tcp stack, which I think is not 
acknowledged.

Roland

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]