The recent change introduced in 0.10.1 of fcs_len in 802.11 parsing is
causing packets to be interpreted as malformed. The most I was able to
figure out was the following:
802.11 NIC provides packets with CRC (and prism header)
802.11 Preferences indicates to assume packets have CRC
When running tethereal, packets are decoded correctly - fcs_len
parameter contains some number which looks like the packet length,
which means to check wlan_check_fcs, which is 1, and therefore
is decoded correctly.
When running ethereal, packets are initially decoded correctly, as
explained above. However, every time you place the cursor on
top of the packet, it is re-dissected again, at which time
fcs_len equals 0, which means no FCS, and is therefore decoded
incorrectly.
Correction - When running tethereal with -V, it appears to do the same
thing as running ethereal.
What happens is that the last 4 bytes are not taken to be CRC, which
causes the dissection to be malformed.
I was unable to trace back who calls the dissection the second time, but
if someone would point that out to me, I will be able to further check.
Also attached is a capture of one packet that shows the problem.
If anybody can help, I would appreciate it. Also, please cc me
directly, as I'm not a member of the list.
--
Dvir Oren
Extricom Ltd.
Glil Yam, Herzlia 46905, Israel
Email: dvir@xxxxxxxxxxxx
Tel: +972-9-9569522 #201
Fax: +972-9-9569557
Attachment:
malformed_beacon.pcap
Description: Binary data