Re: Does it make any sense to supply Radiotap + 802.11 headers for packets captured on wireless adapter for managed mode?

[Yang Luo <hsluoyb () gmail com>]

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 () alum mit edu> wrote:

> On Apr 19, 2016, at 7:09 AM, Yang Luo <hsluoyb () gmail com> 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 () 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