The Aruba ERM Type 1 Dissector inconsistent with Type 0 and Type 3
This issue was migrated from bug 11204 in our old bug tracker.
Original bug information:
Reporter: Doug Wussler
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: All
Platform: All
Version: 1.12.5
Attachments:
ERM_Dissectors.pdf: Screen shots showing FCS for Type 1 and absence of FCS for Type 3
ERM_Type1.pcapng: This is an ERM Type 1 Packet Capture
ERM_Type0.pcapng: This is ERM Type 0 packet capture
ERM_Type3.pcapng: This is ERM Type 3 packet capture
See also: Issue #9880 (closed)
Activity
Created attachment 13612 Screen shots showing FCS for Type 1 and absence of FCS for Type 3
Build Information: Version 1.12.5 (v1.12.5-0-g5819e5b1 from master-1.12)
Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2, without Kerberos, with GeoIP, with PortAudio V19-devel (built May 12 2015), with AirPcap.
Running on 64-bit Windows 8.1, build 9600, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap. Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, with 8097MB of physical memory.
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark is Open Source Software released under the GNU General Public License.
Check the man page and http://www.wireshark.org for more information.
The Aruba ERM dissectors for Types 0 and 3 make a different decision for handling the FCS than the dissector for Type 1 even though there is no difference in the way ERM packages the packets. This issue is compounded by a bug on the Aruba side which fails to include the FCS with certain frames. Dissectors for Types 0, 1 and 3 should all handle the FCS the same way.added libwireshark version1.12 labels
-
Change 8569 had a related patch set uploaded by Alexis La Goutte: Aruba ERM: Fix FCS for Type 3
-
(In reply to Doug Wussler from comment #7) > (In reply to Gerrit Code Review from comment #6) > > Change 8569 had a related patch set uploaded by Alexis La Goutte: > > Aruba ERM: Fix FCS for Type 3 > > > > https://code.wireshark.org/review/8569 > > How about Type 0, will that get the same fix? Like commit message say, no there is no solution for type 0 (no information about determine if TX or RX frame...) -
I would like to make some comments about this proposed fix. I am not an experienced C programmer and I am new to this forum so I hope you will bear with me and not take offense if I say something silly. I really mean well.
It seems this fix has gone in a different direction than we had originally discussed. The original problem was inconsistent behavior in the various dissectors. Type 1 assumed the FCS, Types 0 & 3 ignore the FCS. Inconsistent behavior seems like a legitimate “bug” to me. The correct behavior, from the standpoint of an 802.11 dissector would be to assume the FCS is there, or even better yet, to support the “Assume packets have FCS” checkbox at “Edit | Preferences | Protocols | IEEE 802.11”.
I would argue that a base fix for the current situation would be to change Types 0 & 3 to assume the FCS. That would seem simple to do. Then, if there was some issue with the way the packets were delivered, at least we would see the same problem in all Types.
What I see here is a valiant attempt to modify the dissector for Type 3 to account for a bug in the Aruba software. Unfortunately, this does nothing to address the problem with Type 0. And what if at some later time Aruba changes the default Signal value it plugs in for a TX frame? That would completely break the proposed fix. I would argue against trying to implement compensating behavior at the Wireshark end rather than fixing each end to conform with a known protocol.
So, ideally, what I think would be the preferred solution would be to check the FCS in all Types. This will fix Type 0 & 3. If this is all we do it is a vast improvement and preferable to the proposed change. And then, if we really want to make things right, we could either modify ieee80211 to make the FCS validation optional, or, as Guy suggested, simply not report a validation failure if the FCS bytes are zeros.
-
Hi Doug, "Assume packets have FCS" will be no work, it check if frame is data (and FCS is set on RX and no set for TX). it is worse, if you say "always have FCS"... If Aruba change the value of signal, yes, the fix will be broken.. and Jeff see with R&D to add FCS on all frame (TX & RX) and when i will be available add a preference to disable this hack I work also to add option to disable FCS check -
Alexis - I completely understand that Aruba delivers the FCS for RX and not for TX. This is true for all Types: 0, 1 and 3. And that is an Aruba bug, not something we should try to fix in Wireshark.
The REAL problem in Wireshark is that the dissectors do not behave consistently. Your proposed fix is going to make them even more inconsistent because now all three Types will have different behavior.
From the perspective of a Wireshark analysis it is vastly better if all three Types behave similarly. If all three assume the FCS then we will see the same set of "malformed packets" and understand what we are seeing. Then, when Aruba starts delivering the FCS in TX, as they should, all three dissectors will still report "malformed packets" but it will be due to an invalid FCS. This will again be something we can understand and, if we want, can adjust in our approach to FCS validation.
-
I need to check but if you say always have a FCS for frame with no FCS, the dissection is incorrect.
I prefer add a comment to say "Don't use Type 0, it is buggy, prefer type 3..." for peek type, i have may be a idea (add signal check to but no don't break peek dissector for Cisco...)
-
Alexis - That is the way Type 1 currently works. It assumes there is always an FCS and it reports "malformed packets". Type 0 is not "buggy". There are two bugs: 1. Aruba: Aruba AP does not include FCS bytes on frames transmitted by a capturing AP. Let's not try to compensate for that in Wireshark. Let's fix that on the Aruba end. 2. Wireshark: ERM Type 1 dissector handles FCS differently than Types 0 and 3 even though there is no difference in the way the FCS bytes are delivered by Aruba. The fix to this is to call Type 0 and Type 3 "withFCS" instead of "withNoFCS". -
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 made FCS validation optional, just as we do for the CRC in TCP, UDP and IP.
-
(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") It is worse All packet with no FCS is display "malformed" and the dissection is incorrect... And FCS check don't display expert info (only a [incorrect...]) -
(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). -
(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. By which you mean "allow the end-user to decide which not-always-correct behavior they want"; the problem isn't, as far as I can see, that the FCS is always missing or always present, the problem is that the FCS is always present on frames received by the Aruba device and always absent on frames transmitted by the Aruba device, and that there's no "Tx vs. Rx" flag in any of the flavors of metadata headers, so, unless *all* frames are transmitted or *all* frames are received, you're *guaranteed* to have at least one frame misdissected. You can't fix that with a global preference such as "Assume packets have FCS".