Wireshark-dev: Re: [Wireshark-dev] [tcpdump-workers] What's the difference between NdisMediumBa
On Apr 6, 2016, at 5:41 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:
> I wonder why this mail went to my spam.. I don't know anything about radiotap header so I'm afraid i'm not supplying it.
It's a way to provide "radio metadata" for packets; see
http://www.radiotap.org
for a description of it.
If you were to implement that in the future, you'd get the "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
when you receive a packet. Then 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 radiotap TSFT field with the value from the ullTimestamp field of the structure;
provide a radiotap 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 radiotap 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 radiotap 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 radiotap Antenna signal field whose value is the value of the lRSSI field in the structure;
if the phy is dot11_phy_type_ht, provide a radiotap 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 a radiotap 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).
> And I have confirmed that my captured packets are parsed well using NdisMediumBare80211. In Wireshark it shows "IEEE 802.11 Data".
That means that you're just supplying packets that begin with an 802.11 header, with no form of radio information preceding it, so...
> So I think I will just use this value.
...that is exactly what you should be doing.
