USB Ethernet support

[martin-mat]

creating a ticket to bookmark this feature. This is a point I've been thinking about recently and this comes to me as a really neat idea to add to RF24Ethernet: Support of USB Network device.

Idea: create an USB Stick with nRF24l01 supporting one of standard USB Ethernet interfaces (ECM, RNDIS, ...) so the stick is detected by OS as a regular USB ethernet device.

My explorations on this so far:

• VUsb is probably not a good idea to use as it utilizes USB 1.1 standard only and does not support bulk endpoints that mentioned USB ethernet standards use
• good way seems to be to use LUFA library; there is a nice example there for simple RNDIS device. But this implies to use an avr chip with USB support
• it should be possible to use atmega32U4 used in Leonardo, pro micro, etc...
• mentioned RNDIS example requires better chips with more ram, but it is mainly due to large max ethernet frames, large tcp window and can be reduced to fit to atmega32u4's ram (I did some trials recently there)

The code to be added for this purpose to RF24Network would be probably not that complicated from my point of view and maybe it's already mostly there: get an ethernet frame from LUFA/network, check it's type:

• arp -> call uip's arp handling & send it back to LUFA or network
• ip -> get dest mac from uip's arp, and send the frame with ip accordingly via LUFA or network
  ...and that's probably it. No need for any transport/application layer handling, all this is done on host OS level.

Expected scenario - plug Leonardo into usb -> you get an Ethernet device, assign it's IP and here you go, you are connected to RF24 network.

@TMRh20 any opinion about that?

[TMRh20]

Heh, sounds like a plan. I mostly have questions about the best approach, but limited knowledge, so I'll just throw out some random info here:

With RF24Ethernet, there are 2 main issues with using TAP/ARP right now:

1. Arp requests to nodes multiple hops from the master node can be a bit spotty.
2. Ethernet headers add 14 bytes to each IP payload (54 bytes for headers total)

The alternative of course, is to use either static mapping of MAC/IP or include RF24Mesh. The benefits of using RF24Mesh include faster lookups, no multicast ARP-type requests, and auto-confguration of nodes. A very simple application of this can be seen in the SLIP-Gateway example, and RF24toTUN includes both TAP & TUN options.

The resulting code tends to be about the same size currently, since removing ARP code clears up room for the mesh code. Personally, most of my development has been with TAP/ARP/Ethernet, so I would consider that the more stable side of things right now though.

Another note, the Arduino re-assembly code is nowhere near as robust as the RPi re-assembly code. Arduino will only reassemble one frame at a time from a single host, where RPi will cache a frame fragment from each node, and assemble them independantly of each other. It might be worth beefing up that code in RF24Network, since gateway type nodes typically don't need to run the IP stack, and have more free memory etc. Not quite sure if its worth the effort though.

This is definitely something I would put time into, if you need any info etc. regarding the current libraries, functionality, etc. or if there is anything I can do to help, just let me know.

[martin-mat]

Thanks for info @TMRh20. For now I'll let this topic sleep for a while concerning my activities, but definitely at some point of time I'd like to see that implemented. If you or anyone else interested - feel free to pick this topic.

[2bndy5]

I know this is an old thread, but I just wanted to mention that the new RP2040's PicoSDK would be the most flexible/easiest way to make this feature happen. Because the PicoSDK allows direct configuration of the tinyUSB bootloader, one can easily declare their own patented VID and PID numbers which the OS could then assess to use the custom-made software/drivers for a USB-RF24Ethernet adapter.