Add more fields to the metadata to handle everything radiotap has, and
show them.
Call the FEC type field just "FEC", and have it be an integer field with
0 meaning BCC and 1 meaning LDPC, rather than a Boolean.
11ac doesn't have *an* MCS, it can have up to 4, one per user.
Label the 11ac bandwidth values the same way we do in the radiotap
dissector.
Change-Id: I2c2415baff3e5d68d49dda497980e8271d26b1f6
Reviewed-on: https://code.wireshark.org/review/9176
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Fetch the flags before using them; thanks to Peter Wu for catching that
one.
Fetch and use the frequency and channel.
Have cflags be the variable for the flags in Channel and xcflags be the
variable for the flags in XChannel.
Change-Id: If82f7adb448eef04b769186a90a8722d03a702a3
Reviewed-on: https://code.wireshark.org/review/9038
Reviewed-by: Guy Harris <guy@alum.mit.edu>
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>
Have dissectors of various forms of radio information headers in the
packets fill in a struct ieee_802_11_phdr with radio information as
appropriate, and call the "802.11 radio information" dissector rather
than the raw 802.11 dissector.
This means that the radio information can be found in a
protocol-independent and encapsulation-independent form when you're
looking at the packet; that information can be presented in a form
somewhat easier to read than the raw metadata header format.
It also enables having a single "radio information" tap that allows
statistics to handle all different sorts of radio information
encapsulation.
In addition, it lets us clean up some of the arguments passed to the
common 802.11 dissector routine, by having it pull that information from
the struct ieee_802_11_phdr.
Ensure that the right structure gets passed to that routine, and that
all the appropriate parts of that structure are filled in.
Rename the 802.11 radio protocol to "wlan_radio", rather than just
"radio", as it's 802.11-specific. Give all its fields "wlan_radio."
names rather than "wlan." names.
Change-Id: I78d79afece0ce0cf5fc17293c1e29596413b31c8
Reviewed-on: https://code.wireshark.org/review/8992
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Rather than accessing it through pinfo->pseudo_header, have it passed as
an argument.
This means we no longer tweak the pseudo-header filled in by libwiretap,
but instead construct our own pseudo-header, which is a bit cleaner.
It also opens up the possibility of other dissectors passing radio
information down to the 802.11 dissector, so it can display it in a
better-organized format than the raw metadata headers for
radiotap/PPI/Prism/AVS/etc., and having some of the options for 802.11
dissection (Atheros padding, Centrino stuff, etc.) also passed in
through that pseudo-header so we have fewer arguments to
dissect_ieee80211_common().
Change-Id: I470300a0407ebf029c542f7ca5878593563a70a9
Reviewed-on: https://code.wireshark.org/review/8980
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>
Add the wireless toolbar to the Qt UI.
Start adding AirPcap support to ui/80211_utils. Add FCS validation
routines to ws80211_utils.
Move a bunch of AirPcap routines that require epan from caputils to
ui/gtk. They were required for driver key management, which we'll
leave to the AirPcap Control Panel in the Qt UI.
Move frequency-utils to wsutil.
Change-Id: I44446758046621d183f5c2ba9f6526bf01e084f1
Reviewed-on: https://code.wireshark.org/review/8910
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Shift 1U instead, to make sure it's unsigned; the result of, for
example, the result of shifting a signed value left is undefined if the
value times 2^{shift count} doesn't fit in the *signed* type of the
shifted value. That means, in particular, that the result of shifting 1
left by {number of bits in an int - 1} is undefined. (In *practice*,
it'll probably be -2^32, with the bit you want set, but that's not
guaranteed, and GCC 5.1 seems not to like it.)
Change-Id: I96114047d402d1bae537cdfeb28a8564b1c94712
Reviewed-on: https://code.wireshark.org/review/8256
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Third batch (packet-icmpv6.c -> packet-mac-lte.c).
Will look at cleaning up and committing script afterwards.
Change-Id: Ib91e36ad200db01c3000605f6a7a21125b96a640
Reviewed-on: https://code.wireshark.org/review/6018
Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com>
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
Specifically:
- Set packet.h to be the first wireshark #include after
config.h and "system" #includes.
packet.h added as an #include in some cases when missing.
- Remove some #includes included (directly/indirectly) in
packet.h. E.g., glib.h.
(Done only for those files including packet.h).
- As needed, move "system" #includes to be after config.h and
before wireshark #includes.
- Rework various #include file specifications for consistency.
- Misc.
Change-Id: Ifaa1a14b50b69fbad38ea4838a49dfe595c54c95
Reviewed-on: https://code.wireshark.org/review/5923
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Part 2 of many
Change-Id: I50815e7738b011382392f3078a7107d3d9eec4ec
Reviewed-on: https://code.wireshark.org/review/5542
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(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>
1. Case sensitivity differences between hf_ field name and formatted string.
2. Unnecessary whitespace between hf_ field name and colon in formatted string
There are cases where the hf_ field name doesn't quite match the proto_tree_add_uint_format, but it's close enough that one of them should be "right", I'm just not sure which is, I just know the string in proto_tree_add_uint_format is the one displayed.
svn path=/trunk/; revision=52098
The script didn't catch as many as I would have liked, but it's a start.
The most common (ab)use of proto_tree_add_uint_format was for appending strings to CRC/checksum values to note good or bad CRC/checksum.
svn path=/trunk/; revision=52045
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
sizeof.
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
strtol() and strtoul().
Change some data types to avoid those implicit conversion warnings.
When assigning a constant to a float, make sure the constant isn't a
double, by appending "f" to the constant.
Constify a bunch of variables, parameters, and return values to
eliminate warnings due to strings being given const qualifiers. Cast
away those warnings in some cases where an API we don't control forces
us to do so.
Enable a bunch of additional warnings by default. Note why at least
some of the other warnings aren't enabled.
randpkt.c and text2pcap.c are used to build programs, so they don't need
to be in EXTRA_DIST.
If the user specifies --enable-warnings-as-errors, add -Werror *even if
the user specified --enable-extra-gcc-flags; assume they know what
they're doing and are willing to have the compile fail due to the extra
GCC warnings being treated as errors.
svn path=/trunk/; revision=46748
Also:
- Create/use several extended value strings;
- Reformat hf[] array;
- Do various whitespace and formatting changes to use a consistent style.
svn path=/trunk/; revision=46222
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
* Reorder code ! Match with Wireshark "Rules" (put in top value_string and static hf_..., in bottom proto_register_radiotap...)
svn path=/trunk/; revision=44336
Guy Harris