As of now a plugin subdissector can register itself for byte or string type only.
This change adds an option to allow a plugin to register a subdissector for any protbuf field.
this subdissector will be able to dissect a protobuf field on top of the existing dissector for that field.
As of now a plugin subdissector can register itself for byte or string type only.
This change adds an option to allow a plugin to register a subdissector for any protbuf field.
this subdissector will be able to dissect a protobuf field on top of the existing dissector for that field.
SASL Buffer starts after the SASL Buffer Length field. Therefore
we should only mark the bytes without the Length field.
Sample capture can be found in wireshark/wireshark#15128
As of now GTP dissector provides option to decode T-PDU data ether, async, and with some heuristics.
But there is no option present to decode a new protocol with a plugin.
This change adds an option to decode T-PDU data with a plugin, to help develop and test new protocols that are
encapsulated as GTP T-PDU data.
* Since c3342930 we don't free anymore the entries in the files hashtables.
The cleanest solution is probably to convert these hashtables into two
wmem_map_t structures and let the wmem core handling any cleanup.
* b0f5b2c174 added supported for chained compression; the uncompressed
tvb must be freed
guint64 is *not* guaranteed to be an unsigned long int; on an ILP32
platform, it *can't* be a long, as that's only 32 bits. Use
G_GUINT64_FORMAT to format guint64 values.
The Linux kernel includes a module called psample which sends sampled
packets to user-space over generic netlink.
This patch adds a dissector for these netlink packets.
The dissector is expected to be invoked by the generic netlink dissector and
during its hand off routine it adds an entry in the 'genl.family' dissector
table.
The various netlink attributes are dissected by calling
dissect_netlink_attributes(), in a similar fashion to the rtnetlink and
net_dm dissectors. The sampled packet itself is encoded in the netlink
attribute 'PSAMPLE_ATTR_DATA' and dissected by invoking a dissector from the
'sll.ltype' dissector table based on the packet's protocol which is
encoded in the 'PSAMPLE_ATTR_PROTO' attribute.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Extended sequence number added to info structures.
Extended timestamp (from 32 to 64 bit) calculation added and added to
info structures.
Both values simpifies calculations in rest of the code - we don't have
to care about wraparound. Code will be adapted later.
It is invalid to assume that every unknown and/or vendor specific
traffic is IPPUSB. If a vendor specific class is indeed IPPUSB then
the dissector should be selected based on VID/PID.
The way IPPUSB was registering caused packets from devices without
corresponding dissector in Wireshark (majority of the devices in the
wild) being dissected as IPPUSB and shown as Malformed Packets. For
example the Silicon Labs CP210x UART Bridge was dissected as IPPUSB.
Now that FT_PCRE is gone, a GRegex is not a valid value for a field. (A
field can be a *string* field whose value is supposed to be a PCRE, but
that's just FT_STRING/FT_STRINGZ/FT_STRINGZPAD/FT_STRINGZTRUNC, and the
value is the string text.)
In rare circumstances Spurious Retransmissions are not detected
and the SEQ analysis would instead conclude with a Fast Retransmit
or an Out-Of-Order. As Spurious Retransmissions are more certain
than the latter ones, their respective precedences are changed.
The documentation is updated accordingly. Closes#13863.
IXFR and AXFR queries can have multiple DNS responses. As all responses
belong to one transaction, they have the same transaction ID.
We shouldn't handle them as retransmits.
Fix: wireshark/wireshark#17293
It's not a valid field type, it's only a hack to support regular
expression matching in packet-matching expressions.
Instead, in the packet-matching code, have a separate syntax tree type
for Perl-compatible regular expressions, and a separate instruction to
load one into a register, and have the "matching" operator for field
types take a GRegex * as the second argument.
RFC 7230 Section 3.3.3 case 7 allows a (discouraged) behavior
for HTTP responses of desegmenting until connection FIN when the
Content-Length is not given.
(See commit 69e50be150 for details.)
There is an even rarer subcase not currently handled- if the headers
are split aross multiple segments, then we won't know we need to
desegment until FIN until after than the first segment.
In such a case, msp->nxtpdu still needs to get set to some appropriately
large offset, since it didn't happen when processing the first segment.
It's a fake "field" type, used only for "field" values in
packet-matching expressions to do regular-expression matching. There is
*no* reason to allow fields of that type.
Don't bother checking the representation type when generating the string
representation of a field value. If a developer manages to get past all
the tests for FT_PCRE to register and add an instance of that field to
the protocol tree, either 1) the one and only string representation of
an FT_PCRE value is what they want, in which case, whatever, or 2) it's
*not* what they want, in which case, if they file a bug, ask a question
on a mailing list, or ask a question on the Q&A site, we can explain to
them that what they're doing is bogus.
msp->nxtpdu might wrap around (particularly if DESEGMENT_UNTIL_FIN
is set), so use the wrap around aware sequence number comparisons
when seeing if seq is in the interval [msp->seq, msp->nextpdu).
Note that with wraparound, we have to take the minimum after subtracting
to get the length desired.
If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
Support decrypting captures with Fast BSS Transition roaming present
by now also scanning (re)association frames for relevant information
elements and feeding it into the dot11decrypt engine.
Both (re)association request and response frames are scanned to allow
for potentially missing one frame and still be able to derive PTKs
needed for successful decryption.
Closes#17145
Change-Id: I08436582e4f83695dc606ddb92ff442d6258ef9b
If a header declares a function, or anything else requiring the extern
"C" decoration, have it wrap the declaration itself; don't rely on the
header itself being included inside extern "C".
The right format to use is "%" G_GUINT64_FORMAT. A guint64 might be an
unsigned long or it might be an unsigned long long; do not assume which
one it will be on all platforms.
The default value for the CAN-ID Mask is currently 0. If no config is
present, all comparisons would be always true. This leads to all CAN
packets are being dissected by this dissector by default.
This is a huge performance problem and surely not intended.
This patch sets the default of the CAN-ID Mask to 0xffffffff, so that
in the unconfigured case, only the CAN-ID 0 would be dissected.
Since the intention is to add full decoding of the entire page, rewrite the function to use
add_tree_entries() and define decoding structures to avoid repeating the same code for
each decoded block.
packet-ncsi.c:653:55: warning: Although the value stored to 'offset' is used in the enclosing expression, the value is never actually read from 'offset' [deadcode.DeadStores]
packet-mbim.c:2871:5: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-mbim.c:2976:5: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-mbim.c:4053:9: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
Show the first octet of the option, giving the filter type.
Only display the rest of the option as a string if the type is 0,
meaning it's a libpcap-style filter string.
While we're at it, clean up the dissection of the rest of the options:
* do more proto_tree_add_item_ret_XXX to get the option value;
* don't bother constructing a string for the value if we don't have to;
* use proto_tree_add_item_ret_display_string for string values, so we
know they're printable.
Currently organizational specific TLVs without payload cause an
exception which leads to a 'malformed packet' error. Add a check that
allows correctly parsing those TLVs.
Use the data rate and channel to determine 11b vs. 11g vs. 11a for:
* Aruba Networks encapsulated remote mirroring;
* Prism headers;
* *Peek remote protocol;
* Network Instruments^W^WViavi Observer;
* *Peek classic format;
* Shomiti Surveyor.
Note why we *don't* need to do that for NetMon captures.
"CCK" really means "DSSS", whether it uses CCK or not, i.e. it includes
both the legacy 802.11 DSSS PHY (1 Mb/s and 2 MB/s) and the 802.11b
HR/DSSS PHY (5.5 Mb/s and 11 Mb/s). Change the text and the name of a
variable to match.
For OFDM, put the modulation type after the rate, as is done for the
text for other modulations. Put "Rate:" before the rate for all
modulations as well.
* Currently GetRequest messages processed only from ONU object itself
and parsed incorrectly when such a messages originated for Link
and User Port objects. This commit is fixing this parsing issue.
Signed-off-by: Arkady Gilinsky <8351139-ark-g@users.noreply.gitlab.com>
Do more fixups of the "phy" based on the data rate, so that it reflects
the modulation used for the packet.
Note, in comments, why we're doing this, and that there's no reiable
way, in radiotap, to determine the type of channel on which capturing is
being done, as some packet providers use the channel field to indicate
the channel type and others use it to indicate the modulation.
Only provide the "short preamble" for "11b", as that's now being used to
mean "DSSS modulation" - packets on an 11g channel will be marked as
"11g" if they're OFDM or "11b" if they're DSSS.
When the payload_unit_start_indicator is 0, a continued section may be
followed by stuffing bytes. Detect the stuffing bytes based on the SECT
length and handle them in the MPEG2 TS dissector in that case, rather than
handing them to the SECT dissector (which assumes that the incoming tvb
contains only one section and no additional data), similar to how stuffing
bytes are already handled when the PUSI is 1.
Do more fixups of the "phy" based on the data rate, so that it reflects
the modulation used for the packet.
Note, in comments, why we're doing this, and that there's no reiable
way, in radiotap, to determine the type of channel on which capturing is
being done, as some packet providers use the channel field to indicate
the channel type and others use it to indicate the modulation.
Only provide the "short preamble" for "11b", as that's now being used to
mean "DSSS modulation" - packets on an 11g channel will be marked as
"11g" if they're OFDM or "11b" if they're DSSS.
Make some other cleanups while we're at it.
The user interface code is not part of user interface alerts,
so do not try to dissect it.
This makes the corresponding hf field and value string list unused, so remove those.
Use FT_ETHER for the MAC address, unless the scrambling bits are set,
in which case use a FT_BYTES field. Don't put the address in a separate
tvb, so the bytes it is extracted from can be highlighted. Don't decode
the payload if the payload scrambling bits are set. Add value_strings and
expert infos.
When building with GCC 10.2.0 and optimization level 3 some new
warnings turn up. Fix them.
./epan/crypt/dot11decrypt_util.c: In function ‘dot11decrypt_derive_pmk_r0’:
../epan/crypt/dot11decrypt_util.c:308:5: error: ‘sha256_res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
308 | memcpy(pmk_r0_name, sha256_res, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../epan/crypt/dot11decrypt_util.c: In function ‘dot11decrypt_derive_pmk_r1’:
../epan/crypt/dot11decrypt_util.c:357:5: error: ‘sha256_res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
357 | memcpy(pmk_r1_name, sha256_res, 16);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../wiretap/wtap_opttypes.c: In function ‘wtap_block_add_if_filter_option’:
../wiretap/wtap_opttypes.c:782:12: error: ‘*((void *)&filter_dest+8)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
782 | return filter_dest;
| ^~~~~~~~~~~
../wiretap/wtap_opttypes.c: In function ‘wtap_block_set_if_filter_option_value’:
../wiretap/wtap_opttypes.c:782:12: error: ‘*((void *)&filter_dest+8)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
782 | return filter_dest;
| ^~~~~~~~~~~
From tools/check_typed_item_calls.py:
epan/dissectors/packet-mpeg-dsmcc.c:1212 proto_tree_add_item called for hf_dsmcc_dii_private_data_length - item type is FT_UINT8 but call has len 2
- add an option to decrypt even if not strictly in-sequence
DVB-DATA Multiprotocol Encapsulation (MPE) has the table id 0x3E, which
is conformant to DSM-CC sections with private data, and is by far the
most common "private" implementation. Only register MPE as the default
subdissector for 0x3E, don't register DSM-CC as well. (The order of
registration means that MPE is already the current default, but this
is not reliable.)
Support Decode As for the table ids so that DSM-CC can be used instead if
someone really wants that, and so that some other user private dissector
plugin (on 0x3E or any other user private table_id) can be used.
I believe this was the original intention, to use these API restricitons
with dissectors only (not that I necessarily agree with that policy either),
and through copy-paste and lack of clear guidelines it spread to other
parts of the build.
Rename the checkAPI groups to make it very clear that this is dissector-only.
This doesn't mean, of course, that good programming practices shouldn't be
followed everywhere. In particular assertions need to be used properly.
Don't use them to catch runtime errors or validate input data.
This commit will be followed by another removing the various ugly hacks
people have been using to get around the checkAPI hammer.
This commit should be a proper fix for the regression reported in #17250
(7fd71536 is a simple workaround). Such regression has been introduced by
b287e716 while fixing the infinite loop reported in #16897.
b287e716, while fixing the infinite loop, broke the decoding of perfectly
valid tags not yet supported by Wireshark.
AFAIK, the root cause of the infinite loop is the overflow of the `offset`
variable. Therefore checking for this overflow should be sufficient to avoid
the loop.
Note that we already check for sensible values for the 'tag_len' variable;
we should update `total_tag_len` accordingly.
Some words about testing: other than correctly handling unknown but valid
tags, it is important that this commit doesn't reintroduce the infinite
loop bug.
Fortunately #16897 provided a POC trace. Unfortunately, if you revert
b287e716, this POC doesn't work anymore in master-3.4 and master branches,
but it still triggers the infinite loop in master-3.2 branch.
Therefore I have been able to manually check that this MR + the
overflow check is enough to avoid the infinite loop bug, at least in master-3.2.
Some traffic with unknown but valid tags is available in e2ee14ae03.
Commit 73d793788c removed ws_printf.h from
column-utils.c, but left no prototype for snprintf, causing a build failure on
my Debian testing host. Let's #include <stdio.h> here.
1) G_GUINT16_FORMAT produces warnings about mismatched format string
formats and arguments if you use it with a 32-bit value.
2) There's no reason to format into a string buffer and then use
col_append_lstr(); col_append_fstr() suffices. (In col_append_ports(),
the formatting is done with col_snprint_port(), which attempts to
resolve the port number to a name, but we don't do that here, we just
format it as a number.)
Since fe94133f0d ws_snprintf()
and ws_vsnprintf() don't actually do anything anymore.
The return value of ws_[v]snprintf was discarded before,
now it too conforms to C99.
Ranjeet Kumar Singh