Re: [ECOS] network problems

[Roland Caßebohm <roland dot cassebohm at visionsystems dot de>]

On Samstag, 12. April 2003 00:29, Jonathan Larmour wrote:
> Andrew Lunn wrote:
> >>My problem is, I use select to wait for multiple inputs including the
> >> socket. Normally I recognize the a connection was closed by peer if
> >> read() returns 0 or I get an error while write().
> >>But sometimes I have the case, the I stop reading and writing to the
> >> socket for some reasons. So I just don't set the corresponding bit in
> >> the fdset. but in such state I can't recognize if the connection is
> >> closed.
> >
> > Try setting the bit in exceptfds. I think select will then report when
> > the socket is closed.
>
> I'd be interested to know for other reasons if this is true! AFAIK
> exceptfds is only used for OOB data.
>
> BTW, did you really mean ferror() rather than
> getsockopt(...,SO_ERROR,...)? Although in either case I'm not entirely
> sure they'd ever get set unless some operation is done on the socket
> first. Looking at the freebsd stack source, it looks like the getsockopt
> should probably work, but I also don't know if that's BSD-specific
> behaviour.

I have try it with getsockopt(...,SO_ERROR,...) and select with a timeout,
but it still says "no error" if the other side wants to close the
connection.
If I make a netstat on the host, which wants to close the connection,
it says the state is FIN_WAIT1 and if I make a snmpnetstat to the eCos
board, it says the state is still ESTABLISHED.

After that I have looked at tcpdump and I have seen there was no packet
from the host after closing connection, so the eCos board seems to have
no chance to recognize that the host wants to close the connection.
But if I force the eCos board to send a packet to the host, the host
immediately responses a RESET-packet.
The keepalive packets before don't make anything.

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