Esp32 promiscuous mode - limit callback packet data size

[Xenoxca]

Hello!

I was playing around with promiscuous mode on my ESP32, and noticed that it can miss a lot of packets, presumably because calling the promiscuous callback function and copying all the packet data is a fairly slow process.

I am trying to develop an app that only collects the header of the packet - I don't care about the packet contents, all I'd like is the RSSI value.

I'm thinking there must be a way to limit the data that gets sent back to the promiscuous mode callback function, but it's obvious that there's no established API function that can do this. I looked into the IDF code, and it appears that the function that copies packet data to the callback function is located in a precompiled library (libnet80211.a)

Does anyone have any thoughts about how to only get the headers of the packets, in a way that would speed up packet collection? In my tests, while transmitting about 1,200 packets per second on my computer, the ESP32 only was picking up about 1/4 of those packets, or 300 packets per second.

The thought that immediately comes to mind is to disassemble the libnet80211.a file, and modify it to limit how many bytes it sends to the callback function, but that would be getting very involved...

Anyone have any thoughts, or directions I could go to start exploring this?

Thank you!

[cyberman54]

The promiscous mode function allows to set a filter mask, example see below. But i'm not sure if this speeds up the packet capturing, and can reduce missed frames. I am also interested in the same topic, using ESP32 in an application for which only MAC management frames are needed.

Code: Select all

wifi_promiscuous_filter_t filter = {.filter_mask = WIFI_PROMIS_FILTER_MASK_MGMT}; // we need only MGMT frames
	ESP_ERROR_CHECK(esp_wifi_set_promiscuous_filter(&filter)); // set MAC frame filter

[jeanleflambeur]

Make sure you mark your capture callback with IRAM_ATTR. Made a huge difference for me (went from 50-300 to 1500-2000 packets per second)