Comment # 17
on bug 11204
from Guy Harris
(In reply to Doug Wussler from comment #14)
> So from the ERM dissectors you are doing this:
> ieee80211_handle = (find_dissector("wlan_withoutfcs")
> or this
> ieee80211_handle = (find_dissector("wlan_withfcs")
>
> Would it be possible to make the call in a way that references the value of
> the “Assume packets have FCS” checkbox in the IEEE 802.11 dissector? If you
> could do that for Type 0, 1 and 3 that would allow the end-user to decide
> how they want to deal with the missing FCS.
>
> It would still be a nice enhancement if the 802.11 dissector
There's no such thing as "*the* 802.11 dissector". There are several 802.11
dissectors:
"wlan" - this is for use with packets read from a capture file containing
802.11 packets (rather than 802.11 packets with additional radio information or
containing a snoop of "remote 802.11 traffic" such as "Peek remote" or Aruba
ERM or...). This relies on the code that reads those capture files to
indicate, in a per-frame basis, whether:
the frame has no FCS;
the frame has an FCS;
if the frame is a data frame, it has no FCS, and otherwise might have
an FCS, so the user preference is used for non-data frames (yes, that's how
Microsoft Network Monitor files work);
the frame might or might not have an FCS, so the user preference is
used.
"wlan_withfcs" - this is for use with frames that are *known* to contain an
FCS; it *always* looks for an FCS.
"wlan_withoutfcs" - this is for use with frames that are *known* not to
contain an FCS; it *never* looks for an FCS.
and there are some others.
For radiotap captures, the radiotap dissector uses the "wlan" dissector, and,
based on the radiotap header, either tells it that the frame has an FCS (if the
flags field is present in the radiotap header and indicates that there's an
FCS) or that the frame has no FCS (if the flags field is present in the
radiotap header and indicates that there's no FCS). (It should also say
"unknown, use the preference" if the flags field is absent, although anything
supplying a radiotap header without the flags field should be fixed to supply
it.)
For PPI captures, the PPI dissector hands off to the appropriate dissector
based on the link-layer header type in the PPI header, which means that it
hands off to the "wlan" dissector for 802.11 packets.
For the "Peek remote" protocol, the "Peek remote" dissector hands off to the
"wlan_withfcs" dissector, so the frames are assumed to always have an FCS.
Unless there are devices that use the "Peek remote" protocol but don't supply
the FCS, that's the correct behavior.
For the Aruba ERM protocol, currently:
for Type 0 packets, the "wlan_withoutfcs" dissector is called,
unconditionally treating the frames as having no FCS;
for Type 1 packets, the "peekremote" dissector is called, which calls the
"wlan_withfcs" dissector, unconditionally treating the frames as having an FCS;
for Type 2 packets, we just dissect them as data, as we don't support the
AirMagnet header;
for Type 3 packets, the "wlan_withoutfcs" dissector is called,
unconditionally treating the frames as having no FCS;
for Type 4 packets, the "ppi" dissector is called, which calls the "wlan"
dissector, which (at least in theory) looks at the user preference (although
whether it does so may depend on whether the actual capture file has FCSes or
not; that really needs to be fixed).
You are receiving this mail because:
- You are watching all bug changes.
