[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

On Thu, Apr 14, 2016 at 5:41 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Apr 12, 2016, at 9:57 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> 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:
> 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?

Amazing! This is the right way! Via this way, both ExtSTA and NetMon modes are happy, no systematic "Malformed Packet" in Wireshark any more.

So at least for my adapter:

ExtSTA Mode (no FCS) --> without DOT11_RECV_FLAG_RAW_PACKET set --> turn "FCS at end" off

NetMon Mode (has FCS) --> with DOT11_RECV_FLAG_RAW_PACKET set --> turn "FCS at end" on

Very perfect that DOT11_RECV_FLAG_RAW_PACKET can indicate whether the adapter is in NetMon Mode or not. Otherwise I need to figure out another way to check monitor mode (like query OID).

 

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

As you said in the following text, Wireshark lacks the ability to check FCS availability without Radiotap "Flags". So Npcap needs to provide it to make it right.

 

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

I forgot that wireless network is not that stable as Ethernet. There just can be errors from underlying physical layer, which we can do nothing about.

I rechecked Capture 4, The "Malformed Packet" error is NOT systematic: Not all the 802.11 Acknowledgement or Action packets are wrong. So it's not a Npcap or Wireshark issue. Just transmission error.

 

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

I checked Capture 4 on the two faulty packets, Frame 276 (802.11 Acknowledgement) and Frame 496 (802.11 Action).

Frame 276 is marked with "Bad FCS" bit in Radiotap "Flags".

Frame 496 is NOT marked with "Bad FCS" bit in Radiotap "Flags".

So it's just like you said, "Bad FCS" bit is sometimes but not always working for "Malformed Packet" error.

 

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

I have subscribed the list:)

And the latest Npcap version with this issue fixed is at:

https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap-nmap-0.06-r15-wifi2.exe

Welcome test!

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