[ECOS] network problems

[ECOS] network problems

[Larry Harmon]

Hello,

    I have been working with rCos for about a month now.  My target hardware
is a PC with an Intel ethernet card and 2 serial ports.

    I am attempting to port existing embedded FW from a commercial RTOS to
eCos.
    I can successfully build and run redboot and run my application using a
serial port.  However I can't get ethernet support to work for me.

    I have my FW configured to share the ethernet port with redboot, redboot
using the IP address 192.168.1.222 and the application using the IP address
192.168.1.223.  I can ping both addresses!


    I start a thread to read from the ethernet port.  The thread does the
following, all successfully:

        TCPComm.socket_no = socket(AF_INET, SOCK_STREAM, 0)

        bind(TCPComm.socket_no, (struct sockaddr *)&sin, sizeof(sin) )
        listen(TCPComm.socket_no, 3)
        TCPComm.socket_active = accept(TCPComm.socket_no, (struct sockaddr
*)&sin, (socklen_t *)&sin_len))

I then try the following:
     FD_ZERO(&fd_read);
     FD_SET(TCPComm.socket_active, &fd_read);
     select(1, (fd_set *)&fd_read, (fd_set *)0, (fd_set *)0, (struct timeval
*)NULL)
     cmdSize = recvfrom(TCPComm.socket_active, (void *)Cmd, sizeof(Cmd), 0,
(struct sockaddr *)&sin, (socklen_t *)&sin_len);

However, select never returns when I send the device a message!

Is there a good example for this type of service?
I am confused about the network documentation.  The 2.0b reference doesn't
document recvfrom!
I am also unable to set my socket to non-blocking IO.  How is this done with
eCos?



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

Re: [ECOS] network problems

[Andrew Lunn]

> I then try the following:
>      FD_ZERO(&fd_read);
>      FD_SET(TCPComm.socket_active, &fd_read);
>      select(1, (fd_set *)&fd_read, (fd_set *)0, (fd_set *)0, (struct timeval
> *)NULL)
>      cmdSize = recvfrom(TCPComm.socket_active, (void *)Cmd, sizeof(Cmd), 0,
> (struct sockaddr *)&sin, (socklen_t *)&sin_len);
> 
> However, select never returns when I send the device a message!

Read the man page for select again. You probably don't want to be
passing 1 for the first parameter to select.

        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

Re: [ECOS] network problems

[Nick Garnett]

"Larry Harmon" <harmon@hrdcorp.com> writes:

>      select(1, (fd_set *)&fd_read, (fd_set *)0, (fd_set *)0, (struct timeval
> *)NULL)

Here's your problem. That first argument is the upper bound of the
number of fds to test. It needs to be TCPComm.socket_active+1.

> 
> Is there a good example for this type of service?

The httpd does the same thing. Look there.


> I am confused about the network documentation.  The 2.0b reference doesn't
> document recvfrom!

You're right. All the recv* functions are missing. I have no idea why.

> I am also unable to set my socket to non-blocking IO.  How is this done with
> eCos?
> 

Either an ioctl() or a setsockopt() call should do it -- exactly which
I don't know offhand.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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

Re: [ECOS] network problems

[Roland Caßebohm]

On Donnerstag, 10. April 2003 10:41, Nick Garnett wrote:
> "Larry Harmon" <harmon@hrdcorp.com> writes:
> >      select(1, (fd_set *)&fd_read, (fd_set *)0, (fd_set *)0, (struct
> > timeval *)NULL)
>
> Here's your problem. That first argument is the upper bound of the
> number of fds to test. It needs to be TCPComm.socket_active+1.
>
> > Is there a good example for this type of service?
>
> The httpd does the same thing. Look there.
>
> > I am confused about the network documentation.  The 2.0b reference
> > doesn't document recvfrom!
>
> You're right. All the recv* functions are missing. I have no idea why.
>
> > I am also unable to set my socket to non-blocking IO.  How is this done
> > with eCos?
>
> Either an ioctl() or a setsockopt() call should do it -- exactly which
> I don't know offhand.

int one=1;
ioctl(fd, FIONBIO, &one);

Another question, does anybody know if there is an ioctl() or similar for 
checking if a TCP connaction is still alive?

Thanks,
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

Re: [ECOS] network problems

[Andrew Lunn]

> Another question, does anybody know if there is an ioctl() or similar for 
> checking if a TCP connaction is still alive?

Guessing here... But if the connection is dead, the socket should be
no longer valid. Thus ferror(3) should return something useful. If it
does not return an error, assume the connection is still alive. 

Have you set the keepalive option. If you don't have this option set
and there is no traffic, the stack will not notice the connection is
dead until the next time you try to send something. With keepalive
set, it sends ACK messages every so often so it can detect dead
connections.

   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

Re: [ECOS] network problems

[Roland Caßebohm]

On Donnerstag, 10. April 2003 12:56, Andrew Lunn wrote:
> > Another question, does anybody know if there is an ioctl() or similar for
> > checking if a TCP connaction is still alive?
>
> Guessing here... But if the connection is dead, the socket should be
> no longer valid. Thus ferror(3) should return something useful. If it
> does not return an error, assume the connection is still alive.
>
> Have you set the keepalive option. If you don't have this option set
> and there is no traffic, the stack will not notice the connection is
> dead until the next time you try to send something. With keepalive
> set, it sends ACK messages every so often so it can detect dead
> connections.
>
>    Andrew

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.

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

Re: [ECOS] network problems

[Andrew Lunn]

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

    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

Re: [ECOS] network problems

[Roland Caßebohm]

On Donnerstag, 10. April 2003 13:32, 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.
>
>     Andrew

Thnk you, I will look what will happen with exceptfds if the connection will 
close.

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

Re: [ECOS] network problems

[Jonathan Larmour]

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.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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

Re: [ECOS] network problems

[Andrew Lunn]

On Fri, Apr 11, 2003 at 11:29:24PM +0100, 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,...)? 

----------------------------------------------------------------------
FERROR(3)           Linux Programmer's Manual                FERROR(3)
 
 
 
NAME
       clearerr, feof, ferror, fileno - check and reset stream status

[Snip]
       The function ferror tests  the  error  indicator  for  the
       stream  pointed  to by stream, returning non-zero if it is
       set.  The error indicator can only be reset by the  clear­
       err function.

---------------------------------------------------------------------- 

A socket is a stream, so this should work.

> Although in either case I'm not entirely sure they'd ever get set
> unless some operation is done on the socket first.

Why should an operation been needed? When the socket is closed because
of a timeout or the peer, i would expect the local end to be closed
and -EPIPE or something similar set in the error indicator. I've not
tried this, so i could be totally wrong.

    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

Re: [ECOS] network problems

[Roland Caßebohm]

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

Re: [ECOS] network problems

[Andrew Lunn]

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

Something not right here. I don't have the TCP state machine to hand,
but i would expect the host to send a FIN packet when it transitions
from ESTABLISHED to FIN_WAIT1. The target should respond to this and
send back a response and change its own state. This will then put the
host into another state, probably FIN_WAIT2.

I would check what's is on the wire and see how that compares to what
should happen in a tcp tair down.

       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

Re: [ECOS] network problems

[Nick Garnett]

Andrew Lunn <andrew.lunn@ascom.ch> writes:

[ferror() on sockets]

> 
> A socket is a stream, so this should work.

But only if you have used fdopen() to convert a file descriptor into a
stdio FILE object. That's relatively rare for sockets.

> Why should an operation been needed? When the socket is closed because
> of a timeout or the peer, i would expect the local end to be closed
> and -EPIPE or something similar set in the error indicator. I've not
> tried this, so i could be totally wrong.
>

There's no mechanism for signalling events in the TCP/IP stack back up
to the stdio library. The only way that you can see that something has
happened asynchronously is to call down into the stack and get a
error code back. If no such call has been made, the FILE stream will
be oblivious of any changes.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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

Re: [ECOS] network problems

[Roland Caßebohm]

On Montag, 14. April 2003 11:58, Nick Garnett wrote:
> Andrew Lunn <andrew.lunn@ascom.ch> writes:
>
> [ferror() on sockets]
>
> > A socket is a stream, so this should work.
>
> But only if you have used fdopen() to convert a file descriptor into a
> stdio FILE object. That's relatively rare for sockets.
>
> > Why should an operation been needed? When the socket is closed because
> > of a timeout or the peer, i would expect the local end to be closed
> > and -EPIPE or something similar set in the error indicator. I've not
> > tried this, so i could be totally wrong.
>
> There's no mechanism for signalling events in the TCP/IP stack back up
> to the stdio library. The only way that you can see that something has
> happened asynchronously is to call down into the stack and get a
> error code back. If no such call has been made, the FILE stream will
> be oblivious of any changes.

What about SIGPIPE? But I think it is not implemented in the stacks.

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.

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

Re: [ECOS] network problems

[Andrew Lunn]

> 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

Re: [ECOS] network problems

[Roland Caßebohm]

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

Re: [ECOS] network problems

[Jonathan Larmour]

Roland Caßebohm wrote:
> On Montag, 14. April 2003 11:58, Nick Garnett wrote:
> 
>>Andrew Lunn <andrew.lunn@ascom.ch> writes:
>>
>>[ferror() on sockets]
>>
>>
>>>A socket is a stream, so this should work.
>>
>>But only if you have used fdopen() to convert a file descriptor into a
>>stdio FILE object. That's relatively rare for sockets.
>>
>>
>>>Why should an operation been needed? When the socket is closed because
>>>of a timeout or the peer, i would expect the local end to be closed
>>>and -EPIPE or something similar set in the error indicator. I've not
>>>tried this, so i could be totally wrong.
>>
>>There's no mechanism for signalling events in the TCP/IP stack back up
>>to the stdio library. The only way that you can see that something has
>>happened asynchronously is to call down into the stack and get a
>>error code back. If no such call has been made, the FILE stream will
>>be oblivious of any changes.
> 
> 
> What about SIGPIPE? But I think it is not implemented in the stacks.

Again, AFAIK that's only if you actually try and do something like write() 
to the socket. If you read from the socket, you won't get SIGPIPE until 
there's no buffered data left to read. At least that's the theory - if 
practice doesn't match that, that's a problem!

> 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 should definitely send a FIN, even if there's outstanding data in the 
send queue. That's what I've seen in the past with linux anyway.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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