In the past, tvb_reported_length_remaining(), and thus
Tvb:reported_length_remaining(), may have returned -1 if the offset was
invalid. That's no longer the case; the former returns 0, and, as the
latter just returns the former's return value, that's true of the latter
as well.
It has a "reported length", which is the closes thing to an "actual
length", as it represents the length the packet, or subset thereof, had
on the network, and a "captured length", which is the amount of the
packet that the capture process saved.
In 99.999999999999999999999999999999% of all cases, a dissector should
look at the "reported length", not at the "captured length".
Rename the "len" method to "captured_len", leaving "len" around for
backwards compatibility.
Fix the documentation to reflect reality, to avoid issues such as #15655.
Fixes field names and sets field values to be consistent
with equivalent HT and VHT capabilities fields as indicated
in the IEEE Std 802.11ax-2021 amendment.
Add dissect_netlink_attributes_to_end(), which takes no length argument,
and uses tvb_ensure_reported_length() to get the remaining length in the
packet.
In dissect_netlink_attributes_common(), treat negative lengths as if
they were a positive length >= 2^31, and throw a reported bounds error.
Also, throw a bounds error if there's more padding to a 4-byte boundary
than there is data in the packet.
At that point, we know the length is positive, so assign it to an
unsigned variable and use *that* in the loop. Throw an error if the
attribute goes past the end of the packet (although we presumably would
have done that already).
(We really should eliminate all use of -1 as "to the end", and make
lengths unsigned. We should also get rid of any places where we're
using negative offsets as offsets from the end of the packet - in the
few cases where you're dealing with trailers, you want to do that
carefully, so as not to throw an exception dissecting the trailer before
you get around to dissecting the rest of the packet - and make offsets
unsigned as well.)
It is to tvb_reported_length_remaining() as
tvb_ensure_captured_length_remaining() is to
tvb_captured_length_remaining() - it throws an exception if the offset
is out of range.
(Note that an offset that's just past the end of the {reported,
captured} data is *not* out of range, it just means that there is no
data remaining. Anything *past* that is out of range and thus invalid.)
This big patch addresses the following items:
* implement the "message" virtual channel so that multi-transport and bandwidth
PDUs are dissected;
* prepare the identification of static channels to be able to dissect them later;
* fix the compression field in channelPDUHeader.channelFlags;
* implement the drdynvc channel dissector, so now we decode the traffic on this
channel and we're able to track data on dynamic channels and transition to UDP
transport
They don't include any attributes - they're not large enough to contain
anything other than the netlink message header and the one-byte address
family. For legacy messages, the attribute we hand to
dissect_netlink_route_attributes() is not aligned on a 4-byte boundary,
as it's the offset right after the 1-byte address family value;
dissect_netlink_route_attributes() will try to align that on a 4-byte
boundary, but that will go past the "immediately after the end of the
packet" offset, which can cause problems if any checking is done to make
sure the offset is valid. Therefore, we don't try to dissect the
attributes, rather than relying on the attributes dissector to discover
that there's nothing left in the packet.
A domain filter can be given in the environment variable
'WS_LOG_DOMAINS' or in a command-line options "--log-domains".
The filter is specified as a comma separated case insensitive list,
for example:
./tshark --log-domains=main,capture
Domain data type switches from an enum to a string. There is no
constaint on adding new domains, neither in code or at runtime.
The string format is arbitrary, only positive matches will produce
output.
Note that it was impossible to actually overflow
the buffer, and there is a check to flush and restart
if it gets to within a few bytes of the end, but static
analyzers (CID: 1477927) are unlikely to be able to work
this out.
Guy Harris