Network issues on recent master

Rob Voisey

unread,

Jan 10, 2020, 11:46:03 AM1/10/20

to NuttX

Hi

I'm seeing some problems on master. I haven't check against an older version yet as it's quite a job moving between v7 and v8 but if this doesn't ring a bell for anyone I'll try that next. I've spent a lot of time tracing network code already.

1. SO_RCVTIMEO not working.

I set SO_RCVTIMEO on a UDP socket but the recvfrom hangs indefinitely while no data is received. It's waiting on ir_sem because nothing runs inet_udp_eventhandler to let the timeout code run. If I comment out the devif_event_trigger test in devif_conn_event to run the handler on Ethernet driver polls (which it doesn't normally accept) this works around the problem and the timeout code runs correctly.

As an aside setsockopt appears to clear the s_options SO_RCVTIMEO bit if a timeout is set and vice versa. That looks backwards to me, although I don't think that bit is used directly other than by getsockopt.

2. TCP close not working.

If I call close on a TCP socket it does not send a FIN | ACK and then hangs up waiting for the response. If I close the other end it receives the FIN | ACK which it interprets as a response and finishes closing the socket.

I'm guessing many people would be shouting about them if these were really network stack bugs but I've no idea what else I might be missing. Any thoughts appreciated.

Thanks

Rob

patacongo

unread,

Jan 10, 2020, 3:09:19 PM1/10/20

to NuttX

Forwarded to d...@dev.apache.org This mail list is being phased out in favor the Apache mail list. There is a response there.

Greg

Xiang Xiao

unread,

Jan 11, 2020, 3:02:21 AM1/11/20

to NuttX

On Saturday, January 11, 2020 at 12:46:03 AM UTC+8, Rob Voisey wrote:

Hi

I'm seeing some problems on master. I haven't check against an older version yet as it's quite a job moving between v7 and v8 but if this doesn't ring a bell for anyone I'll try that next. I've spent a lot of time tracing network code already.

1. SO_RCVTIMEO not working.

I set SO_RCVTIMEO on a UDP socket but the recvfrom hangs indefinitely while no data is received. It's waiting on ir_sem because nothing runs inet_udp_eventhandler to let the timeout code run. If I comment out the devif_event_trigger test in devif_conn_event to run the handler on Ethernet driver polls (which it doesn't normally accept) this works around the problem and the timeout code runs correctly.

As an aside setsockopt appears to clear the s_options SO_RCVTIMEO bit if a timeout is set and vice versa. That looks backwards to me, although I don't think that bit is used directly other than by getsockopt.

Thanks for reporting the bug, please try this patch:

https://github.com/apache/incubator-nuttx/pull/76/commits/d4031679479d0bb607e9c103cece387289202959

2. TCP close not working.

If I call close on a TCP socket it does not send a FIN | ACK and then hangs up waiting for the response. If I close the other end it receives the FIN | ACK which it interprets as a response and finishes closing the socket.

I'm guessing many people would be shouting about them if these were really network stack bugs but I've no idea what else I might be missing. Any thoughts appreciated.

Try this patch: https://github.com/apache/incubator-nuttx/pull/76/commits/3c0d68fe08039d9702a7603e20c0329b1d0aa8a8

Thanks

Rob

Xiang Xiao

unread,

Jan 11, 2020, 3:16:37 AM1/11/20

to NuttX

Rob,

BTW, if you have any new question, please post to the new mail list: d...@nuttx.incubator.apache.org.

You can subscribe it by:

mailto:dev-su...@nuttx.incubator.apache.org?subject=send%20this%20email%20to%20subscribe

Rob Voisey

unread,

Jan 11, 2020, 6:13:24 AM1/11/20

to NuttX

Xiang

Both issues are resolved with these patches thank you. Refer to my notes on the pull request.