Issue 106 in dpkt: Possible endianess problem in radiotap header parsing (and others?)

[dp...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 106 by hso...@gmail.com: Possible endianess problem in radiotap
header parsing (and others?)
http://code.google.com/p/dpkt/issues/detail?id=106

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),



--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[dp...@googlecode.com]

Comment #1 on issue 106 by hso...@gmail.com: Possible endianess problem in

radiotap header parsing (and others?)
http://code.google.com/p/dpkt/issues/detail?id=106

Ok... looked more closely at this and it's obviously my stupidity. Ignore...

[dp...@googlecode.com]

Comment #2 on issue 106 by hso...@gmail.com: Possible endianess problem in

radiotap header parsing (and others?)
http://code.google.com/p/dpkt/issues/detail?id=106

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.

[dp...@googlecode.com]

Comment #3 on issue 106 by hso...@gmail.com: Possible endianess problem in

radiotap header parsing (and others?)
http://code.google.com/p/dpkt/issues/detail?id=106

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

[dp...@googlecode.com]

Comment #4 on issue 106 by dick.mar...@gmail.com: Possible endianess

problem in radiotap header parsing (and others?)

https://code.google.com/p/dpkt/issues/detail?id=106

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.