u7k4rs6 opened a new issue, #21731:
URL: https://github.com/apache/nuttx/issues/21731

   ### Description / Steps to reproduce the issue
   
   #20713 renumbered the SOL_SOCKET options and moved `__SO_PROTOCOL` from 16 
to 11, which also shifts the TCP/IP/IPv6 options built on top of it. Rust's 
libc hardcodes these values for NuttX (src/unix/nuttx/mod.rs) and still has the 
13.1.0 ones, so Rust networking will break with the next release.
   
   I diffed every constant in Rust's nuttx/mod.rs against the master headers 
(sim:nsh). 29 of them don't match, and all are socket options, e.g.:
   
   ```
                  rust  master
   SO_REUSEADDR     11      0
   SO_ERROR          4     69
   SO_RCVBUF         8     64
   SO_SNDBUF        12     66
   SO_SNDTIMEO      14     11
   TCP_NODELAY      16     11
   IP_TTL           30     25
   IPV6_V6ONLY      23     18
   ```
   
   The worst one is `TcpListener::bind`: Rust std always sets `SO_REUSEADDR` 
(11) first, and 11 is now `SO_SNDTIMEO`, which wants a `struct timeval`. I 
checked with a small C program on sim:tcploop using Rust's numbers:
   
   ```
   rust SO_REUSEADDR(11): ret=-1 errno=22
   rust SO_ERROR(4): ret=-1 errno=92
   rust TCP_NODELAY(16): ret=-1 errno=38 (16 is TCP_CORK now)
   ```
   
   So any Rust TCP server fails at bind, and `set_nodelay` / `take_error` fail 
too.
   
   Should we keep the new numbering and fix Rust's libc (and say so in the 
release notes), or keep these values stable since they're user-facing ABI? 
Happy to send the libc PR either way.
   
   ### On which OS does this issue occur?
   
   [OS: Linux]
   
   ### What is the version of your OS?
   
   Ubuntu, kernel 7.0
   
   ### NuttX Version
   
   master (after #20713)
   
   ### Issue Architecture
   
   [Arch: all]
   
   ### Issue Area
   
   [Area: Networking]
   
   ### Host information
   
   _No response_
   
   ### Verification
   
   - [x] I have verified before submitting the report.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to