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

[Guy Harris <guy () alum mit edu>]

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.

> > 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.  We 
can fix tcpdump and Wireshark to interpret that as meaning that we don't know what channel the packet was received on.  
(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.)
___________________________________________________________________________
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