Observed ESP-NOW frames are not according to the docs, and are actually not valid 802.11 "vendor" fr (IDFGH-503)

[vidarino]

Environment

• Module or chip used: ESP32-WROOM and ESP8266
• IDF version v3.3-beta1-4-g23b6d40c5
• Build System: Make
• Compiler version: crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
• Operating System: Linux

Problem Description

I've been playing with ESP-NOW a bit lately (on both ESP32 and ESP8266), and I've noticed that the frames being exchanged aren't actually according to the documentation found at https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/wifi/esp_now.html

The docs claim that frames contain:

MAC Header | Category Code | Organization Identifier | Vendor Specific Content | FCS

But in reality, things are a bit different. There is no FCS (checksum) in the frame, according to the header flags, and there are four "random" (probably not really random, but they change a lot) bytes immediately before the vendor payload. (Did the FCS acidentally make its way into the middle of the packet somehow?)

Here's a frame I snagged with tcpdump from a wlan-interface, running a small ESP-NOW example program:

18:29:55.779381 1.0 Mb/s 2412 MHz 11b -39dBm signal antenna 1 Action (86:0d:8e:85:f5:c4): Vendor Act#24
    0x0000:  0000 1200 2e48 0000 0002 6c09 a000 d901  .....H....l.....
    0x0010:  0000 d008 3a01 3633 3333 3333 860d 8e85  ....:.633333....
    0x0020:  f5c4 3633 3333 3333 c05b 7f18 fe34 75a0  ..633333.[...4u.
    0x0030:  d8cb dd0e 18fe 3404 0148 656c 6c6f c7db  ......4..Hello..
    0x0040:  0144                                     .D

The same is seen in a frame captured from the IDF ESP-NOW example (esp-idf/examples/wifi/espnow/):

21:39:40.525527 1.0 Mb/s 2412 MHz 11b -37dBm signal antenna 1 Action (24:0a:c4:96:c9:3c): Vendor Act#24
    0x0000:  0000 1200 2e48 0000 0002 6c09 a000 db01  .....H....l.....
    0x0010:  0000 d000 0000 ffff ffff ffff 240a c496  ............$...
    0x0020:  c93c ffff ffff ffff a000 7f18 fe34 fb37  .<...........4.7
    0x0030:  94bf ddcd 18fe 3404 0100 000a 00ab 3045  ......4.......0E

The vendor data should start at offset 0x002e (immediately after the [0x7f 0x18 0xfe 0x34] bytes, which is the category and organization id), but there you'll find four "random" bytes, and then, at offset 0x0032, the actual vendor frame [0xdd 0x0e + org + esp-now data].

The result is the same both with an ESP8266 running the Arduino libraries and a freshly updated ESP-IDF and a ESP32-WROOM

I assume most of the ESP devices already implement what I'm seeing, since they appear to communicate with each other just fine, but it's a shame the frames aren't according to the specs, nor are they actually valid 802.11 vendor specific frames. Wireshark quite correctly complains about "Malformed Packet" as well.

For backwards compatibility this might not be trivial to fix, but at least the documentation should reflect what's really going on, I think.

[zhangyanjiaoesp]

@vidarino Sorry to reply you too late. The purpose of the four "random" bytes is to prevent replay attacks. And we will update the documentation as soon as possible.

[zhangyanjiaoesp]

@vidarino The documentation has been updated in c55643b