Hi,
I'm searching for a way to use IEEE802.15.4 in RIOT-OS native between
tap-interfaces to simulate a net with RIOT-OS nodes locally. I found
some information about the native network stack (nativenet) in Ludwig
Knüpfers diploma thesis but it seems outdated? The current RIOT-OS
native version only supports Ethernet over tap-interface and some
zep_sockets. Was there a major rework of the native network stack in the
last couple of years?
The zep_sockets could be exactly what I'm looking for but I couldn't
find any documentation how to use them and what they are capable of. Has
anyone hints where to find documentation/blog posts/examples how to use
zep_sockets?
Best regards,
Linda / Chamaeleon-
Hi Linda,
Whitefield[1] is another way to simulate RIOT-OS native on top of 802.15.4/PLC locally.
Whitefield uses native mode compilation of RIOT, overrides netdev, and sends the packet to the backend. The backend is implemented on NS3-lrwpan[3] which does realistic simulation. It is possible to configure[2] Loss models(Friis, LogDistance, …), Delay models, and Mobility Models in the simulation.
Hope it helps.
Regards,
Rahul
[1] https://github.com/whitefield-framework/whitefield
[2] https://github.com/whitefield-framework/whitefield/blob/master/docs/wf_config_help.md
[3] https://www.nsnam.org/docs/models/html/lr-wpan.html
Disclaimer: I am the lead author of Whitefield.
Hi Linda,
Whitefield[1] is another way to simulate RIOT-OS native on top of
802.15.4/PLC locally.
…
Disclaimer: I am the lead author of Whitefield.
That's pretty cool! I didn't know about this.
Have you considered submitting the whitefield driver to upstream RIOT,
that way you don't have to maintain a fork and it would work on the
latest version of RIOT as well.
I haven't looked much at the code, but it looks like it's mostly
contained to pkg/whitefield and acts as a netdev_driver_t.
So if it's pretty self-contained, we would surely want to have this
too 
Best,
Benjamin
Thanks Benjamin for the feedback. Appreciate.
With regards to upstreaming, I had given it a good long thought, not only for RIOT but also for Contiki/Zephyr/OpenThread etc. The forks as you mentioned must be avoided.
I am working on something called “Plug-n-play mode”[1][3] where you provide RIOT-binary compiled in the native mode “without Whitefield driver/netdev in RIOT”.
During node init/load, Whitefield overrides the tap interface (or UDP-socket in case of OpenThread) or even change netdev interface using a combination of LD_PRELOAD and -fPIC/-pie compilation mode (details [2]). The packets are intercepted, routed to backend NS3. For OAM, RIOT node shell access will be provided directly by overriding the pseudo-terminal. There is some ABI dependency, especially where feedback from phy/mac (for e.g., L2-ACK failure or setting RSSI/LQI) is provided back to RIOT. In this case, RIOT/Contiki internal API is called (bin is compiled with -fPIC,-pie options) and this means ABI dep. But the good news is that these interfaces seldom change and Whitefield can do a pre-elf-check on the binaries before forking the bins.
Looking for any critical feedback if something basic is amiss here.
All in all, the point is, if this works then upstreaming code won’t be necessary.
Btw, I have been given an opportunity to present this work in the upcoming RIOT summit. Stay tuned.
Thanks,
Rahul
[1] https://github.com/whitefield-framework/whitefield/projects
[2] https://github.com/nyrahul/preload … Technical details on how preloading/interceptions/runtime-API-injection will work.
[3] https://github.com/whitefield-framework/whitefield/issues/92#issuecomment-617493105