For GTP session tracking (off by default), there's a mapping
from <TEID, ADDRESS> to frame numbers. The current implementation
is a tree (converting the address to a string for keys) of linked
lists of the TEIDs. That gets very slow when there's a large number
of TEIDs. Convert it to a map that uses the teid and address,
with the TEID used for the hash.
There's still a reverse lookup (foreach_remove) when TEIDs are reused
or sessions fail, but this still yields over a 10x speedup on a
few moderate sized test files (~50000 GTP-C packets).
The session table maps frames (which are 32 bit uints that
start at 1) to sessions (which are also 32 bit uints that
start at 1), so use GUINT_TO_POINTER and the direct hash
functions instead of creating extra file scope pointers.
Like wmem_map_remove(), this frees the key/value pair item
in the map but not the key or the value itself (which may
in fact be the same object.) Not generally a problem, as
they'll get freed by the pool. (If someone wants to manage
memory themselves, they should probably be using a GHashTable.)
Handle PHY Update procedure where both PHY fields are set to no change.
This procedure is terminated immediately without instant.
The instant field is reserved for future use.
This fixes the Control Procedure validation not marking this procedure
as terminated, and marking all following control procedures as invalid
since the instant has not yet been reached.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
The correct place to delete the dissector_info_t pointers added
to the editor is when destroyEditor is called. Override the
virtual function and delete the pointers for the colProtocol
index before calling the inherited function.
Fix#17127
Don't update the end of the msp on a second pass. (This
can only happen if we had some reassembly that didn't finish
in the first pass and got left dangling needing one more
segment. But that information is only used in the first pass.)
Use the same check as done in the TCP dissector.
Related to #18342.
Instead of having the UI have to know about each type of follow
stream, and how to retrieve its total number of streams, have
each follow type register a function that returns the total
number of stream. (The function can be NULL, for protocols like
SIP that do not use this.)
This gets us closer to making follow stream registration generic.
If we get a SYN packet with the same sequence number as the current
conversation, but after a RST (or FIN) segment, create a new
conversation.
In such a case, this is probably a peer using the same sequence
number to retry a handshake that failed with a RST due to a half-open
connection. The RST (or ACK that caused a RST) would have an
out-of-window sequence number (or inapplicable ACK for the rest of
the conversation), which can disrupt the follow info, sequence analysis,
desegmentation, etc. unless we create a new conversation.
It could also, less likely, be a new connection after a connection close
that happened to reuse the same sequence number, in which case we also
want to clear out our conversation state.
If we haven't received a RST (or FIN), then consider it a retransmission.
Fix#18333 (also handles the cases of #16944 and #17616 more smoothly).
Have a "CoAP for TMF" dissector that the user can use Decode As to
assign to a UDP port.
Have a "coap_tmf_media_type" dissector table in which the TMF code can
register itself for the media type "application/octet-stream".
Have the "CoAP for TMF" dissector pass a "this is for TMF" flag to the
common dissection code. In the common dissection code, if that flag is
set, first try the media type with the "coap_tmf_media_type" dissector
table before trying it in the regular "media_type" table.
This allows a user to specify UDP ports that 1) should be decoded as
CoAP and 2) should have an application/octet-stream payload dissected as
a TMF message, which should address concerns raised for Thread in issue
Rename dissector_handle_get_long_name() and
dissector_handle_get_short_name() to
dissector_handle_get_protocol_long_name() and
dissector_handle_get_protocol_short_name(), to clarify that they fetch
names for the protocol that the dissector dissects, not for the
dissector *itself*. Leave a deprecated
dissector_handle_get_short_name() wrapper, and export
dissector_handle_get_protocol_long_name(), as it's now used in some
dissectors.
Change some calls to dissector_handle_get_description() back to
dissector_handle_get_protocol_short_name(), as they appear to be made in
order to display a *protocol* name.
Rename some methods, variables, enums, and table column names to reflect
cases where the dissector description is being used.
Similar to work done in !8070 and !8072 to move off a function
that was deprecated in Qt5 and obsoleted in Qt6. Also migrate to
syntax laid out in !4560 and !4565.
It defaults to the short name of the protocol dissected by the
descriptor, but it's now possible to register a dissector with an
explicit description.
This is mainly for use in the Decode As UI. It handles the case where
the same protocol might have different "Decode As..."-specifiable
dissectors for different situations.
As noted in the comment for e5951765d8,
mechanisms by which a dissector can attempt to infer the protocol over
which its protocol was transported aren't reliable.
To add to that, another failure case for inferring it from the previous
entry in the pinfo->layers list is a packet transported over TCP using
MPTCP, as the previous entry would be MPTCP, not TCP.
So we provide multiple CoAP dissectors:
- CoAP over WebSockets;
- CoAP over TCP, TLS, or other byte-stream protocols;
- CoAP over other transports;
and have them pass the transport type to a common dissection routine.
We then register the appropriate dissectors in various dissector tables,
and register the CoAP-over-other-transports dissector as the "coap"
dissector.
According to RFC 8489:
Sec 1: "All STUN messages start with a fixed header that includes a method,
a class, and the transaction ID".
Sec 14.7: "The value of the attribute is computed as the CRC-32 of the STUN
message up to (but excluding) the FINGERPRINT attribute itself".
Even if the RFCs are not cristal clear, it seems that the "TCP Stream
length" field (described in RFC 4571) should be excluded from the CRC-32
calculation.
The proto_item_XXX_text() routines and proto_tree_add_XXX_format[_value]
functions allow dissectors to alter the representation string for
a protocol tree item with data that may come from arbitrary packet data.
These values are displayed by tshark or wireshark, so they should made
into printable, valid UTF-8.
This means that dissectors no longer need to call format_text before using
those functions (though, if they want to produce some other kind of
printable string, such as with format_text_wsp, they still can.)
Also, mark when appending and prepending text truncates a string that
was not previously truncated (except for a small number of cases where
it is difficult to determine if it was truncated before.)
Part of #18317
A given protocol's packet format may depend, for example, on which
lower-level protocol is transporting the protocol in question. For
example, protocols that run atop both byte-stream protocols such as TCP
and TLS, and packet-oriented protocols such as UDP or DTLS, might begin
the packet with a length when running atop a byte-stream protocol, to
indicate where this packet ends and the next packet begins in the byte
stream, but not do so when running atop a packet-oriented protocol.
Dissectors can handle this in various ways:
For example, the dissector could attempt to determine the protocol over
which the packet was transported.
Unfortunately, many of those mechanisms do so by fetching data from the
packet_info structure, and many items in that structure act as global
variables, so that, for example, if there are two two PDUs for protocol
A inside a TCP segment, and the first protocol for PDU A contains a PDU
for protocol B, and protocol B's dissector, or a dissector it calls,
modifies the information in the packet_info structure so that it no
longer indicates that the parent protocol is TCP, the second PDU for
protocol A might not be correctly dissected.
Another such mechanism is to query the previous element in the layers
structure of the packet_info structure, which is a list of protocol IDs.
Unfortunately, that is not a list of earlier protocols in the protocol
stack, it's a list of earlier protocols in the dissection, which means
that, in the above example, when the second PDU for protocol A is
dissected, the list is {...,TCP,A,B,...,A}, which means that the
previous element in the list is not TCP, so, again, the second PDU for
protocol A will not be correctly dissected.
An alternative is to have multiple dissectors for the same protocol,
with the part of the protocol that's independent of the protocol
transporting the PDU being dissected by common code. Protocol B might
have an "over a byte-stream transport" dissector and an "over a packet
transport" dissector, with the first dissector being registered for use
over TCP and TLS and the other dissector being registered for use over
packet protocols. This mechanism, unlike the other mechanisms, is not
dependent on information in the packet_info structure that might be
affected by dissectors other than the one for the protocol that
transports protocol B.
Furthermore, in a LINKTYPE_WIRESHARK_UPPER_PDU pcap or pcapng packet for
protocol B, there might not be any information to indicate the protocol
that transports protocol B, so there would have to be separate
dissectors for protocol B, with separate names, so that a tag giving the
protocol name would differ for B-over-byte-stream and B-over-packets.
So:
We rename EXP_PDU_TAG_PROTO_NAME and EXP_PDU_TAG_HEUR_PROTO_NAME to
EXP_PDU_TAG_DISSECTOR_NAME and EXP_PDU_TAG_HEUR_DISSECTOR_NAME, to
emphasize that they are *not* protocol names, they are dissector names
(which has always been the case - if there's a protocol with that name,
but no dissector with that name, Wireshark will not be able to handle
the packet, as it will try to look up a dissector given that name and
fail).
We fix that exported PDU dissector to refer to those tags as dissector
names, not protocol names.
We update documentation to refer to them as DISSECTOR_NAME tags, not
PROTO_NAME tags. (If there is any documentation for this outside the
Wireshark source, it should be updated as well.)
We add comments for calls to dissector_handle_get_dissector_name() where
the dissector name is shown to the user, to indicate that it might be
that the protocol name should be used.
We update the TLS and DTLS dissectors to show the encapsulated protocol
as the string returned by dissector_handle_get_long_name(); as the
default is "Application Data", it appeaers that a descriptive name,
rather than a short API name, should be used. (We continue to use the
dissector name in debugging messages, to indicate which dissector was
called.)
Prevent crash due to premature menu object deletion caused by call to
QCoreApplication::processEvents() by executing the slot only after menu
handling has finished.
Fixes#18251 and #18270
The data argument to oscore_dissect(), so don't mark it as unused.
As long as we're declaring a proto_reg_handoff_oscore(), we should
define one; it can serve as a container if we ever have any phase-2
(handoff phase) registration work to do.
Pass in the correct length of the percent decoded string, which
is not necessarily the same as the value calculated from the offsets.
Fix#18322. Fix#18325.
Qt6 removed QComboBox:currentIndexChanged(QString), which had
previously been deprecated in favor of the version with an int.
Switch to using the supported function, so that the comboboxes
work.
The models used for the resolved addresses require that the
source models be set first before setting other properties,
so do that so that filtering works.
For some reason the portTypeModel has to indicate that the
port number column is numeric in order for the ports to
numerically sort instead of lexicographically, so do that too.
Add the Ethernet addresses in their specific groups (Addresses,
Manufacturers, Well-Known Hosts) instead of adding them all
to the Well-Known hosts groups, so that that filtering works.
Fix#18087
Strip the timestamps and function names from extcap errors before
displaying them in a dialog. This keeps us from spewing
```
Error by extcap pipe: ** (falcodump:24913) 15:08:20.263535 [falcodump
WARNING] extcap/falcodump.cpp:593 -- main(): cloudtrail plugin error:
failed to list objects: ExpiredToken: The provided token has expired.
status code: 400, request id: M2PYJOT4JGVAA6B9, host id:
+4V8Q+DGV+80Jd3fdc7tODyVdTRvepNgCD9zuvXeL7kzvp2oikaoi9CLMW+UKt/
aR1G2UXIqyQ8=
```
at the user.
Check for warning messages and set our dialog type accordingly.
John Thacker