I am building a DSSS Radio TCP/IP to Serial Converter device utilizing a
386sx, PCMCIA Card adapter and a WILINX DSSS radio card built with the
latest RTP release and tiny tcp stack.
I spawnvp devp-pccard then io-net from my main process.
My app is doing a socket, bind, listen, accept sequence to wait for the
stationary side to connect as client.
Initial connection works fine. The client does a connect and comm begins. My
code calls select to check for incomming traffic before calling recv
but does blocking sends on out going data. We have had this continuously
running with out failure for as long as 4 days at a time.
The problem is:
When the client detects a comm failure due to loss of RF signal (based on a
time out period) the client closes its’ connection waits a bit then does
connect again.
Two different things happen next.
- My blocking send blocks forever so my side never know the connection is
lost (No errors are detected in the connection)
- Send returns an error
Then I close my fd (returned from accept)
I jump back into my accept loop waiting for a new connect from the
client
Accept never sees that the client is trying to connect
When I look at /proc/ipstats it still shows I have an established
connnect on the previously connected IP,port
I have been able to duplicate this exact same scenario with an
out-of-the-box serial to TCP/IP converter radio from PROXIM (WAVELAN)
plugged in place of my ‘home-built’ device.
I guess my question is, when TCP/IP gets in these states is there any other
info I can get to determine lower level errors that don’t seem to be
bubbling up to the library calls as error returns?
Jim Moore <jmoore@agvp.com> wrote:
: I am building a DSSS Radio TCP/IP to Serial Converter device utilizing a
: 386sx, PCMCIA Card adapter and a WILINX DSSS radio card built with the
: latest RTP release and tiny tcp stack.
: I spawnvp devp-pccard then io-net from my main process.
: My app is doing a socket, bind, listen, accept sequence to wait for the
: stationary side to connect as client.
: Initial connection works fine. The client does a connect and comm begins. My
: code calls select to check for incomming traffic before calling recv
: but does blocking sends on out going data. We have had this continuously
: running with out failure for as long as 4 days at a time.
: The problem is:
: When the client detects a comm failure due to loss of RF signal (based on a
: time out period) the client closes its’ connection waits a bit then does
: connect again.
: Two different things happen next.
: 1) My blocking send blocks forever so my side never know the connection is
: lost (No errors are detected in the connection)
If nothing comes back from the other end, the stack will retry for 9 minutes
before giving up.
: 2) Send returns an error
: Then I close my fd (returned from accept)
: I jump back into my accept loop waiting for a new connect from the
: client
: Accept never sees that the client is trying to connect
: When I look at /proc/ipstats it still shows I have an established
: connnect on the previously connected IP,port
If you have data in the send buffer, it will show up as ESTABLISHED as
the stack is trying to flush this out before actually sending the FIN.
Or this may be a new connection already established waiting for you to
call accept() on. Is the peer’s port different from the first established
socket? What backlog argument are you passing to listen().
-seanb
“Sean Boudreau” <seanb@qnx.com> wrote in message
news:9m3egb$pgn$1@nntp.qnx.com…
Jim Moore <> jmoore@agvp.com> > wrote:
: I am building a DSSS Radio TCP/IP to Serial Converter device utilizing a
: 386sx, PCMCIA Card adapter and a WILINX DSSS radio card built with the
: latest RTP release and tiny tcp stack.
: I spawnvp devp-pccard then io-net from my main process.
: My app is doing a socket, bind, listen, accept sequence to wait for the
: stationary side to connect as client.
: Initial connection works fine. The client does a connect and comm
begins. My
: code calls select to check for incomming traffic before calling recv
: but does blocking sends on out going data. We have had this continuously
: running with out failure for as long as 4 days at a time.
: The problem is:
: When the client detects a comm failure due to loss of RF signal (based
on a
: time out period) the client closes its’ connection waits a bit then does
: connect again.
: Two different things happen next.
: 1) My blocking send blocks forever so my side never know the connection
is
: lost (No errors are detected in the connection)
If nothing comes back from the other end, the stack will retry for 9
minutes
before giving up.
Thanks for that info. Where is info like that obtained?
: 2) Send returns an error
: Then I close my fd (returned from accept)
: I jump back into my accept loop waiting for a new connect from
the
: client
: Accept never sees that the client is trying to connect
: When I look at /proc/ipstats it still shows I have an
established
: connnect on the previously connected IP,port
If you have data in the send buffer, it will show up as ESTABLISHED as
the stack is trying to flush this out before actually sending the FIN.
Or this may be a new connection already established waiting for you to
call accept() on. Is the peer’s port different from the first established
socket? What backlog argument are you passing to listen().
Sometimes /proc/ipstats show an established connection on the original
port.
At other times there are no connections with the port set to listen.
I call listen with 0 for backlog.
To followup, I think I have found a work around.
I now do the socket, bind and listen as before.
But now, once I get a valid fd from the accept, I close the descriptor from
the socket
call which effectively turns of listening on that port.
Now when the client dies, I get good errors from send.
I then close my fd and redo the socket call to start listening
on the port again.
So far I have not been able to make it fail.
I guess that fact that the port was still listening after my accept was
leading to my connection problems. Also, a 9 minute time out
would make my app useless.
Thanks for the reply.
Jim
-seanb