On 4/4/2012 2:58 AM, Guy Harris wrote:
On Apr 4, 2012, at 2:30 AM, Kevin Cullimore wrote:
<SNIP>
4) if you're stuck running Windows, do your capture with another application, such as Microsoft Network Monitor:
http://www.microsoft.com/download/en/details.aspx?id=4865
It's not clear that this option satisfies the "capture the WiFi physical layer information" requirement.
Depends on what you mean by "Wi-Fi physical layer information"; it supplies 802.11 headers and at least some radio information (channel, RSSI, rate). (See the WiFiMetadata structure in the Base/wireless.npl NPL file in the set of NPL files for NetMon 3.4.)
Thanks for the reference. It turns out I WAS encountering a violation of
the "doesn't suck" criterion, which might fail to surprise, given the
OS/Vendor constraints (although the contrast between the
functionality/visibility available in modern versions of netmon vs.
older ones leads me not to complain as loudly as I otherwise might).
However, if the head of Tamosoft is correct, it's not clear that this option satisfies the presumed "doesn't suck" requirement:
http://twitter.com/#!/TamoSoft/status/177670392276713472
"@firemywires It's not that rosy,unfortunately.NativeWiFi is poorly implemented in most of the drivers.And you can't capture 40 MHz channels"
http://twitter.com/#!/TamoSoft/status/182380964125745152
"@DevinAkin @Ben_SniffWiFi @firemywires No 40 MHz ch,no FCS info,broken sig.level (Ralink),broken chan.selection (Intel),invalid HT rate info"
Tamosoft's Commview for Wi-Fi solves this by having its own drivers, rather than relying on the vendor/Microsoft drivers, with the advantage that they can avoid vendor and/or Microsoft driver writer suckage and the disadvantage that if you don't have a card for which they have a driver, you lose.
5) if you're stuck running Windows, and it's Vista or later, and want to capture with Wireshark (or WinDump or any other WinPcap-based application), modify WinPcap so that, on Windows Vista and later, it's an NDIS 6 driver and uses the Native Wi-Fi mechanism (and the monitor mode APIs from libpcap 1.0 and later, which means upgrading WinDump's underlying libpcap version to 1.0 or later). (Contribute the changes to the WinPcap developers if you don't want to continue supporting them yourself.)
And that would have the same characteristics as NetMon, given that it'd use the same code path, and hence the same presumed suckage.
___________________________________________________________________________
Sent via: Wireshark-users mailing list<wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe