The first call to Follow Stream forgot to disable the arrow
button. Reverse the precedence between the display filter edition
and the display filter success now gives the expected GUI behavior.
Closes#10774
Move BSSAP-LE and BSAP to pinos so that Decode As on a SCCP SSN
can specify the protocol of choice. The heuristic dissector still
depends on a preference, but change the existing two boolean
preferences to a three way enum. Separate the BSSAP and BSSAP-LE
dissector tables so that the code is cleaner.
Add BSAP, BSSAP-LE, and BSSAP+ to the SCCP UAT for even finer-grained
control. Fix#16828
The heuristic dissector doesn't always work. It is convenient to have
DVB-S2 in the "decode as" menu as well.
The heuristic dissector does not dissect packets where the modeadapt
cannot be detected (CRC errors or other problems). The "decode as"
dissector, on the other hand, will attempt decoding anyway, using the
preferred mode adaptation set in preferences.
Move the Lintian check from the Ubuntu .dpkg job to the Debian package
job. This should reduce the time it takes to build merge request
pipelines a little bit.
Each "packet" in the USB encapsulation formats for at least
Linux and Darwin corresponds to an OS-level USB request, so
the packets can be much larger than a USB-level packet.
The default max packet length of 256 KiB prevents Wireshark
from loading capture files that contain requests >256 KiB.
(Saving such a capture already works fine.)
Fix this by making the Linux, Darwin, and FreeBSD formats
use the same max packet length as the USBPCap format, which
is 128 MiB.
If a subdissector requests one more segment for a PDU of unknown length,
but we can't do reassembly for whatever reason, that's not necesarily a
dissector bug (while it could be the result of a bad heuristic, it can
happen from a checksum failing validation or reassembly preferences
disabled.)
The correct error is a FragmentBoundsError (dissector requested bytes
that it couldn't get due to not being reassembled), which is what
we would also throw if the returned PDU length were greater than the
tvb length instead of unknown. Fix#16689.
When OpenReceiveChannel/OpenReceiveChannelAck and
StartMediaTransmission/StartMediaTransmissionAck messages are seen, RTP
streams are created so Wireshark decodes related UDP as RTP.
Note: Multichannel commands (e.g. OpenMultiMediaReceiveChannel) are not
processed as I have no sample to test it.
Wireshark defines the relation of equality A == B as
A any_eq B <=> An == Bn for at least one An, Bn.
More accurately I think this is (formally) an equivalence
relation, not true equality.
Whichever definition for "==" we choose we must keep the
definition of "!=" as !(A == B), otherwise it will
lead to logical contradictions like (A == B) AND (A != B)
being true.
Fix the '!=' relation to match the definition of equality:
A != B <=> !(A == B) <=> A all_ne B <=> An != Bn, for
every n.
This has been the recomended way to write "not equal" for a
long time in the documentation, even to the point where != was
deprecated, but it just wasn't implemented consistently in the
language, which has understandably been a persistent source
of confusion. Even a field that is normally well-behaved
with "!=" like "ip.src" or "ip.dst" will produce unexpected
results with encapsulations like IP-over-IP.
The opcode ALL_NE could have been implemented in the compiler
instead using NOT and ANY_EQ but I chose to implement it in
bytecode. It just seemed more elegant and efficient
but the difference was not very significant.
Keep around "~=" for any_ne relation, in case someone depends
on that, and because we don't have an operator for true equality:
A strict_equal B <=> A all_eq B <=> !(A any_ne B).
If there is only one value then any_ne and all_ne are the same
comparison operation.
Implementing this change did not require fixing any tests so it
is unlikely the relation "~=" (any_ne) will be very useful.
Note that the behaviour of the '<' (less than) comparison relation
is a separate, more subtle issue. In the general case the definition
of '<' that is used is only a partial order.
All fragment errors are bounds errors that go past the contained length,
but they do not necessarily involve going past the reported length,
so the checks for FragmentBoundsError should reflect that.
With some forms of reassembly, like IP fragmentation, we don't know how
big the PDU/reassembled packet is until reassembly is complete, so we
probably use tvb_new_subset_remaining() to create fragments and the tvb's
reported length is equal to its contained length. In these cases
ReportedBoundsError would be otherwise thrown, except when the existing
checks for FragmentBoundsError intervene.
However, with other forms of reassembly, like various PDUs carried over TCP,
we know the total PDU length, so we use tvb_new_subset_length[_caplen](),
setting the proper reported length, but not changing the contained
length when reassembly is not performed. In those cases, a bounds error
that occurs due to lack of reassembly is otherwise a ContainedBoundsError,
not a ReportedBoundsError.
In both cases, a bounds error caused by an unreassembled fragment should
be a FragmentBoundsError for the existing reasons. It is not necessarily
a malformed packet (to the extent reassembly is not performed because of a
malformed error elsewhere, that should be reported separately) and can
likely be avoided by changing preferences (e.g., turning reassembly
preferences on, turning off checksum verification, etc.) Otherwise it
is probably a dissector bug.
To enhance the Merge 4644, the isReadRunning variable scope is
changed to reduce the header footprint and make the code compliant
to the usual coding rules.
The fragment length field of DCERPC connection-oriented PDUs includes
the length of the fixed header, and so must be at least that large.
Don't return a (bogus) PDU length zero from get_dcerpc_pdu_len,
because tcp_dissect_pdus interprets that as "need one more segment"
instead of as a bogus value; instead return one, which the TCP
dissector will correctly recognize as bogus.
Also, take into account the offset passed into get_dcerpc_pdu_len
(it is almost always 0, which is why the code previously worked),
and increase the fixed length value passed to tcp_dissect_pdus
to the real fixed header length (so that the TCP dissector will
recognize more bogus values as bogus.)
Fix#14728.
The issue in question is Npcap issue 250, for which work is being
considered in Npcap issue 506; this is all apparently due to Windows
tearing down and reassembling the networking stack in various sitations.
See @jtippet's comments in Npcap issue 250.
We just tell users that this is a known problem, work is being done on
it, so there's no need to report it.
wslog has a small surface, few dependencies and is near essential
for Wireshark development and debugging.
Pulling wmem.h is not a problem either, the library is self contained
and again memory allocation and general data structures are essential
components.
When changing one of the selection parameters in the Follow Stream
dialog while a filtering task is already running, the result is
inaccurate.
While a filtering task is already running in the Follow Stream
dialog, any filter change which triggers a new filtering gives a
wrong result. Both the displayed data and the Save As functions
are impacted. Closes#15637
We know the lengths (or at least bounds on them) for most message
types, so if we have a nonsense value assume that we're actually
seeing Continuation Data (or unsupported Message Stream Encryption.)
Also support the extended message type a little bit, at least to
display the bencoded dictionary when it's type ID 0.
Alexis La Goutte
Vadim Yanitskiy