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 12:57:41 +0800
Hi Guy,

On Wed, Apr 13, 2016 at 10:11 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
On Apr 12, 2016, at 6:27 PM, Yang Luo <hsluoyb@xxxxxxxxx> 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:

2) Capture 2: ExtSTA Mode, Radiotap "Flags" field is forced ON:

3) Capture 3: NetMon Mode, Radiotap "Flags" field is NOT PROVIDED:

4) Capture 4: NetMon Mode, Radiotap "Flags" field is forced ON:

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.
 

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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe