Re: Get "Malformed Packet" for 802.11 Beacon frames on Windows

[Yang Luo <hsluoyb () gmail com>]

Hi Guy,

On Wed, Apr 13, 2016 at 1:01 AM, Guy Harris <guy () alum mit edu> wrote:

> On Apr 12, 2016, at 12:06 AM, Yang Luo <hsluoyb () gmail com> 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:
https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_data_error_with_fcs.pcapng.gz

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)
https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_beacon_error_without_flags.pcapng.gz
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 () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe