Guard Interval is not consistent between Radiotap & wlan_radio

This issue was migrated from bug 12123 in our old bug tracker.

Original bug information:

Reporter: Thomas Baudelet
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: All
Platform: All
Version: 2.0.1

Attachments:

TwoPacketsBug.pcapng: 2 packets with values inverted Long & Short for radiotap & wlan_radio
: Screenshot with values hilighted

Thomas Baudelet said:

Created attachment 14326 2 packets with values inverted Long & Short for radiotap & wlan_radio

Build Information: Version 2.1.0-1833-g35ef16bc (v2.1.0rc0-1833-g35ef16bc from unknown)

Copyright 1998-2016 Gerald Combs <gerald@‍wireshark.org> and contributors. License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with Qt 5.3.2, with libpcap, without POSIX capabilities, with libz 1.2.5, with GLib 2.36.0, with SMI 0.4.8, without c-ares, without ADNS, with Lua 5.2, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with QtMultimedia, without AirPcap.

Running on Mac OS X 10.11.3, build 15D21 (Darwin 15.3.0), with locale C, with libpcap version 1.5.3 - Apple version 54, with libz 1.2.5, with GnuTLS 2.12.19, with Gcrypt 1.5.0. Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz (with SSE4.2)

Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00).

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

It appears that all captures made on my OS X with radiotap headers have inconsistent values for the Guard Interval between radiotap.mcs.gi & wlan_radio.11n.short_gi

They are systematically inverted, cf pcap attached.

As a consequence, the data rate in radiotap & wlan_radio are always different (radiotap.datarate & wlan_radio.data_rate)

Which one should I trust?

added libwireshark version2.0 labels

Thomas Baudelet said:

Created attachment 14327 Screenshot with values hilighted

Gerrit Code Review said:

Change 13950 had a related patch set uploaded by Guy Harris: Correctly set the "short GI" flag in the generic radio information structure.

https://code.wireshark.org/review/13950

Gerrit Code Review said:

Change 13950 merged by Guy Harris: Correctly set the "short GI" flag in the generic radio information structure.

https://code.wireshark.org/review/13950

Gerrit Code Review said:

Change 13951 had a related patch set uploaded by Guy Harris: Correctly set the "short GI" flag in the generic radio information structure.

https://code.wireshark.org/review/13951

Gerrit Code Review said:

Change 13951 merged by Guy Harris: Correctly set the "short GI" flag in the generic radio information structure.

https://code.wireshark.org/review/13951

Guy Harris said:

(In reply to Thomas Baudelet from comment #0)  
> Which one should I trust?  

Prior to the fix, trust the radiotap one if you have a radiotap header; otherwise, trust the wlan_radio one.

With the fix, if you have a radiotap header, trust either one, as they're the same, otherwise trust the wlan_radio one as there's no radiotap one available *to* trust.

Guy Harris said:

(In reply to Guy Harris from comment #6)  
> (In reply to Thomas Baudelet from comment #0)  
> > Which one should I trust?  
>  
> Prior to the fix, trust the radiotap one if you have a radiotap header;  
> otherwise, trust the wlan_radio one.  
>  
> With the fix, if you have a radiotap header, trust either one, as they're  
> the same, otherwise trust the wlan_radio one as there's no radiotap one  
> available *to* trust.  

And you can trust either one for 11ac; the bug was just in the 11n code.

Thomas Baudelet said:

You're awesome, many thanks Guy

closed