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

[Guy Harris <guy () alum mit edu>]

On Apr 12, 2016, at 9:57 PM, Yang Luo <hsluoyb () gmail com> wrote:

> On Wed, Apr 13, 2016 at 10:11 AM, Guy Harris <guy () alum mit edu> wrote:
>
> > On Apr 12, 2016, at 6:27 PM, Yang Luo <hsluoyb () gmail com> wrote:
> >
> > > The even I don't switch on Monitor Mode,
> >
> > Monitor mode is off, but you're getting 802.11 headers?
>
> Yeah. Maybe this is a difference between Windows and Linux. I don't know how 802.11 header capture and Monitor mode 
> are bound together. But for Windows, these two things can be separated.
> In fact, there are three conditions.
> 1) Npcap driver is bound above Native W-Fi interface (aka using normal version Npcap) + ExtSTA Mode ------------> 
> Fake Ethernet packets
> 2) Npcap driver is bound below Native W-Fi interface (aka using -wifi version Npcap) + ExtSTA Mode ------------> 
> 802.11 data packets
> 3) Npcap driver is bound below Native W-Fi interface (aka using -wifi version Npcap) + NetMon Mode ------------> 
> 802.11 data + control + management packets
>
> You probably notice there's a 4) condition (normal Npcap + NetMon Mode), I actually didn't test this condition. But 
> we can easily guess that there will be NO packets captured at all. So 4) is invalid.
>
> You can view he binding operation of Npcap driver (above or below Native W-Fi interface) as a configuration of Npcap 
> driver. And this configuration needs to be built with the driver. This means I can't switch between fake Ethernet and 
> 802.11 headers for wireless adapter capture for the same Npcap driver. This is why I provide two Npcap versions, one 
> normal version (like npcap-nmap-0.06-r14.exe), and one -wifi version (like npcap-nmap-0.06-r14-wifi.exe).
>
> > So which of these modes are you operating in?  Extensible Access Point (ExtAP) Operation Mode, Extensible Station 
> > (ExtSTA) Operation Mode, or Network Monitor (NetMon) Operation Mode?
> >
> >         https://msdn.microsoft.com/en-us/library/ff560671(v=vs.85).aspx
>
> I only focus on two modes now: 
> 1) ExtSTA Mode (aka Managed Mode in Linux terminologies)
> 2) NetMon Mode (aka Monitor Mode in Linux terminologies)
>
> When I said "switch on Monitor Mode", I mean put the wireless adapter from ExtSTA Mode to NetMon Mode.
> When I said "switch off Monitor Mode", I mean put the wireless adapter from NetMon Mode to ExtSTA Mode.
>
> Actually I didn't touch ExtAP Mode yet (aka Master Mode in Linux terminologies). How does Wireshark (or libpcap or 
> Linux kernel) behave in Master Mode on Linux? Should see 802.11 packets or Fake Ethernet? If 802.11 packets, then all 
> packets should be seen like data + control + management? I want to keep the same behavior on Windows with Linux and 
> other systems.
>
> > > 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 force it off if you're not running in Network Monitor Operation Mode and on if you are.
>
> > > Then I just don't provide the radiotap Flags by commenting all the above code. Surprisingly, I still see the 
> > > "Malformed Packet" error.
> >
> > Why is that a surprise?  I didn't say that doing so would fix the problem.  All it does is, *IF* there is no 
> > guarantee that, in monitor mode, you will always have the FCS - for example, if some drivers supply it and some 
> > drivers don't - the 802.11 preference "Assume frames have FCS" will work, so that, *if* the packets in a capture 
> > file all have an FCS, the user would turn the preference on for that capture file, and *if* they don't, the user 
> > would turn the preference off for that capture file.
>
> Maybe there's a little mess here. Let me clarify the current situation (four captures):
>
> 1) Capture 1: NetMon Mode, Radiotap "Flags" field is forced OFF:
> https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_beacon_error.pcapng.gz

With that one, you get malformed packets because the frames have an FCS but the radiotap header says they don't.

If I change Wireshark to force the "FCS at end" flag on in the radiotap dissector, which makes it look as if the flag 
had been forced ON, there are some malformed frames - but the only one that isn't also malformed in a standard 
Wireshark is frame 21324.

So, with the possible exception of frame 21324, it appears that all the validly-captured frames in that capture have an 
FCS.  However, that frame might be a short frame - it doesn't seem to have enough octets to be a valid Measurement 
Pilot frame, but we don't dissect it, as it's encrypted, so we don't detect that.  The short frame might be the result 
of the radio failing to capture the entire frame.

> 2) Capture 2: ExtSTA Mode, Radiotap "Flags" field is forced ON:
> https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_data_error_with_fcs.pcapng.gz

With that one, you get complaints because the frames appear *not* to have an FCS but the radiotap header says they do.

If I change Wireshark to force the "FCS at end" flag off in the radiotap dissector, which makes it look as if the flag 
had been forced OFF, there is one malformed frame - but that's either an HTTP error or an error in the HTTP dissector.

So perhaps the correct answer is:

        NetMon mode, force the "FCS at end" flag *ON*;

        ExtSTA mode, force the "FCS at end" flag *OFF*.

*However*:

        https://msdn.microsoft.com/en-us/library/windows/hardware/ff548626(v=vs.85).aspx

says

        uReceiveFlags

            The attributes of the received packet data specified through a bitmask. 

            If the miniport driver is operating in ExtSTA mode, the driver must always set uReceiveFlags to zero.

            The following flag values are valid for the miniport driver if is operating in NetMon mode.

            DOT11_RECV_FLAG_RAW_PACKET

                If this bit is set, the packet contains the data as it was originally received by the 802.11 station. 
For more information about raw packets, see Indicating Raw 802.11 Packets.

So it might be that "Raw 802.11" packets have the FCS and non-"Raw 802.11" packets don't - at least with the adapter 
you're using.

What happens if you turn "FCS at end" on for packets with DOT11_RECV_FLAG_RAW_PACKET set and turn it off for packets 
with DOT11_RECV_FLAG_RAW_PACKET not set?

> 3) Capture 3: NetMon Mode, Radiotap "Flags" field is NOT PROVIDED:
> https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_beacon_error_without_flags.pcapng.gz

If I turn the "Assume packets have FCS" preference on for the IEEE 802.11 protocol, it shows at least some frames with 
an FCS that's correct.

> 4) Capture 4: NetMon Mode, Radiotap "Flags" field is forced ON:
> https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_acknowledge_error_fcs-on_at_monitor-mode.pcapng.gz
>
> So the conclusion for me is, whether I provide Radiotap "Flags" or not, if provided, ON or OFF, there will always be 
> errors.

That's what happens in monitor mode - even frames that couldn't be correctly received may be provided by the adapter in 
monitor mode, when they would have been discarded in other modes.

If *none* of those four captures provided the Flags field

> Maybe I should just find a way to determine whether FCS is there using a Windows API (if possible)?

See above.  Look at the DOT11_RECV_FLAG_RAW_PACKET flag.

> > > So I think this error is not caused by FCS?
> >
> > No, it's caused by the presence of an FCS; you somehow need to convince Wireshark of that.
>
> Does Wireshark have other FCS determination measures for 802.11 packets other than Radiotap "Flags" field?

No.

> Because 3rd capture shows that there are still errors even Npcap doesn't provide the Radiotap "Flags" field.

As I said above, in monitor mode, you may get frames that weren't fully received, due to radio-level errors, and 
they'll get errors no matter *what* you do.

Unfortunately:

        1) there doesn't seem to be a way to find out from the Windows driver whether a packet wasn't fully received 
(if the radio gives up before the FCS is received, it wouldn't even bother checking the FCS, so it wouldn't be reported 
as an FCS error)

and

        2) there doesn't seem to be a way to indicate that in radiotap anyway

so there's nothing you can do about that.

(I've seen the same thing on OS X and Linux.)

> > Try forcing the "FCS at end" flag on only if WinPcap has been told to run in monitor mode.
>
> See the above 4th capture, there're still errors. Like Frame 276 (802.11 Acknowledgement) and Frame 496 (802.11 
> Action).

Again, see above.

I'll ask about this on the radiotap list.

You probably want to subscribe to that list; see the information on

        http://www.radiotap.org
___________________________________________________________________________
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