Why do my ath9k generated RadioTap headers seems malformed?

Question

I'm collecting 802.11 packets using scapy on Ubuntu 16.04 (4.4 kernel). The RadioTap headers for my packets have the following present flags:

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

Given the description of RadioTap, I would expect Channel to start on the 10th byte following the header and preceding fields (8 for TSFT + 1 each for Flags and Rate). Channel has an alignment of 2, so there is no need for padding. Yet this is what is in the undecoded portion of the packet:

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 at bytes 18-19 ('l\t' = 2412), and im not sure exactly what byte contains the dBm signal strength.

Anyone have an idea as to what i'm missing?

Answer 1

Found the answer after digging into the spec a bit deeper:

Scapy doesn't parse extended headers as signified by bit-32 (though it did tell me about them by stating +Ext above). Those extra headers are stuffed on the front of 'notdecoded' section of the packet. I think scapy should, at minimum, remove those extended headers from not-decoded to avoid future confusion.

In this particular case there are two extra 32 bit extended bitmap headers, accounting for the extra 8 bytes.

If someone wants to write an answer up with more detail, ill accept it, otherwise i will clean this answer up and accept it for perpetuity.