[BUG] Socket option renumbering in #20713 breaks Rust's libc

Open
  • Is something wrong?
#21,731 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, rust
Domain
networking

Research direction

Start by comparing the socket option constants in Rust's src/unix/nuttx/mod.rs with the NuttX master headers, as the report identifies 29 mismatches after #20713. Read that change and trace the affected socket options, including the TCP/IP/IPv6 values built on them. Determine whether NuttX should preserve the existing ABI values or coordinate a Rust libc update; done means the chosen numbering is consistent and the reported Rust networking calls work.

Written by the indexing model from the issue text.

Description

Arch: all Area: Networking OS: Linux
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
  • I have verified before submitting the report.
Dominant language
C
Stars
4.1k
Forks
1.8k
Avg merge
1d 3h
Merged PRs (30d)
833

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/nuttx

All issues in apache/nuttx

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.