The existing stuff doesn't appear to work (I tried it on 32-bit Ubuntu
18.04, and it did *not* add any flags to the compilation, as it appeared
not to conclude that they were necessary, even though they were).
Pull in the stuff from libpcap, which *does* appear to work. (it does
so in my 32-bit Ubuntu testing).
This should fix#17301.
While we're at it, fix cppcheck.sh so that it doesn't attempt to run
cppcheck on files that have been deleted.
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.
Visual waveform is derived from decoded audio. When audio is decoded
incorrectly, waveform now shows it.
E.g. on issue 14401 is now audio play aligned with waveform, but it
exhibits that decoded audio is incorrect - about two times longer than
pcap!
Changes:
- samplefile_ renamed to sample_file_
- tempfile_ is renamed to temp_file_
- decode() is separated to decodeAudio and decodeVisual
- Frame info stores frame len and frame_num for every frame. We must hold
it per frame as it may change in time. Info is stored in separate temp file
as waveform samples.
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.
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
Guy Harris