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

[Yang Luo <hsluoyb () gmail com>]

Hi Guy,

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

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

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

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.

Maybe I should just find a way to determine whether FCS is there using a
Windows API (if possible)?
I have asked this question on both Stackoverflow and MSDN, still no replies.
http://stackoverflow.com/questions/36566978/how-to-determine-whether-a-802-11-raw-packet-has-fcs-4bytes-in-a-ndis-6-filter
https://social.msdn.microsoft.com/Forums/vstudio/en-US/8de141e8-413c-499c-9335-a5d3b2cf4bdd/how-to-determine-whether-a-80211-raw-packet-has-fcs-4bytes-in-a-ndis-6-filter-driver?forum=wdk


> If you turn the preference on, then...
>
> > 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
>
> frame 18 of that file dissects correctly.

OK. This demonstrates that it's caused by FCS. But it's not a solution
because I don't think it's good to rely on users to switch preference to
avoid false alarms.


> > 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?
Because 3rd capture shows that there are still errors even Npcap doesn't
provide the Radiotap "Flags" field.


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


> You *are* controlling monitor mode based on whether pcap_set_rfmon_mode()
> was called before pcap_activate(), right? If not, you should do so.

I haven't started to integrate the Monitor mode switch into wpcap/libpcap
API yet. This is a next work.
Currently the switch is controlled using WlanHelper.exe manually by the end
user.


> > But is it possible to change the Radiotap protocol standard?
>
> Yes.  The interpretation of *existing* fields can't be changed in an
> incompatible fashion, but *new* fields can be added (and they have been
> added, for example the VHT field for 802.11ac).

Good.


> > 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.
>
> Yes, we would add a new "Flags with presence bits" field, with a new
> presence bit value, and it's 2 bytes long, with a byte containing presence
> bits and a byte containing flag bits; the flag bits byte would be the same
> as with the Flags field, and the presence bits indicates which of the bits
> in the flag byte actually contain a value, so, for example, the presence
> bits byte and flag byte could be
>
>         0 1 0 0 0 0 0 0
>         0 0 0 0 0 0 0 0
>
> for a frame that didn't fail the FCS check but for which we don't know
> anything else, and
>
>         0 1 0 0 0 0 0 0
>         0 2 0 0 0 0 0 0
>
> for a frame that did fail the FCS check but for which we don't know
> anything else.

I think there's a typo here.

For the packet fails the FCS check, the new "Flags" bits should be:
0 1 0 0 0 0 0 0
0 1 0 0 0 0 0 0

If this proposal passes, I will definitely adopt this standard first:)


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