On Apr 12, 2016, at 12:06 AM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:
> So the question is how to determine if the 802.11 packet has FCS or not?
>
> In that capture file, I found that only Beacon (like Frame 40) and Reassociation Response (like Frame 47) packets have the "Malformed Packet" error ( I guest Reassociation Response is the same error?).
Not setting "FCS at end" won't *necessarily* cause a "Malformed packet" error.
Most 802.11 data frames are probably IP datagrams. For an IP datagram, the IPv4 header has a field giving the total length of the IP datagram, and the IPv6 header has a "payload length" field, and the actual length of the IP payload (TCP segment, UDP datagram, etc.) is derived from *that* value, and whatever dissects the payload won't treat the FCS as part of the payload and possibly think there should be more than just 4 bytes there. So few if any data frames will get a "Malformed packet" error if "FCS at end" isn't set and, as a result, Wireshark thinks the FCS is part of the 802.11 payload.
For an 802.11 management frame, however, there's no such extra length field, and, if "FCS at end" isn't set, Wireshark will try to dissect the FCS as if it were part of the payload, and, *if* the FCS appears to be part of an IE, and the IE appears to be bigger than 4 bytes, Wireshark will keep trying to dissect the IE past the 4 bytes of FCS, and will get an error.
So it's not as if those are the only frames with an FCS; I built a version of Wireshark that forced the "FCS at end" indication to always be passed from the radiotap dissector to the radio information dissector, and thus to the 802.11 dissector, regardless of what the radiotap header said, and a whole bunch of data frames now were dissected as if they had an FCS, and, for most of them, the FCS had the right value, meaning that the chances are extremely high that they *did* have an FCS in the capture.
> But I don't think determination based on whether the packet is Beacon or Reassociation Response is good.
But they *weren't* the only ones with an FCS.
For now, just try forcing the flag on.
> Because maybe for another wireless adapter, this behavior might change.
If some, but not all, adapters supply an FCS, perhaps Npcap should just omit the Flags field as, unfortunately, the Flags field only has flag bits, not flag *presence* bits to allow a driver to say "I know whether the frame got an FCS error but I don't know whether the frame data has the FCS at the end" (and, in addition, to say, for example, "I don't know whether the frame was sent with a short preamble").
I can propose a "Flags with presence bits" field to the radiotap mailing list.