Details Regarding "Received packet radio metadata header"

thethinker
Posts: 53
Joined: Thu Mar 01, 2018 1:26 am

Details Regarding "Received packet radio metadata header"

Postby thethinker » Thu Mar 01, 2018 1:35 am

Hi,
I have been looking at the following structure in sniffer's API:
typedef struct {
signed rssi:8; /**< signal intensity of packet */
unsigned rate:5; /**< data rate */
unsigned :1; /**< reserve */
unsigned sig_mode:2; /**< 0:is not 11n packet; 1:is 11n packet */
unsigned :16; /**< reserve */
unsigned mcs:7; /**< if is 11n packet, shows the modulation(range from 0 to 76) */
unsigned cwb:1; /**< if is 11n packet, shows if is HT40 packet or not */
unsigned :16; /**< reserve */
unsigned smoothing:1; /**< reserve */
unsigned not_sounding:1; /**< reserve */
unsigned :1; /**< reserve */
unsigned aggregation:1; /**< Aggregation */
unsigned stbc:2; /**< STBC */
unsigned fec_coding:1; /**< Flag is set for 11n packets which are LDPC */
unsigned sgi:1; /**< SGI */
unsigned noise_floor:8; /**< noise floor */
unsigned ampdu_cnt:8; /**< ampdu cnt */
unsigned channel:4; /**< which channel this packet in */
unsigned :12; /**< reserve */
unsigned timestamp:32; /**< timestamp */
unsigned :32; /**< reserve */
unsigned :32; /**< reserve */
unsigned sig_len:12; /**< length of packet */
unsigned :12; /**< reserve */
unsigned rx_state:8; /**< rx state */
} wifi_pkt_rx_ctrl_t;

I have some questions which probably can only be answered by ESPRESSIF developers themselves.
I looked everywhere for detailed documentation regarding the values in this structure, no luck!
The ones I'm interested in are: Timestamp, and Channel. The questions:
1-What is the accuracy of the timestamp? Seconds? Milliseconds?
2-What is this timestamp based off? Epoch?
3-When exactly does this timestamp gets associated with the incoming packet?
4-Does the radio use the system-time to generate this timestamp at the time it captures the packet?

Now regarding the channel, Is this value just showing the channel the radio has been sniffing on? Or does it indicate if it's getting it from a different channel (in case of the channel width leak).
Please include as much details as possible.
Thanks!

thethinker
Posts: 53
Joined: Thu Mar 01, 2018 1:26 am

Re: Details Regarding "Received packet radio metadata header"

Postby thethinker » Sun Mar 04, 2018 9:15 pm

Any Ideas on this?

ESP_Sprite
Posts: 2843
Joined: Thu Nov 26, 2015 4:08 am

Re: Details Regarding "Received packet radio metadata header"

Postby ESP_Sprite » Mon Mar 05, 2018 1:33 am

I think these are filled in by hardware. I'll ask one of our HW engineers.

thethinker
Posts: 53
Joined: Thu Mar 01, 2018 1:26 am

Re: Details Regarding "Received packet radio metadata header"

Postby thethinker » Mon Mar 05, 2018 2:47 am

I believe that to be true as well. Thank you very much for your response. I'm looking forward for the response.

ESP_Sprite
Posts: 2843
Joined: Thu Nov 26, 2015 4:08 am

Re: Details Regarding "Received packet radio metadata header"

Postby ESP_Sprite » Mon Mar 05, 2018 4:06 am

According to the hardware engineer, the timestamp is in milliseconds and is reset to 0 when the HW MAC is reset (normally when WiFi is started I think.) He also noted there's a small bug in this field: it's only valid when the protocol is *not* the classic 802.11B. For 802.11B specifically, this field can be corrupted.

Wrt the 'channel' in the struct: I'll also ask, but I think it's the channel the radio is tuned to; as far as I remember, the channel info is not part of the 802.11 headers so I don't see how the radio could know about it.

thethinker
Posts: 53
Joined: Thu Mar 01, 2018 1:26 am

Re: Details Regarding "Received packet radio metadata header"

Postby thethinker » Tue Mar 06, 2018 1:16 am

Thank you very much for the response.
Regarding the timestamp: Is there a way to change the reference of this timestamp? Or is there a way to get notified when ever this timestamp resets to zero? Or is there a way/function to just read this reference time when ever I need?
The reason I'm trying to use this timestamp rather than time stamping sniffed data in the sniffer callback function is that this should be more accurate since it gets recorded as soon as the packet is received. But I need to be able to somehow link the difference between this timestamp and system Epoch timestamp (that gets sync to UTC time with sntp).

Regarding the Channel, yes it makes total sense, there is noway for the radio to know the channel.

thethinker
Posts: 53
Joined: Thu Mar 01, 2018 1:26 am

Re: Details Regarding "Received packet radio metadata header"

Postby thethinker » Wed Mar 07, 2018 1:30 am

Any help on this?

ESP_Sprite
Posts: 2843
Joined: Thu Nov 26, 2015 4:08 am

Re: Details Regarding "Received packet radio metadata header"

Postby ESP_Sprite » Wed Mar 07, 2018 2:38 am

I don't think there's a way to mess with the timestamp reference. I suggest you just store the timestamp from when a packet arrives plus the current time somewhere, then do some calculations to figure out the real timestamp. Same with overflowing: although there's no indicator it does this, knowing the timer overflows every 71 minutes or so should make it possible to just use an external timer to keep track of overflows.

thethinker
Posts: 53
Joined: Thu Mar 01, 2018 1:26 am

Re: Details Regarding "Received packet radio metadata header"

Postby thethinker » Wed Mar 07, 2018 2:59 am

Thank you, is there a function to just retrieve/read the value of that timer?
I think what I'm going to do it write a function so it reads the value of the timer once in a while to set the actual offset between the timer and the real time.

matteof93
Posts: 3
Joined: Sun Nov 04, 2018 1:24 pm

Re: Details Regarding "Received packet radio metadata header"

Postby matteof93 » Sun Nov 04, 2018 1:31 pm

I am in the same situation as the OP, I need to know what is the base of the clock used to fill the timestamp value in the callback registered when a packet is received and I need to know if there is any API that can be used to read or write the value of that clock.

did anyone figure out how to do that?

Who is online

Users browsing this forum: Jarml0x0F and 19 guests