802.11 beacons showing corrupted SSIDs

[guyharris]

Converted from SourceForge issue 2825019, submitted by horsepunchkid

For some beacon packets, tcpdump's 802.11 printer fails to print the SSID correctly. Sometimes it's blank, sometimes truncated, sometimes junk characters. I traced this to parse_elements(pbody) parsing the SSID field correctly but then erroneously finding further SSID fields, overwriting the good data with junk. That it's finding additional SSID fields seems to either indicate bad packets or that some other part of the parsing is going wrong. The attached raw dump might help track down the problem. The SSIDs are visible with -X at the end of 0x0000 and beginning of 0x0010. You'll see at least three different networks in this dump whose beacons are consistently parsed incorrectly.

The attached patch is probably not the right fix, but it works: just ignore additional SSID fields if the SSID has already been found.

[guyharris]

Submitted by horsepunchkid

This artifact has been marked as a duplicate of artifact 2543416 with reason: Same root cause, different symptom

[guyharris]

Submitted by guy_harris

Nope, NOT the same root cause.

The root cause of 2543416 was that the printer wasn't stopping before the FCS, and was parsing the FCS as if it were part of the payload.

The root cause of this is that the packets are cut short by a snapshot length, and the printer isn't stopping at the snapshot length.

[guyharris]

Submitted by guy_harris

At the end of frame 8's data, there are 5 bytes: 00 0c 12 18 60. That frame has a radiotap header, but the flags field does NOT have the "FCS present at end" bit set, so neither tcpdump nor Wireshark believe the frame has the FCS in the last 4 bytes. Furthermore, the frame is claimed to have been 474 bytes long on the network, with only the first 94 bytes of the frame captured.

The 00 looks, to both tcpdump and Wireshark, to be the first byte of an SSID.

What version of what OS did you capture this on? What type of network adapter did you capture on?

[guyharris]

Submitted by guy_harris

I've checked in a change to save the first, rather than the last, IE of a given type (except for zero-length rates IEs, which are ignored - some devices seem to put a zero-length rates IE into frames, followed by the right rates IE). That should address this problem (the frames are still bad, so they're reported as such, with [|802.11]).

[guyharris]

Submitted by horsepunchkid

Thanks for looking into this, Guy. This was on an OLPC XO-1, with its delightfully quirky setup. It's a Marvell 88W8388 and a linux kernel; which version, I'm not sure, but I can find out.

That said, I'm pretty sure I had the same problem with a capture done on a Toshiba tablet with a Prism card of some kind. I can verify (or unverify) that, if it would be helpful.

[guyharris]

Submitted by horsepunchkid

I just pulled and built the latest sources, and it is indeed working fine with the dump I had that was giving bad output earlier. Thanks again for the fix! Is there a timeline for the next release?

[guyharris]

Submitted by guy_harris

We'll probably be putting out a release candidate this Wednesday, with a final release early next week, at least according to Ken Bantoft's recent mail to the tcpdump-workers mailing list.