On 5/21/12 12:39 PM, Guy Harris wrote:
>
> 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".
Done in r42757. Balint, can you check the updated ABI on your end?
--
Join us for Sharkfest ’12! · Wireshark® Developer and User Conference
Berkeley, CA, June 24-27 · sharkfest.wireshark.org