This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Link Layer Header Types for 802.11

0

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%20Assasa's gravatar image

Hany Assasa
21101114
accept rate: 0%


2 Answers:

1

PPI provides more data than Radiotap, especially for 11n networks.

answered 12 Jun '15, 17:59

Amato_C's gravatar image

Amato_C
1.1k142032
accept rate: 14%

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?

(12 Jun '15, 18:12) Hany Assasa
1

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.)

(12 Jun '15, 18:25) Guy Harris ♦♦

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.

(13 Jun '15, 14:28) Hany Assasa

The most important information to me is the MPDU Aggregation

What MPDU aggregation information does PPI provide that's not provided by the radiotap A-MPDU status field?

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.

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.

(13 Jun '15, 17:22) Guy Harris ♦♦

@Amato_C So what 802.11n information does PPI provide that's not provided by radiotap?

(13 Jun '15, 17:28) Guy Harris ♦♦

"@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.

(13 Jun '15, 19:18) Amato_C
1

Looking at the 2009 1.0.10 spec, as linked in an earlier comment of mine:

  • the 802.11-Common fields are in the radiotap Channel, FHSS, Antenna signal, and Antenna noise;
  • the 802.11n MAC fields are in the radiotap MCS and A-MPDU status fields;
  • the 802.11 MAC+PHY fields are in those headers and the antenna noise/signal headers, with the Antenna field used to indicate to which antenna the signal information refers, but the error vector magnitudes and extension channel information isn't there. However, is the extension channel information useful, or do you determine it from the main channel information and the +20/-20 flag?

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.

(13 Jun '15, 19:37) Guy Harris ♦♦

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

(14 Jun '15, 07:58) Hany Assasa
1

When I try to display generated PCAP file by ns3 in Wireshark, the frames are not being decoded correctly

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.

(14 Jun '15, 10:04) Guy Harris ♦♦

@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.

(14 Jun '15, 13:43) Amato_C

The adapter needs to know whether the extension channel is above or below the primary channel.

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.)

(14 Jun '15, 13:49) Guy Harris ♦♦

@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.

(15 Jun '15, 02:04) Hany Assasa

@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

(15 Jun '15, 03:54) Hany Assasa
showing 5 of 13 show 8 more comments

1

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's gravatar image

chillypenguin
9114
accept rate: 25%