[Guy Harris <guy@xxxxxxxxxxxx>]

On Feb 13, 2012, at 5:20 PM, abhinav narain wrote:

> I am using wireshark on linux ( ubuntu), and I want to write a custom ieee80211 parser for a router machine where Wireshark cannot be installed (obvious reasons) .
> Going through Wireshark code, there is no call to  dissect_ieee80211_ht() function.
> How does wireshark find n packets ?

The same way it finds any other packets.  It's not as if all 802.11n packets have to be captured or dissected specially.

> the is_ht variable is also never used.

Actually, it is - check the code again.

To quote the comment before the dissect_ht_control() routine:

/*
 * 7.1.3.1.10 says:
 * "The Order field is 1 bit in length and is set to 1 in any non-QoS Data
 * frame that contains an MSDU, or fragment thereof, which is being
 * transferred using the StrictlyOrdered service class. The presence of the
 * HT Control field in frames is indicated by setting the Order field to 1
 * in any Data type or Management type frame that  is transmitted with a
 * value of HT_GF or HT_MM for the FORMAT parameter of the TXVECTOR except
 * a non-QoS Data frame or a Control Wrapper frame. The Order field is set
 * to 0 in all other frames. All non-HT QoS STAs set the Order field to 0."
 *
 * ...so does this mean that we can check for the presence of +HTC by
 * looking for QoS frames with the Order bit set, or do we need extra
 * information from the PHY (which would be monumentally silly)?
 *
 * At any rate, it doesn't look like any equipment we have produces
 * +HTC frames, so the code is completely untested.
 */

That probably came from a draft; section "7.1.3.1.9 Order field" of the final 802.11n-2009 spec changes section 7.1.3.1.9 of the 802.11-2007 spec from:

	The Order field is 1 bit in length and is set to 1 in any non-QoS data frame that contains an MSDU, or fragment thereof, which is being transferred using the StrictlyOrdered service class. This field is set to 0 in all other frames. All QoS STAs set this subfield to 0.

to

	Change 7.1.3.1.9 as follows :

	The Order field is 1 bit in length.  It is used for two purposes:

	    -  When set to 1 in a non-QoS data frame transmitted by a non-QoS STA, it indicates that the frame contains an MSDU, or fragment thereof, which is being transferred using the StrictlyOrdered service class.

	    -  When set to 1 in a QoS data or management frame transmitted with a value of HT_GF or HT_MF for the FORMAT parameter of the TXVECTOR, it indicates that the frame contains an HT Control field.

	Otherwise, the Order field is set to 0.

At least as I read it, that seems to imply that the only QoS frames with the Order field set should be QoS data or management frames with HT_GF or HT_MF as the format, i.e. high-throughput QoS frames.

Section "7.1.3.5a HT Control field" of the 802.11n-2009 spec says:

	The HT Control field is always present in a Control Wrapper frame and is present in QoS Data and management frames as determined by the Order bit of the Frame Control field as defined in 7.1.3.1.9.

I read that plus the change to 7.1.3.1.9 to indicate that a frame has an HT Control field if and only if:

	1) it's a Control Wrapper frame

or

	2) it's a QoS frame with the Order field set

which seems to imply that you don't need extra information from the PHY - non-QoS frames don't ever have an HT Control field, and only high-throughput QoS frames will have the Order flag set.

So we probably need to get rid of dissect_ieee80211_ht(), and make the is_ht argument to dissect_ieee80211_common() into a local variable, and set it for Control Wrapper frames and QoS frames with the Order flag set - and perhaps rename is_ht to has_ht_control or something such as that, to indicate what it really means.

which seems to imply that the mere fact that the Order flag is set is insufficient to indicate whether the frame has an HT Control field - the frame could be a non-QoS frame

> I have seen the runtime call graph and dissect_80211_common is called, while there is no use of capture_80211..() code,

Yes, there is.

capture_ieee80211() is called by capture_info_packet() if you're capturing on a device whose DLT_ value maps to WTAP_ENCAP_IEEE_802_11 or WTAP_ENCAP_IEEE_802_11_WITH_RADIO.  capture_radiotap() is called by capture_info_packet() if you're capturing on a device whose DLT_ value maps to WTAP_ENCAP_IEEE_802_11_WLAN_RADIOTAP, and it calls either capture_ieee80211() or capture_ieee80211_datapad().

capture_info_packet() is called by capture_info_new_packets(), and capture_info_new_packets() is called from capture_input_new_packets() if capture_opts->show_info is true.  It will be true *if* you have a "capture info" window up; that's the small window that's open during a capture, showing packet counts and a button to stop a capture.  There's an option in the "Capture Options" dialog to show that window.

Whoever, or whatever, produced the runtime call graph either

	1) made a mistake

or

	2) didn't look at the call graph when capturing with a capture info window up.

> Also, I don't find any option to use PPI format in linux ?

Linux drivers that supply radio information generally do it with radiotap, not PPI.