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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
