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.
Here's a grab bag of trivial cleanup to the documentation. This change:
- Cleans up some comments in the asciidoctor macros which are no longer
accurate (and do not appear in the build products anyway).
- Fixes a missing space in the text "Wireshark Q&A" in the release notes.
- Allows the "docbook" backend to produce hyperlinks too... That seems to be
necessary if we want to start using our custom link macros in WSDG, which
seems like a reasonable thing to do. And fixes up a wrong variable name in
the handling of the case where we are not able to produce a hyperlink.
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.
Have separate #ifdef HAVE_LIBPCAP ... #endif sections for the includes
and the definitions/declarations.
(There are no good solutions that don't require hopping in a time
machine and changing history.)
Instead, declare each function with EXTERN_C, #defined as extern "C" in
C++ and just extern in C.
This avoids all the thrashing to try to keep headers outside extern "C"
{ by the simple expedient of not *having* extern "C" {.
The extern declaration must be put outside the ifdef to match the
closing statement as well as surrounding al the functions.
Fixes: 2820156fbd (Move still *more* headers outside of extern "C".)
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".
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".
Add comments in various switch statements warning people *not* to add
standardized block types or option codes that aren't in the pcapng spec.
If you want a standardized block or option type, go through the
standards process.
Give details on what happens when running Wireshark from a GUI on
UN*Xes, or, at least, on {macOS,Ubuntu+GNOME,Ubuntu+KDE}, although
it's probably similar on other UN*Xes and on other desktop environments.
Eugene Adell