Wireshark-dev: Re: [Wireshark-dev] Does it make any sense to supply Radiotap + 802.11 headers f
From: Yang Luo <hsluoyb@xxxxxxxxx>
Date: Wed, 20 Apr 2016 10:24:59 +0800
Hi Guy,

Thanks for your answer! It seems that the header switch based on operation mode switch is quite reasonable. I think I will make Npcap follow it.

And I still have some additional questions. 

First there's a little background here: Npcap uses a build-time configuration to choose whether the driver sees fake Ethernet packets or raw 802.11 packets. This build-time configuration controls whether Npcap driver is bound below or above a Microsoft driver called NWIFI (NativeWiFi Filter). NWIFI does the translation between fake Ethernet headers and 802.11 headers. So if Npcap is below NWIFI, it can see 802.11 prior to NWIFI's handling. If Npcap is above NWIFI, it will only see the fake Ethernet provided by NWIFI. This is why there're two versions of Npcap.

1) When operation mode switches (like managed mode to monitor mode), how fast does the header switch take effect? For example, does the user need to restart the mac80211 driver (and Wireshark) to make this change take effect? Or without driver restart, and don't need to close Wireshark, new packets can automatically switch to radiotap + 802.11 headers in Wireshark capture window. I'm asking this because currently Npcap needs to install a -wifi version to make the switch. It should be possible to make the switch between a driver restart, but I want to know how Linux does it.

2) Does Linux allow to inject (send) packets in monitor mode? I'm asking this because Jeffery from Microsoft said in this post (http://www.osronline.com/showThread.CFM?link=265127) that they won't officially support packet injection for LWF driver below NWIFI (like -wifi version Npcap). 

I'm not too surprised that the packets don't work if your driver gets stuck below NWIFI. We don't support drivers doing that, because you need to decorate your packets in a special way & synchronize with the WLAN state machine, etc.

3) According to the background, if I need to provide the header switch between a driver start, first I need to choose the -wifi version Npcap. (I can't use the normal version Npcap, because it can't see 802.11 packets in any case). And this leads to an issue: I need to handle the 802.11 data header-> Ethernet header translation for capturing and Ethernet header -> 802.11 data header translation for injection by myself under ExtSTA mode. I want to know is it possible to do this translation?

I know it's easier to do the translation from 802.11 to Ethernet. I found 802.11 data header is 24 bytes and it contains Destination Address as dst_mac in Ethernet and Source Address as src_mac in Ethernet. And the following LLC header is 8 bytes and it contains Type as type in Ethernet.
But reversely it's not easy any more. I don't know how to fill in the blanks in 802.11 data and LLC only based on the knowledge of Ethernet header information. And I feel like I'm reimplementing the NWIFI driver, which I don't know if it's possible. I don't know how NWIFI gets the needed parameters to fill in the blanks when doing the translation from fake Ethernet to 802.11.

Any ideas? Thanks.


Cheers,
Yang



On Wed, Apr 20, 2016 at 12:34 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
On Apr 19, 2016, at 7:09 AM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> Someone told me that:
>       • could you please automatically provide Ethernet pseudo-headers rather than Radiotap etc. when the WLAN NIC is switched to "managed" (STA) mode? The point is that Wireshark doesn't dissect frames whose 802.11 header indicates some Data subtypes (probably encrypted ones) although the actual payload has been decrypted by the NIC. So you can see the plaintext contents in the hex dump but the dissection says just "Data".
>
> So it seems that Wireshark doesn't quite support option 3)?

What's probably happening is that the Protected bit is set but the packet contents are decrypted.

One of the "Yes" options for "Ignore the Protection bit" preference might make that work.
___________________________________________________________________________
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