It was already added to the clean dissectors list, but wasn't removed
from the dirty dissectors list, so it was built twice and linked in
twice, and hilarity ensued.
Change-Id: Ic4636f17b61e619546dc21a04ebbaace0296d583
Reviewed-on: https://code.wireshark.org/review/9067
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The return values of new-style dissectors always use the captured length, so
replace those automagically with sed.
Change-Id: Ic43072ee4a80d433cd4264444583a0e670adc26a
Reviewed-on: https://code.wireshark.org/review/9065
Reviewed-by: Evan Huus <eapache@gmail.com>
distinguish between the length field in the packet and the current item's length
make sure that the length field fits into a gint variable
add a cast to the return value of tvb_strsize()
don't throw an exception manually
Change-Id: I2debab778be3e34d68b1be31963d2d9260a30e0e
Reviewed-on: https://code.wireshark.org/review/9056
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Also regenerate all to pick up the usage of https in some comment links.
Change-Id: Ic17b6368d2118627178b0b560031450d98e5b5e5
Reviewed-on: https://code.wireshark.org/review/9060
Reviewed-by: Evan Huus <eapache@gmail.com>
new function dissect_zvt_tlv_len(), use it for the total length
and for each tlv entry's length field
Change-Id: I2b7ba6939ddf0326b014c565ffbe5d16e3a88282
Reviewed-on: https://code.wireshark.org/review/9059
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
This got missed in the initial refactoring.
Change-Id: I98dcc0816e065efab9b497f753c8d2d388349ff3
Reviewed-on: https://code.wireshark.org/review/9044
Reviewed-by: Michael Mann <mmann78@netscape.net>
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>
Part 2 !
Change-Id: Iaa46f3d785cbff6b397edf5bd54c0c3cf65a7264
Reviewed-on: https://code.wireshark.org/review/8822
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
tvb_strsize() returns guint
remove the if (tree) while we're at it
Change-Id: Icc24f166104a3e9b95fca2ef14a7bd8be2677cba
Reviewed-on: https://code.wireshark.org/review/9047
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: I497b77dec1eb4617179d492838ecd7d267539ba4
Reviewed-on: https://code.wireshark.org/review/9043
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
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>
parse_key_string reads from rec->string and rec->key (without
modifying those parameters), then returns a newly allocated
decryption_key_t struct which is not used except for reading the
type field. Release memory after copying that single field!
Change-Id: Iac19bea23dedb73cab9dd1ea09f98cc83556e96c
Reviewed-on: https://code.wireshark.org/review/9025
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Change-Id: I47795fb9e1044f4319721c3bf1208c269a4b9c34
Reviewed-on: https://code.wireshark.org/review/9023
Reviewed-by: Michael Mann <mmann78@netscape.net>
Very similar to the refactoring of SRT stats, it provides more commonality of the stats for all GUI interfaces. Currently implemented for TShark and GTK. Affected dissectors: MEGACO, MGCP, Radius
Change-Id: Icb73a7e603dc3502b39bf696227fcaae37d4ed21
Reviewed-on: https://code.wireshark.org/review/8998
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
packet-dnp.c:2735:28: error: variable 'al_filename' set but not used [-Werror=unused-but-set-variable]
packet-dnp.c:1843:32: error: variable 'al_filename_offs' set but not used [-Werror=unused-but-set-variable]
Change-Id: Ia84b270aa8f56fb4104fb875339dc3d39c6105c6
Reviewed-on: https://code.wireshark.org/review/9020
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
From 3GPP 23.003
The GSN Address is composed of the following elements:
1) The Address Type, which is a fixed length code (of 2 bits) identifying the type of address that is used in the
Address field.
2) The Address Length, which is a fixed length code (of 6 bits) identifying the length of the Address field.
3) The Address, which is a variable length field which contains either an IPv4 address or an IPv6 address.
Address Type 0 and Address Length 4 are used when Address is an IPv4 address.
Address Type 1 and Address Length 16 are used when Address is an IPv6 address.
The IP v4 address structure is defined in RFC 791 [14].
The IP v6 address structure is defined in RFC 2373 [15].
Currently the Wireshark decodes IPv6 addresses as IPv4
This commit reverts parts of commit 1cdef1d98a
Change-Id: I4905d4cf559abcb42b9dfe3652667d2ff96dd444
Reviewed-on: https://code.wireshark.org/review/8984
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I979990e9385182870ce4809a7e6fa16e598cb2be
Reviewed-on: https://code.wireshark.org/review/9016
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Create "common" SRT tap data collection intended for all GUIs. Refactor/merge functionality of existing dissectors that have SRT support (AFP, DCERPC, Diameter, FC, GTP, LDAP, NCP, RPC, SCIS, SMB, and SMB2) for both TShark and GTK.
SMB and DCERPC "tap packet filtering" were different between TShark and GTK, so I went with GTK filter logic.
CAMEL "tap packet filtering" was different between TShark and GTK, so GTK filtering logic was pushed to the dissector and the TShark tap was left alone.
Change-Id: I7d6eaad0673fe628ef337f9165d7ed94f4a5e1cc
Reviewed-on: https://code.wireshark.org/review/8894
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
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>
use an FT_BYTES variable instead of passing it to the data dissector
Change-Id: Ia52cba24dedec13c9842109d45b3a277ee627f42
Reviewed-on: https://code.wireshark.org/review/8994
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
remove the if(tree) so that we fill the info column regardless of the tree
clear the info column first, then append our data
remove an unnecessary initializer
Change-Id: I0e9e9582f360dd929e422f994c3d4a644c602642
Reviewed-on: https://code.wireshark.org/review/8993
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Martin Mathieson