[WIP] net/lwip: [EXPERIMENTAL] Add auxiliary lwIP stack for sim.

[elokuucadiaN]

Supersedes #20159, which GitHub closed automatically when the source branch was renamed.

Summary

• Add the complete lwIP 2.0.3 source tree as an optional auxiliary stack. Its BSD license is retained in net/lwip/lwip-2.0.3/COPYING.
• Add the NuttX sys_arch port, Ethernet link adapter, and a raw L2 tap for the simulator network driver. Applications select the prefixed lwip_* API; native NuttX socket routing is unchanged.
• Add sim:lwip configuration and documentation, including the requirement to initialize lwIP from a long-lived context.
• This initial integration is simulator-only and experimental. The tests use three local nuttx-apps programs that are not included in this NuttX PR; there is no dependent apps PR.

Impact

• New feature: Yes, behind CONFIG_NET_LWIP, currently limited to ARCH_BOARD_SIM && NET_PKT.
• Existing users and compatibility: No change when the option is disabled. With the option enabled, applications must explicitly use the lwip_* API and initialize the auxiliary stack in a persistent context.
• Build: Adds the optional lwIP sources and sim:lwip configuration; no default configuration is changed.
• Hardware: Simulator Ethernet only. No physical board or hardware driver is changed.
• Documentation: Documentation/components/net/lwip.rst is included.
• Security: A second TCP/IP stack and raw link-layer tap increase the enabled build's network attack surface; this experimental option is disabled by default.

Testing

• Build host: WSL2 Ubuntu 22.04, x86_64, GCC 11.4.0.

• Target: sim:lwip, NuttX master base bc116157329946d2f7e6c82eb4b2d82009a41ebb; fresh export from the staged Git tree, make olddefconfig && make -j8 completed successfully.

• Local test setup: BOARDCTL_FINALINIT disabled and the three local test programs enabled only in the isolated build configuration. The local NSH test harness calls nuttx_lwip_initialize() from its persistent context. These test-only apps and configuration changes are not included in this PR.

• Runtime: Within one NSH session over a TAP interface (10.0.1.1/24), the host receiver logged:

  UDP ('10.0.1.3', 49153): 16 bytes, b'hello from lwip\n'
  TCP ('10.0.1.3', 49153): b'hello from lwip tcp\n'
  TCP ('10.0.1.3', 49153): received 20 bytes in 1.009 s
  TCP ('10.0.1.3', 49154): received 67108864 bytes in 4.697 s
  tcpbench: total=67108864 bytes time=4.696763 sec throughput=114.307 Mbps
  

• NuttX nxstyle completed with no diagnostics for the ten NuttX-written/modified C and header files. The complete vendored lwIP tree is preserved verbatim; git diff --check reports pre-existing trailing whitespace in third-party files.

• No physical hardware runtime result is available: the current link adapter only supports sim. This is a draft for architecture and scope discussion, not a request to merge without meeting the project's testing requirements.

PR verification self-check

• One functional change: optional auxiliary lwIP integration.
• Required scope, impact, testing limitations, and documentation described.
• All contribution requirements are satisfied; hardware testing and third-party lint disposition remain open.
• Work in progress; keep this PR as a draft.
• Ready for review and merge.

[xiaoxiang781216]

@elokuucadiaN but why do we need integrate lwip? nuttx has the native tcp/ip support.

[xiaoxiang781216]

nuttx normally doesn't add the 3rd party source code into git directly

[xiaoxiang781216]

why not reuse sim_tapdev_xxx

[acassis]

@elokuucadiaN I think the question that @xiaoxiang781216 raised is valid: you forgot to explain "why?"

I know that Samsung used lwIP because they thought that the default stack was slow; but in fact they were using the default network stack parameters that is tailored to fit on small devices, so buffers were minimum, fragmentation were huge, etc. Configuring the network stack correctly it is so fast as lwIP or even faster than lwIP.

That said, I think having an option to use lwIP on NuttX is fine, the only problem is this: probably you will add it and disappear, so it will be "another baby" for our small community to take care :-)

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[acassis]

@elokuucadiaN suggestion: instead of close an open PR you can use "git rebase -i ..." and later "git push -f"