Wireshark-dev: Re: [Wireshark-dev] How Wireshark supports monitor mode for WLAN 802.11 adapter
By the way, the next thing you'll have to do, if you haven't done so already, is to handle raw 802.11 packet indications from NDIS:
https://msdn.microsoft.com/EN-US/library/ff554833.aspx
which seems to imply that you need to set NDIS_PACKET_TYPE_802_11_RAW_DATA and NDIS_PACKET_TYPE_802_11_RAW_MGMT in the packet filter.
And if you want to supply radio information for received packets, there's more work to do. That information is provided as "Media-Specific OOB Data for Received 802.11 Packets":
https://msdn.microsoft.com/en-us/library/windows/hardware/ff559169(v=vs.85).aspx
in a DOT11_EXTSTA_RECV_CONTEXT structure:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff548626(v=vs.85).aspx
To do this, you'd provide a link-layer header type of DLT_IEEE802_11_RADIO, and synthesize a radiotap header. When you open the device, you'd have to fetch the device's data rate mapping table with the OID_DOT11_DATA_RATE_MAPPING_TABLE OID:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff569139(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff547679(v=vs.85).aspx
and associate that with the private data for the pcap_t.
Then, for each received packet:
if DOT11_RECV_FLAG_RAW_PACKET_TIMESTAMP is set in uReceiveFlags, provide a TSFT field with the value from the ullTimestamp field of the structure;
provide a Flags field with 0x10 set if the frame includes the FCS (you'll probably have to experiment a bit to see whether you get the FCS or not - the answer might differ for data and management frames, based on Network Monitor's behavior) and with 0x40 set if DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE is set in uReceiveFlags;
provide a Rate field whose value is the result of looking up the ucDataRate field's value in the data rate mapping table and returning the usDataRateValue value from that table - if it's not found, don't provide the Rate field;
provide a Channel field where the frequency value is the uChCenterFrequency field of the structure and the flags are derived from the uChCenterFrequency and uPhyId fields of the structure - assuming that the uPhyId value is one of the ones from
https://msdn.microsoft.com/en-us/library/windows/hardware/ff548741(v=vs.85).aspx
then the mapping would be:
dot11_phy_type_fhss - set 0x0800 in the flags (11 legacy FHSS);
dot11_phy_type_ofdm - set 0x0040 in the flags (11a);
dot11_phy_type_hrdsss - set 0x0020 in the flags (11b);
dot11_phy_type_erp - set 0x0040 in the flags (11g, unknown whether it's pure or not);
and, unless it's dot11_phy_type_irbaseband, set 0x0100 if the frequency is in the 5 GHz range or set 0x0080 if it's in the 2.4 GHz range;
provide a Antenna signal field whose value is the value of the lRSSI field in the structure;
if the phy is dot11_phy_type_ht, provide an MCS field where the known field is 0 and the other fields are also zeroed out (i.e., it's 11n, but we don't know anything else about it);
if the phy is dot11_phy_type_vht, provide an VHT field where the known field is 0 and the other fields are also zeroed out (i.e., it's 11ac, but we don't know anything else about it).