Re: Got "Radiotap data goes past the end of the radiotap header" for Npcap's radiotap header.

[Yang Luo <hsluoyb () gmail com>]

Hi Guy,

On Sun, Apr 10, 2016 at 2:53 AM, Guy Harris <guy () alum mit edu> wrote:

> On Apr 9, 2016, at 9:11 AM, Yang Luo <hsluoyb () gmail com> wrote:
>
> > On Sat, Apr 9, 2016 at 5:33 PM, Guy Harris <guy () alum mit edu> wrote:
> > > On Apr 9, 2016, at 1:09 AM, Yang Luo <hsluoyb () gmail com> wrote:
> > >
> > > > However, most information of the radiotap header is zero like below.
> The most commonly seen TSFT field (I thought) is not there. Although I
> didn't implement some fields like "Rate" yet, but I still feel it's too
> blank?
> > > > Maybe this is because the underlying network card driver doesn't
> implement so many 802.11 OOB data,
> > > It could be:
> https://social.technet.microsoft.com/Forums/en-US/624a6148-f8ed-4be0-819e-924ae3cd3dda/wifi-in-netmon-dealing-with-broken-monitor-mode-implementations-in-the-drivers?forum=netmon
> > > Michael Berg of Tamosoft has also noted that the quality of the
> metadata supplied by Native Wi-Fi drivers for Windows... *varies*.
> (Unfortunately, I think that was in some tweets he posted, and Twitter
> makes it *really hard* to search - it seems not to find reply tweets, which
> I think his comments were.)
> > I'm not surprised if the WiFi and monitor support will not work on all
> hardwares. Even for the current wifi version Npcap with 802.11 data packets
> enabled, some hardwares even cause crash in certain conditions. So I will
> see how far this can go.
>
> Linux drivers seem to do a better job of providing radio information; I
> think that may be true even for the same Wi-Fi adapter.  Perhaps providing
> radio information is more important to the people writing Linux Wi-Fi
> drivers than the people writing Windows Wi-Fi drivers.

Good point.


> > > If the channel frequency is 0, that probably means that it's not
> supplied, so don't provide a Channel field.
> > Is this a good behavior of not providing Channel? I think Channel
> contains two parts: 16 bits flags and 16 bits frequency. Even the frequency
> is invalid, the flags is still there? If I remove Channel field, flags will
> also be gone.
>
> I guess if you can determine what type of channel the packet was received
> on, even if the driver doesn't bother supplying a channel number or channel
> frequency, you might as well provide a Channel field with a frequency of 0.


I know what a channel number or frequency means, but what's a "channel
type"?
I know that in monitor mode, I should be able to get the channel no without
query the underlying driver? I don't know if there's method to get it by my
own in ExtSTA mode.


> We can fix tcpdump and Wireshark to interpret that as meaning that we
> don't know what channel the packet was received on.


Yeah, we can pick a definitely invalid value of channel number as an
agreement to indicate UNKNOWN condition. In fact I think 0 is just the best
choice. The valid values of Channel number are 1, 2, 3, 4.. So there's no
use of 0.


> (If you can submit a bug to the vendor of the Wi-Fi chip or adapter that
> supplies a channel number/frequency of 0, maybe they'll fix it.)

I don't think we can count on the chip vendors. They are big companies and
have so many chip models. Like your link:
https://social.technet.microsoft.com/Forums/en-US/624a6148-f8ed-4be0-819e-924ae3cd3dda/wifi-in-netmon-dealing-with-broken-monitor-mode-implementations-in-the-drivers?forum=netmon
said,
even Microsoft itself doesn't have confidence (or will?) to persuade its
partners into following the rules.


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