On Feb 15, 2012, at 10:16 PM, abhinav narain wrote:
> Can someone explain how the 80211 packets be captured in PPI format written in the packet-ppi.c file ?
They can be captured in PPI format by:
1) having a PC that runs Windows, buying an AirPcap adapter, capturing with the AirPcap adapter, and selecting PPI (or "Per-packet information" or whatever the UI lists) rather than radiotap in the Capture Options dialog;
2) if I remember correctly, having a Mac running Mac OS X Lion and a AirPort adapter, capturing on the AirPort adapter, and selecting PPI (or "Per-packet information" or whatever the UI lists) in the Capture Options dialog (I seem to remember support for PPI being added in Lion, in addition to the support for radiotap that's been there since at least Snow Leopard, but I might be remembering incorrectly - if so, you can't get PPI on a Mac);
3) having a machine that runs Linux and that has an 802.11 adapter, convincing the maintainers of include/if_arp.h to add an ARPHRD_ value for PPI (if it doesn't already have one), getting a version of libpcap that maps that ARPHRD_ value to DLT_PPI, convincing the maintainers of the mac80211 layer and, if necessary, the author of the driver for the 802.11 adapter in question to add support for PPI, and, well, there are two options here:
1) they drop support for radiotap in favor of PPI, in which case capturing on the 802.11 adapter in monitor mode would give you PPI - but that means breaking libraries and applications that expect radiotap headers, so that's probably never going to happen;
2) they add a new ioctl or some other call to request a particular type of radio header, in which case libpcap also needs to be modified to use that ioctl or other operation and whatever other ioctl or other operation gives a list of possible radio headers;
and, once that's all done, capturing on the 802.11 adapter, and selecting PPI (or "Per-packet information" or whatever the UI lists) rather than radiotap in the Capture Options dialog;
4) having a machine that runs *BSD and that has an 802.11 adapter, convincing the maintainers of the BSD in question to pick up DLT_PPI if they don't already have it, convincing the author of the driver for the 802.11 adapter in question to add support for PPI, capturing on the 802.11 adapter, and selecting PPI (or "Per-packet information" or whatever the UI lists) rather than radiotap in the Capture Options dialog.
Neither 3) nor 4) are, I suspect, likely to happen in the near future, if they even ever happen.
> For now, I see only the path for dissect_80211_common seems to be used without the is_ht flag, which essentially make me wonder how wireshark identifies 80211 n packets
"80211 n packets" are packets transmitted using the "High Throughput (HT) PHY" as defined in section 20 of IEEE 802.11n-2009.
Wireshark can't identify b packets, a packets, g packets, or n packets without some form of radio header. If the radiotap header is present, an n frame would be identified by, for example, having the MCS field:
http://www.radiotap.org/defined-fields/MCS
present.
HT is another matter; as section "20.1.4 PPDU formats" of IEEE 802.11n-2009 says, there are three formats for an N frame:
non-HT;
HT-mixed;
HT-greenfield;
so not all n frames are HT frames.
As per my previous mail, it appears that "is_ht" should *NOT* be passed as an argument to dissect_80211_common() and, in fact, it probably shouldn't even exist; it's only used to determine whether to do the check for ((QoS and Order flag set) or Control Wrapper), but, at least as I read 802.11n, that check should always be done - non-n frames shouldn't be Control Wrapper frames and shouldn't have the Order flag set if they're QoS frames.
