Why does my Ath9k generate RadioTap headers seem distorted?

Question

I compile 802.11 packets using scapy on Ubuntu 16.04 (kernel 4.4). The RadioTap headers for my packages have the following current flags:

present=TSFT+Flags+Rate+Channel+dBm_AntSignal+b14+b29+Ext 

Given the description of RadioTap, I expect Channel to start on the 10th byte after the header and the preceding fields (8 for TSFT + 1 for Flags and Rate). The channel has an alignment of 2, so there is no need for filling. However, this is what is in the unencrypted part of the package:

 notdecoded=' \x08\x00\x00\x00\x00\x00\x00f\xc0 \x02\x00\x00\x00\x00\x10\x02l\t\xa0\x00\xa9\x00\x00\x00\xa9\x00' 

In this case, the channel number actually appears in bytes 18-19 ('l \ t' = 2412), and im not sure exactly what bit the dBm signal level contains.

Does anyone have an idea about what I'm missing?

Answer 1

Found the answer after going deep into the specification a little deeper:

Scapy does not parse extended headers denoted by bit-32 (although he told me about them by specifying + Ext above). These additional headers are populated on the front of the "non-decoded" section of the packet. I think scapy should, at a minimum, remove these extended headers from non-decoded ones to avoid confusion in the future.

In this particular case, there are two additional 32-bit extended bitmap headers that take into account the additional 8 bytes.

If someone wants to write an answer in more detail, do not agree well with it, otherwise I will clear this answer and accept it forever.