On Apr 9, 2016, at 9:11 AM, Yang Luo <[email protected]> wrote: > On Sat, Apr 9, 2016 at 5:33 PM, Guy Harris <[email protected]> wrote: >> On Apr 9, 2016, at 1:09 AM, Yang Luo <[email protected]> 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 <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
