Support for lwIP
I'd like to use libnyoci on an Espressif ESP32 system (SparkFun's ESP32 Thing.) The software stack for this is the ESP IoT Development Framework, ESP-IDF, which uses lwIP for IP networking. This is apparently a pretty widespread IP stack; Wikipedia says "lwIP is used by many manufacturers of embedded systems. Examples include Altera (in the Nios II operating system), Analog Devices (for the Blackfin DSP chip), Xilinx, Honeywell ... and Freescale."
Most of libnyoci builds fine, but there are a bunch of errors in plat-net/posix/ due to missing functionality in lwIP:
- [ ]
pollisn't supported, sonyoci_plat_update_pollfdsneeds to be#ifdef'd out, but thennyoci_plat_waitandnyoci_plat_processbreak because they call it. - [ ]
cmsgheaderand all its ancillary types and constants aren't defined. This breakssendtofrom. - [ ]
ipv6_mreqis calledip6_mreqfor some reason, and itsipv6mr_interfacefield is of typein6_addrnotint, i.e. it wants the IP address of the interface, not its index in the interface list (which doesn't seem to exist; there is nogetifaddrs.) - [ ]
in_pktinfoandin6_pktinfoaren't defined. This breaks thepktinfofield ofnyoci_plat_s(which seems to be unused. It's written to innyoci_plat_process, but never read.) - [ ]
IN6_IS_ADDR_V4MAPPEDis not defined. I worked around this by copying in the definition from macOS's<in6.h>. - [ ] Some supported APIs are in different headers; for example there is no
<sys/select.h>for some reason, insteadselectis in<lwip/sockets.h>.
The first issue is the hardest one for me, since I don't know much about either poll or select. Looks like I need to reimplement nyoci_plat_wait and nyoci_plat_process using nyoci_plat_update_fdsets. Probably easy, but I'd appreciate any clues.
The second and third issues seem to be related to multihoming; not a problem for my use case because my board only has a single (WiFi) interface.
The other issues I think I've fixed locally.
First of all, this sounds great! Thanks for having a look. I always intended to add LWIP support but never got around to it.
My first suggestion would be to not attempt to adapt plat_posix, but to instead write a new plat_lwip that uses LWIP directly instead of the LWIP BSD-sockets emulation layer. LWIP has it's own constructs for this purpose which I think would be easier to use directly.
Some hints:
- Check out this documentation for some (very sparse) guidance on implementing a new net platform.
- Strictly speaking, both
nyoci_plat_wait()andnyoci_plat_process()are optional.
That being said, it is usually convenient to have nyoci_plat_process() around because otherwise you will end up just writing that code somewhere else. nyoci_plat_process() does two things: It checks to see if there is any data from the UDP port that needs to be ingested, and if there is it ingests it via nyoci_plat_set_session_type () and nyoci_inbound_packet_process(). It also checks to see if any timers have expired and handles them if they have (via nyoci_handle_timers()). See the uIP implementation to get a feel for what is required. If you handle packet ingestion as it happens, and call nyoci_handle_timers() appropriately, then strictly speaking you wouldn't need nyoci_plat_process().
You could also implement nyoci_plat_wait() to just return NYOCI_STATUS_OK (basically forcing a tight loop), like I do in plat_uip.
Again, I recommend using LwIP directly instead of using the BSD-Sockets emulation that comes with LwIP. It will give you a tighter, better integrated solution.
Thanks for the quick reply! For now I'm hacking the plat_posix code, because it's faster and I've got a demo on Thursday 😱 It's compiling and basically running now; I will know if it works properly in a few hours when I get the rest of my demo functional.
How'd the demo go?
Pretty well, thanks. It had a tendency to stop responding after a minute or so, but I worked around that. Afterwards I found the reason — I had an uninitialized variable, which was sometimes causing huge timeout values to be passed to select(). After I fixed that, it became pretty reliable.
I have a branch with my changes; I'll clean it up and submit it to you as a PR. (As I said earlier, it adapts the existing POSIX code to make it compatible with lwIP's POSIX adapter layer, instead of creating a new implementation.)