On May 21, 2012, at 12:02 PM, Balint Reczey wrote:
> Please do not release 1.6.8 in its current state or bump library version to 2.0.0 for libwireshark. Using 1.1.8 is misleading as 1.6.8 breaks the ABI:
> http://rbalint.cs.bme.hu/ws-ABI-1.6.7-1.6.8/libwireshark/abi_compat_report.html
Summary:
The data_rate field in the struct ieee_802_11_phdr structure grew from 8 bits to 16 bits.
This was a fix for bug 7134:
r42123 | alagoutte | 2012-04-18 00:22:12 -0700 (Wed, 18 Apr 2012) | 14 lines
Changed paths:
M /trunk/wiretap/wtap.h
From Colus Tang via https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7134
Unable to display the correct IEEE802.11 MCS data rates due to header definition
The problem is due to the ieee_802_11_phdr.data_rate is defined as guint8,
since this variable is counting number of 0.5Mbps units, any datarates which is
higher than 255Mbps would get wrapped up. In the above example, only the lower
8bit value will be put into the ieee_802_11_phdr which is 0x04 and result in
the incorrect 2Mbps display.
There are 802.11n WLAN product is capable to transmit @450Mbps, we should fix
this data_rate from guint8 to guint16.
#BACKPORT
This does *NOT* affect radiotap captures or any other captures where the 802.11 information is presented as a header at the beginning of the packet data. It affects OmniPeek captures as they currently use ieee_802_11_phdr (which prevents some items in OmniPeek's radio data from being presented).
I'd say "un-backport and require anybody who wants full 802.11n support in OmniPeek captures to upgrade to 1.8".