Bugzilla – Bug 979
Multi-octet fields in Wi-Fi headers have wrong endianness
Last modified: 2010-09-03 05:05:21 EDT
In the serialisation and deserialisation of various multi-octet fields within frames constructed and deconstructed by the wifi module, conversion between host and network byte order, and vice versa, is applied. Unfortunately, IEEE 802.11 does not follow the standard network byte order - instead multi-octet fields are serialised in a little endian fashion. Section 7.1.1 of IEEE Std. 802.11-2007 makes this clear: "In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k + 1 bits. The octet boundaries within a field can be obtained by taking the bit numbers of the field modulo 8. Octets within numeric fields that are longer than a single octet are depicted in increasing order of significance, from lowest numbered bit to highest numbered bit. The octets in fields longer than a single octet are sent to the PLCP in order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits." I believe the attached patch addresses the problem in the wifi module, though I expect (but have not confirmed) it to cause regression test failures for those tests which compare PCAPs. I note that FlameHeader does similar conversions for the Protocol and Sequence Number fields. I'm not familiar enough with FLAME to know whether this is wrong, but I suspect that it is. I haven't addressed this in the attached patch.
Created attachment 967 [details] First attempt at a patch for this bug in the wifi module
I confirm this bug. It can be reproduced by running examples/wireless/wifi-wired-bridging, opening wifi-wired-bridging-0-2.pcap, and then looking at the timestamp field in beacon frames. For example, the first timestamp is read by wireshark as 0x0090010000000000, but it should actually be read as 0x0000000000019000. Note that not all wifi headers are affected: for example wifi-mac-headers.cc are already using WriteHtolsb and ReadLsbtoh. Dean, thanks for the good work, as usual! The patch is ok for me; if you think no further work is needed to fix this, you have my +1 to commit.
(In reply to comment #2) > For example, the first timestamp I actually meant the timestamp of the second beacon frame in the trace.
(In reply to comment #2) > ...if you think no further work is needed to fix this, you have my +1 to > commit. In comment #1 I noted that: > ...FlameHeader does similar conversions for the Protocol and Sequence > Number fields. I'm not familiar enough with FLAME to know whether this is > wrong, but I suspect that it is. I haven't addressed this in the attached > patch. Who knows about FLAME? Can someone comment on whether a change is needed there, too?
(In reply to comment #4) > Who knows about FLAME? Can someone comment on whether a change is needed there, > too? In the absence of information on FLAME I'm going to assume the current endianness is correct. I've thus pushed the fix for the wifi module, and the associated updates to regression traces. The relevant changesets are 6602:0aae670ceff3, 6603:cbbc605cbe5b, and 6604:81c69049bdab on ns-3-dev, and 130:1b0a4ffea208 on ns-3-dev-ref-traces.