It reads better, at least to me.
Change-Id: I4b11449ea32d77e95bfbc54029b7afed7ea17c64
Reviewed-on: https://code.wireshark.org/review/27081
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The Osmocom GSUP protocol is a light-weight alternative to the
classic GSM MAP protocol. It operates between (MSC|SGSN) and HLR.
Change-Id: I954c7e332dce3a8855f7f4ace0b878f66da6f02e
Reviewed-on: https://code.wireshark.org/review/25477
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The radiotap HE-MU header is being completely reworked and likely expanded
in size. There are likely very few captures at the moment with such radiotap
headers. Rather than ripping the code out and seeing problems in the future
I have attempted to warn people who encounter such captures that they need
to upgrade. The standard will settle out soon.
Change-Id: I69eea20e2e65197a837a48706f9bcdddbbe42a63
Reviewed-on: https://code.wireshark.org/review/26995
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The command ID was passing the value of the cmd_id instead of the
encoding for the proto_tree_add_item. This caused an issue with the
color control cluster where it wasn't parsing the command ID properly.
Change-Id: Iee42031146e37bb96182f765e79de47f6e4b5a04
Reviewed-on: https://code.wireshark.org/review/27064
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This puts more distance between the caller and the underlying
library. At the moment we're using libjsmn, but other libraries
(like json-glib) could be used.
Change-Id: I1431424a998fc8188ad47b71d6d95afdc92a3f9e
Reviewed-on: https://code.wireshark.org/review/27055
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
For a value_string_ext, the values must be in numerical order.
Change-Id: I43063b59a8c15d7d1fcdca07d4ae9fd89917427d
Reviewed-on: https://code.wireshark.org/review/27058
Reviewed-by: Guy Harris <guy@alum.mit.edu>
../epan/tvbuff.c: In function 'tvb_new_octet_aligned':
../epan/tvbuff.c:274:26: error: 'abs_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
*rem_len = tvb->length - *offset_ptr;
^
../epan/tvbuff.c:486:8: note: 'abs_offset' was declared here
guint abs_offset, rem_length;
^
../epan/tvbuff.c: In function 'tvb_find_line_end':
../epan/tvbuff.c:274:26: error: 'abs_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
*rem_len = tvb->length - *offset_ptr;
^
../epan/tvbuff.c:486:8: note: 'abs_offset' was declared here
guint abs_offset, rem_length;
^
../epan/tvbuff.c: In function 'tvb_find_line_end_unquoted':
../epan/tvbuff.c:274:26: error: 'abs_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
*rem_len = tvb->length - *offset_ptr;
^
../epan/tvbuff.c:486:8: note: 'abs_offset' was declared here
guint abs_offset, rem_length;
Change-Id: Iba9fe31ac5fcf604d65bbf3bceef0c09004c1b6c
Reviewed-on: https://code.wireshark.org/review/27050
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Draft 11 swapped the Connection ID field with version in long packet.
CIDs are split into two and can now become up to 18 bytes. The column
will now display "DCID=1234" (or "SCID=1234" instead of "CID: 0x1234").
Recognize new short header flags, but maintain draft -10 dissection.
The VN and Long Header packet share much more common fields now, so pull
out some code from Long Header packets dissection.
Drop "LH", "SH" (can be inferred from other information) and
unabbreviate "VN" for columns.
Bug: 13881
Change-Id: Ifabd8f09f388f0c4c6afe78d939c1cff6b5f161b
Reviewed-on: https://code.wireshark.org/review/27009
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add a "contained length" to tvbuffs. For non-subset tvbuffs, that's the
same as the reported length. For a subset tvbuff, that's the amount of
the reported data that was actually present in the "contained data" of
the parent tvbuff.
This is unaffected by the *captured* length of any tvbuff; that differs
from the contained length only if the capture was cut short by a
snapshot length.
If a reference is within the reported data, but not within the contained
data, a ContainedBoundsError exception is thrown. This exception
represents a protocol error, rather than a reference past the captured
data in the packet; we treat it as such.
Change-Id: Ide87f81238eaeb89b3093f54a87bf7f715485af5
Reviewed-on: https://code.wireshark.org/review/27039
Reviewed-by: Guy Harris <guy@alum.mit.edu>
We no longer have TVBUFF_ values corresponding to different types of
tvbuff; we have, instead, a set of method pointers for the different
types. Refer to the types by name, rather than by TVBUFF_ value.
Expand the description of some fields in the tvbuff structure.
Change-Id: I38b5281df247ddd66b4e39abfc129053a012d241
Reviewed-on: https://code.wireshark.org/review/27036
Reviewed-by: Guy Harris <guy@alum.mit.edu>
[packet-ber.c:2687]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
[packet-erf.c:2475]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
[packet-fmp.c:378]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
[packet-http2.c:2050]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
[packet-obd-ii.c:643]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
[packet-yami.c:244]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
Change-Id: Ie71f9f7c8f863d1e9c693bd56444f00bdad48042
Reviewed-on: https://code.wireshark.org/review/27019
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
The generated elastic mapping file is huge and it can hassle softwares
like Kibana. This change adds the ability to append desired filters
that will appear in the mapping file.
This change adds the option --elastic-mapping-filter <protocols> to tshark.
Example: tshark -G elastic-mapping --elastic-mapping-filter ip,udp,dns
make only those 3 protocols to appear in the mapping file.
Change-Id: Ie2dcd6e44be2d084e8e50cd6554bd90178da4e38
Reviewed-on: https://code.wireshark.org/review/27001
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Dario Lombardo <lomato@gmail.com>
JSON-GLIB depends on GObject. To avoid "undefined reference to
'g_object_unref'" with the gold linker, include gobject directly.
As the files are included with the GLib package, adjust FindGLIB2.cmake.
Change-Id: I007d30b89cc07d8746cee6b619832a722f086105
Fixes: v2.9.0rc0-201-g511c2e166a ("tshark: add -G elastic-mapping report.")
Reviewed-on: https://code.wireshark.org/review/27007
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
If the option length is >= 2, so that it's long enough to include the
code and length, always put it into the protocol tree, even if the
length is invalid. If the length is invalid, attach an expert info item
to the length field, rather than putting it into a top-level item of its
own.
Use a length of -1 for the top-level item for an option, rather than
what the length is supposed to be; that way, we don't throw an exception
if the option is too short - we just attach the aforementioned expert
info item to the length.
Change-Id: If2d987fa10739a7da28ca2c39515bfdf50da6ef9
Reviewed-on: https://code.wireshark.org/review/27018
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Drop support for draft -08 and draft -09, add support for draft -10
handshake decryption only (requires a new salt as well as a HKDF label
change). Fixed a bug in qhkdf_expand (swapped length and "QUIC " label)
which affects KeyUpdate (which was initially untested).
Bug: 13881
Change-Id: I5f3e2fe71ef0fd929d3271ecea3a8870f90e3934
Reviewed-on: https://code.wireshark.org/review/26992
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Previously a filter such as `http.request.method in {"GET"HEAD""}` would
be parsed as three strings (GET, HEAD and an empty string). As it seems
more likely that people make typos rather than intending to construct
such a filter, forbid this by always requiring a whitespace separator.
Change-Id: I77e531fd6be072f62dd06aac27f856106c8920c6
Reported-by: Stig Bjørlykke
Reviewed-on: https://code.wireshark.org/review/26989
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
For numeric values such as port numbers, "4430..4434" looks more
natural than "4430 .. 4434", so support that.
To make this possible, the display filter syntax needs to be restricted.
Assume that neither field names nor values can contain "..". The display
filter `data contains ..` will now be considered a syntax error and must
be written as `data contains ".."` instead. More generally, all values
that contain ".." must be quoted.
Other than the ".." restriction, the scanner deliberately accepts more
characters that can potentially form invalid input. This is to prevent
accidentally splitting input in multiple tokens. For example, "9.2." in
"frame.time_delta in {9.2.}" is currently parsed as one token and then
rejected because it cannot be parsed as time. If the scanner was made
stricter, it could treat it as two tokens (floats), "9." and "2." which
has different meaning for the set membership operator.
An unhandled edge case is "1....2" which is parsed as "1 .. .. 2" but
could have been parsed as "1. .. .2" instead. A float with trailing dots
followed by ".." seems sufficiently weird, so rejection is fine.
Ping-Bug: 14180
Change-Id: Ibad8e851b49346c9d470f09d5d6a54defa21bcb9
Reviewed-on: https://code.wireshark.org/review/26960
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Allow "tcp.srcport in {1662 1663 1664}" to be abbreviated to
"tcp.srcport in {1662 .. 1664}". The range operator is supported for any
field value which supports the "<=" and "=>" operators and thus works
for integers, IP addresses, etc.
The naive mapping "tcp.srcport >= 1662 and tcp.srcport <= 1664" is not
used because it does not have the intended effect with fields that have
multiple occurrences (e.g. tcp.port). Each condition could be satisfied
by an other value. Therefore a new DVFM instruction (ANY_IN_RANGE) is
added to test the range condition against each individual field value.
Bug: 14180
Change-Id: I53c2d0f9bc9d4f0ffaabde9a83442122965c95f7
Reviewed-on: https://code.wireshark.org/review/26945
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
It has been replaced by cmake.
Change-Id: I83a5eddb8645dbbf6bca9f026066d2e995d8e87a
Reviewed-on: https://code.wireshark.org/review/26969
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Iff833bf5c197959c8decb62d6ce794c6d0415fb7
Reviewed-on: https://code.wireshark.org/review/26978
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>