Comment # 9
on bug 11204
from Doug Wussler
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.
You are receiving this mail because:
- You are watching all bug changes.