On Oct 17, 2014, at 8:25 AM, "Emburey Samrex Edward -X (emedward - EMBED UR SYSTEMS at Cisco)" <emedward@xxxxxxxxx> wrote:
> This is regd the FCS representation in the 802.11 frames.
>
> Most of the Cisco APs do have the last 4-byte of FCS, which is rightly represented in the wireshark captures.
>
> Whereas, in a recent AP, we do not include this 4byte FCS.
> So we go for the option in ‘EditàPreferencesàProtocolàIEEE 802.11àAssume packets have FCS’
> But still, wireshark treats the last 4-bytes as FCS; as a result it is shown as malformed packets.
>
> Could you please let us know about this setting.
> Like, would we need to make any other extra config, for the wireshark tool to not mark the pkts as malformed?
> OR there is a valid bug here in this setting.
> For reference I had attached the working & non-working cases of the pkt captures.
There are three flavors of 802.11 packet provided to the 802.11 dissector:
1) packets from sources that indicate whether the packet includes the FCS, such as some capture file formats;
2) packets that include metadata that indicates whether the FCS is included, such 802.11+radiotap radiotap packets;
3) packets that don't come from a source that indicates whether the packet includes the FCS.
The preference works only for packets of type 3), as it's unnecessary for packets of type 1) or 2).
The packets in your captures are coming from a source using Wildpackets' "remote Peek" protocol. Currently, those packets are treated as always including an FCS, i.e. they're treated as packets of type 1) where the indication is always "FCS is present".
*If* the protocol contains a flag bit to specify whether the FCS is included, the "remote Peek" dissector could be changed to use that flag bit. There don't appear to be any flags of that sort that differ between the two captures.
If packets sent with the "legacy" headers have an FCS and packets sent with the "802.11n" headers don't have an FCS, the "remote Peek" dissector could be changed to use that to determine whether the FCS is present.
Otherwise, the "remote Peek" dissector would have to be changed to act as a source of packets of type 3, and users would just have to change the setting as appropriate for the particular capture they're reading.
