The size of a 802.11 payload is saved in sig_len (found here). What is the best way to save this in a variable, so i can work with it?
(Actually i want to get the end of a 802.11 frame, but can't get the length of the buffer for some reason. Maybe there is also a way for getting the checksum of the buffer and print the buffer till it reaches the checksum?)
Get size of payload / end of 802.11 frame
-
- Posts: 9759
- Joined: Thu Nov 26, 2015 4:08 am
Re: Get size of payload / end of 802.11 frame
You have to figure out the type of packet you're passed in your sniffed callback, then cast the buffer you receive to the appropriate type, then grab the len from that type. Here's to do it for management frames, as an example:
Code: Select all
static void sniffcb(void *buf, wifi_promiscuous_pkt_type_t type) {
if (type==WIFI_PKT_MGMT) {
wifi_promiscuous_pkt_t *p=(wifi_promiscuous_pkt_t*)buf;
int len=p->rx_ctrl.sig_len;
//do stuff, p->payload contains an 802.11 packet of len bytes.
}
}
Re: Get size of payload / end of 802.11 frame
Why do i have to figure out the type of the sniffed packet? I mean, the length is everytime filed in sig_len, independently of the packet type.
This should work´for all packets, or am i wrong?
Code: Select all
static void sniffcb(void *buf, wifi_promiscuous_pkt_type_t type) {
wifi_promiscuous_pkt_t *p=(wifi_promiscuous_pkt_t*)buf;
int len=p->rx_ctrl.sig_len;
//do stuff, p->payload contains an 802.11 packet of len bytes.
}
-
- Posts: 9759
- Joined: Thu Nov 26, 2015 4:08 am
Re: Get size of payload / end of 802.11 frame
Yes, it should. I think the (unused) possibility to cast to some other datatype is a remnant from the ESP8266, if I recall correctly its hardware used slightly different structs to save different types of frames.
Re: Get size of payload / end of 802.11 frame
-
Last edited by mattismyo on Fri Jun 23, 2017 6:52 pm, edited 1 time in total.
-
- Posts: 9759
- Joined: Thu Nov 26, 2015 4:08 am
Re: Get size of payload / end of 802.11 frame
No clue, to be honest, I can parse management frames well enough to at least parse the SSID out of the beacon packets. (Fwiw, my code is here: https://github.com/SHA2017-badge/bpp/bl ... _sniffer.c )
Wrt the watchdog: My guess is that is because you're sending a lot of bytes to the serial port, and that is a bottleneck. Standard printf does active-waiting on the serial port if the FIFO is full, and that triggers the wdt. You should be able to stop that from happening by printing less data.
Wrt the watchdog: My guess is that is because you're sending a lot of bytes to the serial port, and that is a bottleneck. Standard printf does active-waiting on the serial port if the FIFO is full, and that triggers the wdt. You should be able to stop that from happening by printing less data.
Re: Get size of payload / end of 802.11 frame
Yeah, but i wan't to capture the whole traffic, such as mgmt, data and misc. So my only possibility is to feed the watchdog or disable him. I have to make some long-term tests to see if i really need it. Maybe i can reduce the clocking speed to prevent the watchdog.
I saw in the esp_wifi_types.h that the ssid of an AP can be catch out with wifi_scan_config_t. I'm looking for a way to capture only traffic from a specific SSID, do you know how? Maybe the traffic is not any more that big, so the watchdog won't be triggered. But independently to this fact, an SSID filter would be solid.
I saw in the esp_wifi_types.h that the ssid of an AP can be catch out with wifi_scan_config_t. I'm looking for a way to capture only traffic from a specific SSID, do you know how? Maybe the traffic is not any more that big, so the watchdog won't be triggered. But independently to this fact, an SSID filter would be solid.
Last edited by mattismyo on Fri Jun 23, 2017 6:52 pm, edited 1 time in total.
-
- Posts: 9759
- Joined: Thu Nov 26, 2015 4:08 am
Re: Get size of payload / end of 802.11 frame
You cannot pipe all the data from WiFi, which has a speed of what, 104MBit max? into a serial port which presumably still runs at 115200 baud; it just won't fit. Instead, the WiFi handler (specifically, your printf statement) will just sit there, spinning until there's finally some room in the UARTs serial buffer. That causes the idle threads to be starved and the WDT to go off. You can disable the WDT, but it's indicative of a deeper problem, and you'll be missing wifi packets anyway.
Yes, esp_wifi_set_channel is the way to set the channel; what do you think is unelegant about it?
Also, you can actually filter on SSID, although you have to do it manually. First figure out the AP MAC belonging to a certain SSID (by decoding beacon packets or otherwise, see the code I linked above), then you can compare one of the four MAC addresses in the WiFi header with that MAC address. You may want to read the 802.11 specs for more info about that.
Yes, esp_wifi_set_channel is the way to set the channel; what do you think is unelegant about it?
Also, you can actually filter on SSID, although you have to do it manually. First figure out the AP MAC belonging to a certain SSID (by decoding beacon packets or otherwise, see the code I linked above), then you can compare one of the four MAC addresses in the WiFi header with that MAC address. You may want to read the 802.11 specs for more info about that.
Who is online
Users browsing this forum: Baidu [Spider], Bing [Bot] and 167 guests