Hi Guy, Alexis,
I think, I should have mentioned this earlier.
There does exist two different headers: a 20-byte (legacy) and a 55-byte (with additional, 802.11n support)
To accommodate the 802.11n header, we would need a different dissection at
dissect_peekremote(), apart from the way legacy header had been dealt.
May be, we can have the ‘magic number’ as reference from the obtained hex-dump, to choose between the two dissection methods.
PFA the difference in dissection that omnipeek performs on a 20-byte and a 55-byte header.
(compare_80211n_legacy_omnipeek.png)
I believe it helps in the classification of fields to be done at
dissect_peekremote().
Please let me know your further queries/comments.
Once clear, I’ll go ahead to file a bug, with all these snaps & pkt captures.
Thanks and Regards,
Emburey
