Wireshark-dev: Re: [Wireshark-dev] Get "Malformed Packet" for 802.11 Beacon frames on Windows
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Yang Luo <hsluoyb@xxxxxxxxx>
Date: Wed, 13 Apr 2016 09:27:44 +0800
Hi Guy,

On Wed, Apr 13, 2016 at 1:01 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
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.

I changed Flags to include IEEE80211_RADIOTAP_F_FCS like below:

------------------------------------------------------------------------------------------
// [Radiotap] "Flags" field.
// The packet doesn't have FCS. We always have no FCS for all packets currently.
if (FALSE)
{
pRadiotapHeader->it_present |= BIT(IEEE80211_RADIOTAP_FLAGS);
*((UCHAR*)Dot11RadiotapHeader + cur) = 0x0; // 0x0: none
cur += sizeof(UCHAR) / sizeof(UCHAR);
}
else // The packet has FCS.
{
pRadiotapHeader->it_present |= BIT(IEEE80211_RADIOTAP_FLAGS);
*((UCHAR*)Dot11RadiotapHeader + cur) = IEEE80211_RADIOTAP_F_FCS; // 0x10: frame includes FCS

// FCS check fails.
if ((pwInfo->uReceiveFlags & DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE) == DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE)
{
*((UCHAR*)Dot11RadiotapHeader + cur) |= IEEE80211_RADIOTAP_F_BADFCS; // 0x40: frame failed FCS check
}

cur += sizeof(UCHAR) / sizeof(UCHAR);
}

------------------------------------------------------------------------------------------

The even I don't switch on Monitor Mode, all 802.11 data packets captured by Wireshark are all WRONG (shown as "Malformed Packet").
The capture is:

So I'm afraid forcing Flags on is not a good solution.

Then I just don't provide the radiotap Flags by commenting all the above code. Surprisingly, I still see the "Malformed Packet" error.
See the following capture file: (like Frame 18)
So I think this error is not caused by FCS? Could it be a bug in Wireshark?

 

> 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.

I know what you mean. You want to set the every single bit in radiotap Flags respectively. Because Npcap can only tell whether it's IEEE80211_RADIOTAP_F_BADFCS or not. But it can't tell whether it's IEEE80211_RADIOTAP_F_FCS. However, radiotap Flags need to be set all bits if provided.
Proposal to radiotap community is good. But is it possible to change the Radiotap protocol standard? I thought it's a industrial de facto standard adopted by many companies and open-source communities? I never doubt Wireshark will follow the latest standard, but other players won't be so happy about this minor change I think.. If there is a way to propose this feature without impacting backward compatibility, it will be good.


Cheers,
Yang

 
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe