802.11n packets incorrectly parsed [was Payload limit for MacOS 10.15 devices (at least) - large payloads unseen]

[davidchatting]

For my MacBook MacOS 10.15 (at least) I don't see large packets addressed to its MAC address - I only see payloads of 28 bytes in length - however, it does seem to work properly for iOS devices. Other packets that may be asscoiated with this target device and have larger payloads are parsed with different MAC addresses, so this may be a problem with the parsing or (more likely) a misunderstaning of how MacOS addresses packets. This is an issue for both the ESP8266 and ESP32.

[davidchatting]

On further investigation there appears to be some difference in the packet structure. This code reports locally generated packets... (needs current dev branch)

#include <Approximate.h>
PacketSniffer *packetSniffer = PacketSniffer::getInstance();

char ma[18];

void setup() {
  Serial.begin(115200);

  packetSniffer -> init(6); //channel 6
  packetSniffer -> setPacketEventHandler(parsePacket);
  packetSniffer -> begin();
}

void loop() {
  packetSniffer -> loop();
}

void parsePacket(wifi_promiscuous_pkt_t *wifi_pkt, uint16_t len, int type) {
  if(wifi_pkt -> rx_ctrl.rssi > -50 && type == Approximate::PKT_DATA && len > 28) {
    wifi_mgmt_hdr* header = (wifi_mgmt_hdr*)wifi_pkt -> payload;

    Serial.printf("%i\t", len);
    Approximate::MacAddr_to_c_str(&(header -> da), ma);
    Serial.printf("%s\t", ma);
    Approximate::MacAddr_to_c_str(&(header -> sa), ma);
    Serial.printf("%s\t", ma);
    Approximate::MacAddr_to_c_str(&(header -> bssid), ma);
    Serial.printf("%s\t", ma);
    Serial.printf("%i\t", wifi_pkt -> rx_ctrl.rssi);
    Serial.printf("\n");
  }
}

While the router MAC address is consistently reported, the device's own MAC address is reported incorrectly and changes between a few different values.

[davidchatting]

This is a problem with 802.11n packets - for which rx_ctrl.sig_mode is set to 1. The struct wifi_mgmt_hdr is no longer correct and means that the MAC addresses are inccorretly parsed, it also appears that the type is not correctly set for these packets.

[davidchatting]

Interesting my Google Home seem to now be exclusively using 11n packets - part of a firmware update I guess?

[davidchatting]

Interesting my Google Home seem to now be exclusively using 11n packets - part of a firmware update I guess?

That doesn't seem to be true - at least not now