Wireshark-dev: Re: [Wireshark-dev] Got "Radiotap data goes past the end of the radiotap header"
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sat, 9 Apr 2016 11:53:42 -0700
On Apr 9, 2016, at 9:11 AM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:

> On Sat, Apr 9, 2016 at 5:33 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>> On Apr 9, 2016, at 1:09 AM, Yang Luo <hsluoyb@xxxxxxxxx> 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.)