Wireshark-dev: Re: [Wireshark-dev] Expected ABI breakage with 1.6.8
From: Guy Harris <[email protected]>
Date: Mon, 21 May 2012 12:39:02 -0700
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".