[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] What's the difference between NdisMediumBare80211 (DLT_IEEE802_11) and NdisMed
From:       Guy Harris <guy () alum ! mit ! edu>
Date:       2016-04-07 1:37:12
Message-ID: 9C28B44E-2AFD-47DE-86BE-B87A705242C6 () alum ! mit ! edu
[Download RAW message or body]

On Apr 6, 2016, at 5:41 PM, Yang Luo <hsluoyb@gmail.com> 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.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


[prev in list] [next in list] [prev in thread] [next in thread]