Hello, Regarding the Wifi 802.11 with different variants (a, b, g, n, ac , and ad). What is the best Link Layer Header Type to use to convey as much information as possible to the upper layer applications? Is it better to use RadioTap header over PPI, or what? asked 12 Jun '15, 16:56  Hany Assasa |
2 Answers:
PPI provides more data than Radiotap, especially for 11n networks. answered 12 Jun '15, 17:59  Amato_C showing 5 of 13 show 8 more comments |
My personal preference is Radiotap. That is using AirPCAP. But it does depend on what information you are looking for. answered 13 Jun '15, 14:15  chillypenguin |
And what about the new standard 802.11ad? In addition, if A-MPDU aggregation is enabled would PPI would be more informative than RadioTap for this particular feature?
What information does PPI provide that's not supported by the radiotap specification?
If the answer is "none", then the problem is with the drivers that supply radiotap information, not with radiotap itself, and the maintainers of the drivers should be told to fix their drivers. (Given which vendors support PPI and which vendors support radiotap, the way to tell them is probably to use the site mentioned here.)
The most important information to me is the MPDU Aggregation and I would like the header to be supportive for 802.11ad. During my inspection in RadioTap and PPI, I did not find fields that contain information related to 802.11ad like PPDU Aggregation, Beamforming, PHY LAyer Type.
What MPDU aggregation information does PPI provide that's not provided by the radiotap A-MPDU status field?
No, there's no 802.11ad support in either version 1.0.10 of the PPI spec or the radiotap spec. Radiotap does have some 802.11ac support, such as the VHT field; I don't see any 802.11ac support in the PPI spec.
@Amato_C So what 802.11n information does PPI provide that's not provided by radiotap?
"@Guy Harris" Here is a link to the PPI Header Specification: https://www.cacetech.com/documents/PPI%20Header%20format%201.0.7.pdf
Unfortunately I could only find the version from 2008. But when I open a trace with PPI I see the following main headers: 802.11-Common 802.11n MAC 802.11n MAC+PHY
In contrast, Radiotap has only MCS information.
I understand that both PPI and Radiotap depends on the driver. But whenever viewing a capture with PPI, the information is more extensive.
Looking at the 2009 1.0.10 spec, as linked in an earlier comment of mine:
If you don't have the fields listed, that sounds like a rather severe driver bug. I get Channel, Flags, and MCS on my MacBook Pro when I capture in monitor mode; that's with a Broadcom BCM43xx AirPort adapter and the Mountain Lion driver.
I found that PPI provides different type of information regarding MPDU Aggregation than RadioTap. My main issue is I am generating Wifi traffic in ns3 tool. These traffic contains aggregated MPDU frames. When I try to display generated PCAP file by ns3 in Wireshark, the frames are not being decoded correctly. ns3 uses RadioTap to provide information regarding the captured frames. So I was thinking is it a problem of ns3 or it is the RadioTap problem
This could be a bug in the Wireshark dissector. Please file a bug on the Wireshark bugzilla and attach one of the captures that Wireshark isn't decoding correctly. Without that capture, we have no way of determining whether 1) radiotap can't convey enough information to decode it correctly, 2) radiotap can do so but ns3 isn't using it correctly, or 3) radiotap can do so, ns3 is using it correctly, but Wireshark isn't using the radiotap information at all or isn't using it correctly.
@Guy Harris: Is the extension channel information useful, or do you determine it from the main channel information and the +20/-20 flag? Yes, the extension channel information is required to set-up my wireless capture. The adapter needs to know whether the extension channel is above or below the primary channel. Sometimes it is easy to determine this information (e.g., primary channel is 36 then extension must be +20). For other occasions, I use the Beacons from the AP: HT Information Element (ID = 61)
@HA87: Sorry that Guy and I are having a side conversations on your original post.
That's indicated by the "bandwidth" value in the "flags" subfield of the MCS field in radiotap, so that information is supplied by radiotap. For 802.11ac, it's more complicated, but see the "bandwidth" subfield of the VHT raditap field.
(I.e., the "+20/-20 flag" is what says whether the extension channel is above - +20 or below - -20 - the primary channel.)
@Amato_C it is OK, no problem to have discussion here.
@Guy Harris: I am working on generating trace file to check if the decoding problem is from wireshark or ns3. I will update you ASAP.
@Guy Harris: I can confirm the problem I reported before is from Wireshark dissector. I have filed a bug on Wireshark Bugzilla. Please find the following link to it with the capture file: Bug 11277