Have it take a format and argument list as arguments, and have the
formatting done inside the reporting code. That way, we're not relying
on any particular wmem scope working.
If WIRESHARK_ABORT_ON_DISSECTOR_BUG is set, try to add the message to
the crash information (currently only supported in macOS), and print it
to the standard error, before crashing. We won't necessarily have a
usable crash dump to analyze, so we can't rely on that to find the cause
of the crash.
Ping-Bug: 14490
Change-Id: I2b39169c45c84f2ada31efa1d413bd28c140f8f4
Reviewed-on: https://code.wireshark.org/review/26643
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Make it easier to check if traffic over UDP ports is
protobuf-based.
Change-Id: Ib88c4a7a6d2996f53249da6707f35e06b38c7b2d
Reviewed-on: https://code.wireshark.org/review/26625
Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com>
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Using a 32bit value string triggers the assertion in
hf_try_val64_to_str().
Bug: 14560
Change-Id: Ief3f46ee60355f43d2fb5f210608fde21be8d41d
Reviewed-on: https://code.wireshark.org/review/26633
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add dissection of events:
LE Periodic Advertising Sync Established
LE Periodic Advertising Report
LE Periodic Advertising Sync Lost
LE Advertising Set Terminated
LE Scan Request Received
LE Channel Selection Algorithm
SAM Status Change
Add missing extended LMP feature bits
Change-Id: I6aed69ff70674950507a7f4730f4136077c00357
Signed-off-by: Allan Møller Madsen <almomadk@gmail.com>
Reviewed-on: https://code.wireshark.org/review/26631
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Fix "might be clobbered by 'longjmp' or 'vfork' warning
Change-Id: I3c7433568c452782316e37efd9697effdf0ebe0f
Reviewed-on: https://code.wireshark.org/review/26632
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
The RDMA reply chunk is used for a large RPC reply which does not fit
into a single SEND operation and does not have a single large opaque,
e.g., NFS READDIR. The RPC call packet is used only to set up the RDMA
reply chunk. The whole RPC reply is transferred via RDMA writes.
Fragments are added on any RDMA write packet, RDMA_WRITE_ONLY,
RDMA_WRITE_FIRST, etc., and the reassembly is done on the reply
message. The RPC reply packet has no data (RDMA_NOMSG) but
fragments are reassembled and the whole RPC reply is dissected.
The RDMA read chunk list is used for a large RPC call which has
at least one large opaque, e.g., NFS WRITE. The RPC call packet
is used only to set up the RDMA read chunk list. It also has the
reduced message data which includes the first fragment (XDR data
up to and including the opaque length), but it could also have
fragments between each read chunk and the last fragment after
the last read chunk data. The reduced message is then broken
down into fragments and inserted into the reassembly table.
Since the RDMA read chunk list is set up in the RPC call
then do not dissect the upper layer in this case and just
label rest of packet as "Data" since the reassembly will
be done on the last read response.
The protocol gives the XDR position where each chunk must be
inserted into the XDR stream thus as long as the maximum
I/O size is known it is possible to know exactly where to
insert these fragments. This maximum I/O size is set on the
first READ_RESPONSE_FIRST or READ_RESPONSE_MIDDLE but in case
where any of these packets have not been seen then a value
of 100 is used (real value should be at least 1024) but in
this case the message numbers are not consecutive between
chunks but since the total size of all chunks is verified to
make sure there is a complete message to reassemble then all
fragments should be in the correct order.
Fragments are added on any RDMA read packet: RDMA_READ_RESPONSE_ONLY,
RDMA_READ_RESPONSE_FIRST, etc., and the reassembly is done on the
last read response. Since there could be multiple chunks and each
chunk could have multiple segments then the total size must be
checked to complete the reassembly because in this case there
will be multiple READ_RESPONSE_LAST.
The RDMA write chunk list is used for a large RPC reply which has
at least one large opaque, e.g., NFS READ. The RPC call packet is
used only to set up the RDMA write chunk list. The opaque data is
then transferred via RDMA writes and then the RPC reply packet is
sent from the server.
The RPC reply packet has the reduced message data which includes
the first fragment (XDR data up to and including the opaque length),
but it could also have fragments between each write chunk and the
last fragment after the last write chunk data. The reduced message
is then broken down into fragments and inserted into the reassembly
table. Since the RPC reply is sent after all the RDMA writes then
the fragments from these writes must be inserted in the correct
order: the first RDMA write fragment is inserted with message
number 1, since the first fragment (message number 0) will come
from the very last packet (the RPC reply with RDMA_MSG). Also,
the last packet could have fragments which must be inserted in
between chunk data, therefore message numbers from one chunk to
another are not consecutive.
In contrast with the RDMA read chunk list, the protocol does not
allow an XDR position in the RDMA write chunks, since the RPC
client knows exactly where to insert the chunk's data because
of the virtual address of the DDP (direct data placement) item.
There is no way to map a virtual address with an XDR position,
thus in order to reassemble the XDR stream a two pass approach
is used. In the first pass (visited = 0), all RDMA writes are
inserted as fragments leaving a gap in between each chunk.
Then the dissector for the upper layer is called with a flag
letting the dissector know that it is dealing with a reduced
message so all DDP enabled operations handle the opaque data
as having only the size of the opaque but not the data and
reporting back the offset from the end of the message.
Once the upper layer dissector returns, this layer now has a
list of DDP eligible item's offsets which are then translated
into XDR offsets and then the RPC reply packet is broken into
fragments and inserted in the right places as in the case for
the RDMA read chunk list. On the second pass (visited = 1),
all fragments have already been inserted into the reassembly
table so it just needs to reassembled the whole message and
then call the upper layer dissector.
RFC 8267 specifies the upper layer bindings to RPC-over-RDMA
version 1 for NFS. Since RPC-over-RDMA version 1 specifies the
XDR position for the read chunks then only the write chunk DDP
eligible items are handled in the upper layer, in this case the
NFS layer. These are the only procedures or operations eligible
for write chunks:
* The opaque data result in the NFS READ procedure or operation
* The pathname or linkdata result in the NFS READLINK procedure
or operation
Two functions are defined to signal and report back the DDP
eligible item's offset to be used by the upper layers.
Function rpcrdma_is_reduced() is used to signal the upper layer
that it is dealing with a reduced data message and thus should
ignore DDP eligible item's opaque processing and just report
back the offset where the opaque data should be. This reporting
is done using the second function rpcrdma_insert_offset().
Reassembly is done for InfiniBand only. Reassemble fragments using
the packet sequence number (PSN) of each RDMA I/O fragment to make
sure the message is reassembled correctly when fragments are sent
out of order. Also a unique message id is used for each message so
fragments are reassembled correctly when fragments of different
messages are sent in parallel.
The reassembled message could be composed of multiple chunks
and each chunk in turn could be composed of multiple segments
in which each segment could be composed of multiple requests
and of course each request is composed of one or more fragments.
Thus in order to have all fragments for each segment belonging
to the same message, a list of segments is created and all
segments belonging to the same message are initialized with
the same message id. These segments are initialized and added
to the list on the call side on RDMA_MSG by calling
process_rdma_lists.
Bug: 13260
Change-Id: Icf57d7c46c3ba1de5d019265eb151a81d6019dfd
Reviewed-on: https://code.wireshark.org/review/24613
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Fix to use the MD encoding info when decoding some MQ Struct
Change-Id: I0de05efeff41df893b82ac36ad28cfa04c68b1e0
Reviewed-on: https://code.wireshark.org/review/26510
Reviewed-by: Robert Grange <robionekenobi@bluewin.ch>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
We already *have* an exported dissector that always dissects PPP without
HDLC-like framing; the question is whether we should have one that
always dissects PPP with HDLC-like framing (with a check for the
HDLC-like framing, in case, for example, it was negotiated away), but
doesn't check for Cisco HDLC.
Change-Id: I3b3319dd29c7516220b82df626bc6ac520ea0dd9
Reviewed-on: https://code.wireshark.org/review/26622
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There might be HDLC-like framing inside SSTP, even if it eventually gets
negotiated away.
Bug: 14559
Change-Id: Ibc254f221f26c0da905ceff4edff7859a3fec635
Reviewed-on: https://code.wireshark.org/review/26619
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Minor display issues, and show in context tree 2
recently-introduced fields.
Change-Id: I14ecde0059d17abd17767d4d0c34ba093fa1987f
Reviewed-on: https://code.wireshark.org/review/26596
Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
Sadly, "cooked" means the GRE header isn't available; the extra data
pointer is null, so we can't dereference it.
Bug: 14548
Change-Id: I51ae67dcc144b7f5ab3c82dd9adf09b342b29ced
Reviewed-on: https://code.wireshark.org/review/26595
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Fix some wrongly named fields names related to
multiple entry PHRs.
Change-Id: I87b8b53ddfb86255d4840a73cdf4e570b7f9b9f0
Reviewed-on: https://code.wireshark.org/review/26590
Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
This will likely change in the future as we:
- add support for 32-bits of flags for when there are
higher SCellIndex
- possibly add different filters for each type of ph measurement
- possibly add separate filters for the pcmax_c fields
Change-Id: Icb9b242910a41b1b9e448ae2cd1dbd54a418fd36
Reviewed-on: https://code.wireshark.org/review/26507
Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
- remove GEN field, that is obsoleted
- add SIGNAL command
- update return codes following the draft
Bug: 14542
Change-Id: I7eeb6f832d23688d5dc50f68224da9a7612429ff
Reviewed-on: https://code.wireshark.org/review/26553
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
In preparation for QUIC packet decryption, add a method to retrieve the
cipher used in a TLS session. (QUIC embeds the TLS handshake.)
Change-Id: If58e16bd0a01808dafa455ddc6c67ad23f33d7da
Reviewed-on: https://code.wireshark.org/review/26558
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
When a conversation contains two Initial Packet messages or payloads
spanning key updates, then the cipher might be unusable when trying to
decrypt an earlier packet. To solve this, perform decryption on the
first pass only and store the result (error message and plaintext).
Display an error message when payload decryption is not possible due to
missing keys (currently, TLS Exporter secrets from the TLS key log).
Refactor code for adding decrypted results/expert info to reduce code
duplication and have less ifdef's.
Bug: 13881
Change-Id: I932069b09840e14c7ccc6a235f62b8830f1b85aa
Reviewed-on: https://code.wireshark.org/review/26577
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Packet number (PKN) reconstruction must happen sequentially or the wrong
value can be derived. A wrong packet number will also result in
decryption value. Fix this by storing the full packet number per packet.
Always display the full PKN field for use in a column. Improve tracking
of the client and server side.
Bug: 13881
Change-Id: Ia386893e719411c21793aca509a6d07a06823e2e
Reviewed-on: https://code.wireshark.org/review/26574
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Use the exporter secrets as written by NSS or boringssl to derive packet
protection keys.
Test: tshark -r ngtcp2-09.pcap -ossl.keylog_file:ngtcp2-09.keys -V
Known issue: random access dissection of handshake and packet protection
data sometimes fails because packet number reconstruction requires a
sequential pass. This will be fixed later.
Bug: 13881
Change-Id: I58b2379d6bc2a6274b154b26054fa6cbbfa8e8fb
Reviewed-on: https://code.wireshark.org/review/26559
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Add support for "EXPORTER_SECRET" (NSS 3.34, boringssl 1c58471cc9f4) and
"EARLY_EXPORTER_SECRET" (NSS 3.35) key log lines. These secrets can be
used with the TLS-Exporter interface to derive QUIC 0-RTT/1-RTT keys.
Ping-Bug: 13881
Change-Id: I7ff3e51ce0bd868353aacb2e3a52b28f144af341
Reviewed-on: https://code.wireshark.org/review/24981
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Changed type for the bitrate fields, from signed32 to unsigned32.
This fixes the problem of getting "-1" values at G_MAXUINT32.
TS 32.298 refers to TS 29.212 regarding bitrates, in TS 29.212 the
corresponding AVPs are defined as Unsigned32.
Change-Id: I6e0083bf034c7254ab48ca3c2c405cc20f5d6394
Reviewed-on: https://code.wireshark.org/review/26585
Petri-Dish: Graham Bloice <graham.bloice@trihedral.com>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
If the previous TCP segments already form one or more PDUs, then the
data source of these segments must not be removed. Otherwise
get_field_data (epan/print.c) will fail to find the data source which
correspond to the fields within these PDUs.
Also tested with the capture referenced in v1.11.3-rc1-1525-g21e0a63b29
(bug 9169), the "tshark -Vr mem-leak.pcap" output remains unchanged.
Bug: 14472
Change-Id: Ia448a6b84dd2eb84b00e56d3fcde04f7bec05b9d
Reviewed-on: https://code.wireshark.org/review/26397
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
In function 'add_header' coгple of if-statements didn't corespond
to comments above.
Change-Id: Idd846cebf7e17d0e2f49c7c7d3de466b899c73c6
Reviewed-on: https://code.wireshark.org/review/26573
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Draft -20 shortened the label used by Key Update, adjust accordingly.
Change-Id: I3761b94933165a65fd810eff7bef4373290346cd
Ping-Bug: 12779
Reviewed-on: https://code.wireshark.org/review/26554
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
This should solve the missing prototypes warnings
Change-Id: Iaf2ac6c0a151cfb614f76c4a6bb103e0210d3808
Reviewed-on: https://code.wireshark.org/review/26567
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
That dissector expects to be handed an 802.11 pseudoheader; the GRE
dissector passes the flags and version from the GRE header to
subdissectors registered in the gre.proto table, so they'd better either
expect the flags-and-version structure or ignore the pseudoheader. (For
802.11, the pseudoheader has radio information, but that's not available
from GRE.)
Use the no-FCS 802.11 frame dissector instead.
Bug: 14544
Change-Id: I6515901dc3674eb36ec768fa4f9a7a4040a78365
Reviewed-on: https://code.wireshark.org/review/26560
Reviewed-by: Guy Harris <guy@alum.mit.edu>
GSMTAP_TYPE_LTE_NAS has been set to 0x12 by osmocom:
https://gerrit.osmocom.org/5018
Change-Id: Ia248e54cd73eaa9b8ad02aa40145e5a87baca79e
Reviewed-on: https://code.wireshark.org/review/24554
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Filter does not work due to same shared short name for cell-id being used for two different asn.1 defintions
cell-ID OCTET STRING,
cell-ID CellIdentity,
Change-Id: I5921bc82d46f38d43f9083e41d3a0558821042eb
Reviewed-on: https://code.wireshark.org/review/26545
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Pavel Strnad <pavel_strnad@hotmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Use a single filter for short/long (truncated) BS values to ease
filtering.
Rename other filters to the new mac-nr.bsr.* format.
Fill the missing entries in 8 bits buffer size levels array.
Change-Id: If150f9a951efb40e554c5ea18639cfd4539a1319
Reviewed-on: https://code.wireshark.org/review/26539
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
RFC 7668 section 3.2.2 states that IID formed from the 48-bit Bluetooth
device addresses does not toggle the Universal/Local bit, but Linux
kernel BT IPSP code before version 4.12 does toggle this bit.
Add an option to turn this on when needed.
Change-Id: I77f84a5d56e77bb2c61770237fe53367498cc194
Reviewed-on: https://code.wireshark.org/review/26533
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
Guy Harris