Possible endianess problem in radiotap header parsing (and others?)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use dpkt to parse packets captures with pypcap using airmon-ng on a wireless 
interface.
2. When using the radiotap.Radiotap class to parse the packet, the length seems 
to be read incorrectly, using native byte order rather than network order.

What is the expected output? What do you see instead?
Packet starts with 0x00 0x00 0x12 0x00, so packet length field should be 18 
(0x0012), but instead is read as 4608 (0x1200).

What version of the product are you using? On what operating system?
dpkt version 1.7. 
running on Ubuntu 13.04.

Please provide any additional information below.
Seems like the issue is in radiotap.py at line 75:
        ('length', 'H', 0),

which should read something like:
        ('length', '>H', 0),

Original issue reported on code.google.com by hso...@gmail.com on 15 Apr 2013 at 1:13

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok. Still seems to be a bug, but I mixed up the endianess. Radiotap is 
little-endian, so it's the fact that dpkt.Packet.unpack uses big endian that 
seems to be the problem.

Original comment by hso...@gmail.com on 15 Apr 2013 at 1:49

[GoogleCodeExporter]

Currently fixed by me (on r88 version) by adding the line:
__byte_order__ = "<"
at line 69 in radiotap.py

Original comment by hso...@gmail.com on 15 Apr 2013 at 2:39

[GoogleCodeExporter]

I have the same issue when using linux 3.16.4-200.fc20.x86_64 and pypcap.

using the following script:
import dpkt, pcap
pc = pcap.pcap('mon0')
while 1:
    p = pc.next()
    if pc.datalink() == 127:
        ts, pkt = p
        tap = dpkt.radiotap.Radiotap(pkt)

tap.data is always empty and tap.length is 4608.

Setting __byte_order__ in Radiotap fixes the issue for me. Please fix.

Original comment by dick.mar...@gmail.com on 15 Oct 2014 at 6:28