On Mar 20, 2014, at 8:37 AM, Hadriel Kaplan <hadrielk@xxxxxxxxx> wrote:
> I think the Prism dissector is being called, but then it hands it to normal 802.11 instead. I don't know anything about Prism packets, but the wireshark code appears to expect the Prism message codes (either 0x00000044 for type 1, or 0x00000041 for type 2) to be in little-endian order on-the-wire, whereas your packet has it in network-order (ie, big-endian) on-the-wire.
Actually, they're not "on-the-wire" at all - the Prism header is radio-level-information metadata generated by and written to the packet buffer by the driver.
So the byte order might depend on the driver and the CPU type; he said "mips" - there are both big-endian and little-endian MIPS systems, so perhaps
1) this was a big-endian MIPS system
and
2) the drivers put the Prism header in host byte order
in which case we need to have the Prism code support both byte orders.
(Yet another reason not to like Prism headers; radiotap:
http://www.radiotap.org
specifies little-endian byte order, so a non-buggy driver would write out the radiotap header in little-endian order *even when running on a big-endian machine*.)