On May 28, 2014, at 6:54 AM, Alexis La Goutte <alexis.lagoutte@xxxxxxxxx> wrote:
> The header for “IEEE 802.11 QoS Data” under “AiroPeek/OmniPeek encapsulated IEEE 802.11” is found to be of 28 bytes in length. Whereas the same ““IEEE 802.11 QoS Data” under default decoding is 26 bytes for “LLC” packets. This leads to the fist 2 bytes of LLC to go wrongly under “IEEE 802.11 QoS Data”, which in turn leads to LLC DSAP as unknown and Wireshark is not able to identify EAP/EAPOL packets.
The problem is that the PEEKREMOTE dissector is calling the "wlan_datapad" dissector, which assumes that there's padding between the 802.11 header and the 802.11 payload if the 802.11 header's length isn't a multiple of 4 bytes.
Calling the "wlan" dissector, which makes no such assumption, fixes the dissection.
*However*, doing so would, apparently, *break* other dissections. The first two checkins for that dissector were:
------------------------------------------------------------------------
r23852 | jmayer | 2007-12-12 15:26:39 -0800 (Wed, 12 Dec 2007) | 3 lines
The extra bytes seem to go away if I call wlan_datapad instead
of wlan.
------------------------------------------------------------------------
r23851 | jmayer | 2007-12-12 15:03:44 -0800 (Wed, 12 Dec 2007) | 4 lines
Beginnings of airopeek remote capture support.
The metainformation is not yet decoded, also, there
are problems with QoS frames (extra bytes).
------------------------------------------------------------------------
Joerg, do you have any of the captures where wlan_datapad was necessary, so we can try to figure out if there's any obvious indication as to whether the padding is present (e.g., one of the bits in the flags or status fields)?
