On Apr 4, 2012, at 2:30 AM, Kevin Cullimore wrote:
> On 4/3/2012 9:40 PM, Guy Harris wrote:
>> On Apr 3, 2012, at 7:30 PM, Barry Constantine wrote:
>>
>>> Besides AirPcap, are there other ways to capture promiscuously on a wireless network and to capture the WiFi physical layer information?
>> Yes:
...
>> 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.)
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.