[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Guy,

On Sun, Apr 10, 2016 at 2:53 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

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.

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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe