Provide that information so that the "802.11 radio information" protocol
can indicate whether a packet was 802.11 legacy/11b/11a/11g/11n/11ac,
and possibly whether it's 2.4 GHz or 5 GHz 11n. (Sometimes the center
frequency might not be supplied, so the band information can be useful.)
Also, provide some 11ac information, now that we can distinguish between
11n and 11ac. Don't calculate the data rate from the MCS index unless
it's 11n; we don't yet have code to calculate it for 11ac.
For radiotap, only provide guard interval information for 11n and 11ac,
not for earlier standards.
Handle the 11ac flag in the Peek remote protocol.
For Peek tagged files, the "extension flags" are 11n/11ac flags, so we
don't have to check for the "MCS used" bit in order to decide that the
packet is 11n or 11ac or to decide whether to provide the "bandwidth" or
"short GI" information.
Change-Id: Ia8a1a9b11a35243ed84eb4e72c384cc77512b098
Reviewed-on: https://code.wireshark.org/review/9032
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It's a 2-bit field that is the "number of STBC streams", according to
the radiotap Web site item for the MCS field:
http://www.radiotap.org/defined-fields/MCS
Correctly label both the FCS type and STBC stream count fields.
Change-Id: Ic49f6faec3335096c6bb8ce96ce0dec2f9342a37
Reviewed-on: https://code.wireshark.org/review/8971
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Adding VHT Radiotap fields support
Parsing and UI representation for recently adopted VHT Radiotap fields for
802.11ac specification
http://www.radiotap.org/defined-fields/VHT
From me :
* Make checkAPIs happy
* Fix wrong last argument for some proto_tree_add_item
* Use proto_tree_add_item when it is possible
svn path=/trunk/; revision=44985