ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 11205] IEEE 802.11 dissector: Add a option for disable FCS

Date: Tue, 19 May 2015 02:01:35 +0000

Comment # 6 on bug 11205 from
(In reply to jgoff from comment #5)
> @Guy
> 
> I don't know why we didn't implement radiotap (will try to find out) but the
> easiest win I see on our side is to inject either a padded fake FCS for
> these  packets (that we can handle at the dissector) or the AP can add a
> dummy FCS calculation that is correct at the time. 
> 
> The packet-capture code on Aruba side has a number of fields which are dummy
> filled for the specific case of "the capturing AP is also transmitting",
> hence we can easily handle it at the AP. As you note there is no way to flag
> this, other than perhaps a dummy 0x00 * 4 FCS inserted.

Doug seems to say you're already doing that:

> Specific case need is packet capture by Aruba Access Points (AP).  An AP
> that is capturing packets cannot actually capture its own transmitted
> frames, it has to fork off a copy of the frame on its way down the protocol
> stack for transmission.  At the time the copy is made some of the fields
> are not filled in, including the FCS.  Aruba could compute an FCS for the
> copy but that would eat up CPU cycles and it wouldn't represent what was
> transmitted anyway.  So they pad four null bytes to occupy the FCS space.
> Of course Wireshark then sees this as a "malformed packet" because the
> FCS is incorrect.

So, *if* that's what you're doing, we could check the FCS if it's non-zero but
not if it's zero.  That wouldn't require a preference.


You are receiving this mail because:
  • You are watching all bug changes.