Change-Id: Ife44b225337e5c583c722ac62f711ed3ec9cf808
Reviewed-on: https://code.wireshark.org/review/30535
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
In preparation for decrypting and dissecting EAPOL keydata in
ieee80211 dissector move the RC4 decryption and key copy into
separate helper functions.
Change-Id: I13f3e981038f48526032e263b6eb3c9e3496abbe
Reviewed-on: https://code.wireshark.org/review/30546
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
SSNs 145 and 148-150 are all used by MAP so register for them.
This allows Wireshark to decode messages between, for example, an SGSN and
GMLC without having to touch the dissector preferences.
Change-Id: Iaaad668bcde074a2a89d3de605659849856dc396
Reviewed-on: https://code.wireshark.org/review/30531
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Replace all calls of tvb_ensure_captured_length_remaining with
tvb_ensure_length_remaining as they are only used to ensure that already
read data is present and it is not always required that at least 1 more
byte follows.
Change-Id: I71b1142c0d8f8fe3ddb09b80b6ca8ed10e0b67b6
Reviewed-on: https://code.wireshark.org/review/30517
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Based on ntp_request.h header file:
- authentication parameters are only present in request messages, not
resonse ones
- the authentication timestamp is at a fixed position with an offset
of 184 bytes in the packet, followed by the encryption keyid and
optionally the mac
- do not display the authentication timestamp (even if present in the
packet) if the authentication bit is not set (as the value 0 translates
into a date in 2036)
Bug: 15258
Change-Id: Id2e49beeef4a0fdc3082d9b7b09a214fd531a6bb
Reviewed-on: https://code.wireshark.org/review/30527
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
This is only the new IEs and one new Extension Frame type
Change-Id: If55fbf205735f657352c8f21b22fa0858ae183f0
Reviewed-on: https://code.wireshark.org/review/30519
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
- fix byte used for A and Sequence fields
- added missing unused field in MON_GETLIST_1 strcuture
- added dissection of MON_GETLIST structure
- added dissection of Encryption Keyid and MAC fields
Bug: 15258
Change-Id: I7525fcd8daeeeef449294c0d79c2853a852328ed
Reviewed-on: https://code.wireshark.org/review/30514
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Proxy DHCP (proxyDHCP) is described in the PXE specification ver 2.1 (section
2.2.3) as a mechanism to allow a PXE client to query a separate service,
listening on port 4011, to obtain boot file information. Other than the UDP
port number used, the protocol is identical to regular DHCP.
This change implements support for dissecting proxyDHCP packets.
The change expands the default pref value for the DHCP/BOOTP UDP ports list to
include port 4011, and if the dissector receives a packet for port 4011 which
passes a rough heuristic (the DHCP magic number is mandatory for proxyDHCP --
there is no such thing as BOOTP-only proxyDHCP), the packet passes through to
the regular DHCP dissector.
There's currently no separate preference to allow configuration of the expected
proxyDHCP port number... This seems reasonable, since the port number 4011 is
stipulated in the PXE specification, and variations would seem unlikely.
Testing Done: Opened a capture file containing a DHCP conversation using
proxyDHCP, and saw the traffic on UDP port 4011 was now decoded as DHCP and
reported as "proxyDHCP", instead of being generic UDP. Regular DHCP traffic
in the same capture file is still decoded as it was before. Produced some
deliberately malformed requests (bad magic number) and tweaked the
DHCP/BOOTP port list in prefs, and saw the expected behavior in each case.
20,000 iterations of fuzz-test.sh with a small corpus of captures from
PXE-booting systems.
Change-Id: Ifd485cd75834a51bdfd6f3ba3fe517c4a892d9d0
Reviewed-on: https://code.wireshark.org/review/30498
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Bug: 15251
Change-Id: I47e80ea6271f46731cf391a54ceea61c363b6cf7
Reviewed-on: https://code.wireshark.org/review/30481
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Bug: 15251
Change-Id: I1929e96766c32654f3b41c522df5cf22a1c60516
Reviewed-on: https://code.wireshark.org/review/30483
Reviewed-by: Johannes Altmanninger <aclopte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
On many platforms, G_GINT64_MODIFIER is "ll", that gives an error when used with
the float modifier:
../epan/dissectors/packet-tds.c:2270:55: error: length modifier 'll' results in undefined behavior or no effect with 'f' conversion specifier [-Werror,-Wformat]
proto_item_append_text(item, " (%"G_GINT64_MODIFIER"f)", tvb_get_letohieee_float(tvb, *offset));
~~^~~~~~~~~~~~~~~~~~~
/usr/local/Cellar/glib/2.58.1/lib/glib-2.0/include/glibconfig.h:56:28: note: expanded from macro 'G_GINT64_MODIFIER'
#define G_GINT64_MODIFIER "ll"
^
1 error generated.
The solution appears to revert back to %lf.
Fixes: v2.9.0rc0-2411-gdbe2d081ec
Change-Id: I470cc5395921abc14aedd501f27881d5c21c618f
Reviewed-on: https://code.wireshark.org/review/30487
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Neither of the following situations were reading MQTT v5 properties from
the packet, leading to valid MQTT 5 packets being marked as malformed.
CONNECT packet with a Will
UNSUBSCRIBE packet
Bug: 15257
Change-Id: Iedb68e7285832fc5692f793b4354a6402ca8ac8d
Reviewed-on: https://code.wireshark.org/review/30464
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Bluetooth specification says that some bits mean that packet type MAY BE used,
but some other bits meaning is "may NOT be used" what is suprising.
Follow specification by improving description of these fields.
Bug: 15156
Change-Id: Ie3cf11db420fff07b4833878d1131d56575ccc22
Reviewed-on: https://code.wireshark.org/review/30459
Petri-Dish: Michal Labedzki <michal.labedzki@wireshark.org>
Tested-by: Petri Dish Buildbot
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Mikael Kanstrup
Pau Espin