ESP-NOW max data rate and security

[harald.milz]

I am evaluating the feasibility of using ESP-NOW instead of UDP for my project which involves low-latency 8-channel audio transmission between two ESP32-C6 or (soon) C5 modules over a couple of meters. The sample rate is 44.1 kHz and I'm going to use an I2S TDM256 format from the ADC in the sender and to the DAC in the receiver. The 32 bit slots will be packed to 24 bits because for my application, 24 bit resolution is sufficient, and this reduces the overall data rate by 25% at the price of a small for loop. This has been tested and works nicely. Thus, the net data rate will be 44100 samples/s * 8 slots/sample * 24 bits/slot = circa 8.5 Mbit/s. And I'm going to packetize as many samples as possible to use the max. payload size without IP fragmentation, i.e. 1472 byte for UDP. The latency is then theoretically and confirmed by measurement 1.36 ms for 60 samples per datagram.

So there I have three questions.

1. The ESP-IDF documentation and the esp_now.h file seem to imply (but do not say explicitly) that I can use pretty much all Wifi PHY rates and frequency bands (in particular, WIFI_PHY_RATE_MCS7_SGI in the 5 GHz band). Is that correct, or am I limited to the default data rate of 1 Mbps?

2. The ESP-IDF documentation says that "the maximum packet length supported by v2.0 devices is 1490" but does not say which devices are v2 devices. In particular, are the C6 and the C5 v2 capable devices? For the modules, I'd say as long as they have enough RAM to provide the buffers, it should not matter, and they should support this, right?

3. I am concerned about ESP-NOW authentication which by and large seems not to exist, hence opening the door for denial of service. Maybe I misunderstand the concept, but according to my analysis, ESP-NOW supports packet encryption, but the master will always happily accept all packets (also unencrypted ones!) that are sent to him. ESP-NOW does not enforce encryption on the receiving end. One can verify the sender's MAC or IP address but these can easily be spoofed by anyone who knows how to handle a packet sniffer. One can add an HMAC to the payload to perform integrity checksumming and authenticity but the HMAC can only be verified after reception of each full datagram, which means it is fairly easy to saturate the receiver with nonsense data. So - how can this be mitigated? So far, UDP with WPA2/PSK appears to be a better solution. Can someone shed some light on this please?

Thank you!

[robiwan]

I'd say that 8 channel 24 bit is way over what ESP-Now can handle, at least with v1.0. Conducting tests I can reliably push ~600 kBit/s.

Have you considered looking into compression, f.i. the multi-channel version of Opus ? https://opus-codec.org/

[harald.milz]

True - this is why I asked for v2.

Compression is not an option, mainly because this is supposed to be a low latency application, and compressing imposes to much calculation effort, and hence, latency.

I could simply run a test, no problem, but my main concern is the point #3. Makes no sense to set up a test when it is clear that the whole stuff will be prone to denial of service. While this may be okay for a wifi connected lightbulb, it is sure not for a stage environment when you're playing a gig.