Have tvb_get_string_time use iso8601_to_nstime for
ENC_ISO_8601_DATE_TIME (which seems to be the only time in a string
encoding any built in dissector actually uses, in syslog). It is
strictly superior; among other things it handles fractional seconds.
Also, tvbuff.c does not use strptime, so remove that include.
Convert the tm struct to nstime first, then apply the timezone
offset, because applying the offset to the hours and minutes fields
directly can require carrying or borrowing in base 24 and 60 arithmetic.
C is notoriously difficult to bind from other languages
without additional metadata. The C ABI does not include
enums and macros that are an essential component of the
API.
To make Wireshark instrospectable and more binding friendly
include an introspection API to export enums and integer macros.
To avoid the tedious need to manually keep the code up to date
it uses the excellent pyclibrary python package to automatically
parse C headers and extract this data.
This is not a process that should be done automatically during
the build.
This could be used for example to replace most of the wslua
make-init-lua.pl perl script, which tries to do the same thing
using regular expressions.
Besides the downside of using Perl using regular expressions
is inferior to pyclibrary in 2 ways: 1) pyclibrary understands
most of C99 grammar so it is much more powerful; 2) pyclibrary
has a specific API to extract "values" (enums and constants)
automagically. We just need to take care to use only integer
values, for our purposes.
Just break out of this loop if we wraparound sequence numbers in
the middle of a segment. That guarantees that the sequence of lookups
in the tree with _le will terminate at some point. This probably
makes the dissection a little worse in a few cases with sequence
number wrap around but non erroneous sequence numbers, so a more
complete fix would be ideal. Fix#17749, at least the infinite loop.
Add an UAT for configuring fake headers according to the server port, stream
id and direction of the long-lived stream that we start capturing packets
after it is established. That helps to parsing the DATAs captured subsequently.
A testcase also added.
close#17691
Don't blindly examine the fifth byte in the input string without testing
earlier bytes. Instead, process the year by hand before calling sscanf.
ISO 8601 times don't switch between Basic and Extended format in the
middle, so for the later possible buffer overflows just use the
previously determined format.
Qt5 recommended to use QRegularExpression instead of QRegExp.
Qt6 deprecated QRegExp and provides it in Qt5 compatibility module.
QRegularExpression is generally faster and safer to use as the results
are returned in separate QRegularExpressionMatch instead of modifying
interal QRegExp object state.
The RTMPT dissector when over TCP reuses the TCP sequence numbers, so
it needs to consider wraparound, which can occur both with the
tcp.relative_sequence_numbers preference set to FALSE, or in some
unusual cases (such as a SYN packet with a bogus sequence number so
that later packets overlap its sequence number.)
Change a sequence number comparison to use the wrap around aware
macros from packet-tcp.h Fix#17745.
This is basically applying c knowledge and Google to the compiler
error messages. There is basically no understanding involved into
what I was doing:
- No idea why lots of #includes needed to be added for Qt6
- No idea how to actually fix the remaining problems, but it's a start
Things that need to be done:
- The AudioDeviceInfo thingy needs to be replaced by something new (as
an interim solution another patch disables the audio player in Qt6).
- GRegExp eventually needs to be replaced by QRegularExpression
(available since Qt5.0, so development can be done in Qt5).
- Solutions for the other problems like some methods no longer
being available in Qt6 that have to sort of co-exist with Qt5.
In order to be able to defer solving all Qt6 API differences at once
I tried to reactivate the QT_MULTIMEDIA_LIB feature. I managed to fix
most problems but one problem remains in both Qt5 and Qt6 builds.
Without Qt[56]Multimedia, the following error exceeds my non-existing
C++ knowledge:
jmayer/work/wireshark/git/ui/qt/rtp_player_dialog.cpp:154:18: error: out-of-line definition of 'RtpPlayerDialog' does not match any declaration in 'RtpPlayerDialog'
RtpPlayerDialog::RtpPlayerDialog(QWidget &parent, CaptureFile &cf, bool capture_running) :
^~~~~~~~~~~~~~~
Of course it still fails in the compile phase, but only for some
of the ui/qt/ files.
Wireshark with Qt5 still compiles and runs.
To do the build invoke cmake with the following settings added:
export CMAKE_PREFIX_PATH=:${MY_QT6_PREFIX}/lib/cmake
cmake -DUSE_qt6=ON ...
Independently of this patch there is lots of Qt-stuff in
CMakeLists.txt that needs review/cleanup:
- Some of the stuff can probably be solved in a less hacky way:
+ There seemed to be a way for QT6 to provide the required c++-standard,
but in the end I could not find it.
+ Once we have a working Qt6 codebase, we may get rid of the USE_qt6
flag and just test for Qt6Core first and if not present check for
Qt5Core.
- All comments that match /qt ?[4-6]/i need reviewing/cleaning up.
- The changes in this patch have been tested to work on all machines
that are my mac (macos 12.0.1, XCode 13.1, Intel, GPL-Qt6.2.1 with only
the macos package selected, cmake 3.21.4)
Add ui/qt/qt6-migration-links.txt for some possibly helpful links
Invalid character constants should be handled in the lexical scanner.
Todo: See if some code could be shared to parse double quoted strings.
It also fixes some unintuitive type coercions to string. Character
constants should be treated as characters, or maybe integers, or
maybe even throw an invalid comparison error, but coverting to a
literal string or byte array is surprising and not particularly
useful:
'\xFF' -> "'\xFF'" (equals)
'\xFF' -> "FF" (contains)
Before:
Filter: http.request.method contains "\x63"
Constants:
00000 PUT_FVALUE "c" <FT_STRING> -> reg#1
(...)
Filter: http.request.method contains '\x63'
Constants:
00000 PUT_FVALUE "63" <FT_STRING> -> reg#1
(...)
Filter: http.request.method == "\x63"
Constants:
00000 PUT_FVALUE "c" <FT_STRING> -> reg#1
(...)
Filter: http.request.method == '\x63'
Constants:
00000 PUT_FVALUE "'\\x63'" <FT_STRING> -> reg#1
(...)
After:
Filter: http.request.method contains '\x63'
Constants:
00000 PUT_FVALUE "c" <FT_STRING> -> reg#1
(...)
Filter: http.request.method == '\x63'
Constants:
00000 PUT_FVALUE "c" <FT_STRING> -> reg#1
(...)
The original MACsec capability value strings do not reflect the
IEEE 802.1X specification (2010 or 2020).
For example: IEEE 802.1X says for value 2:
"‘Integrity without confidentiality’ and ‘Integrity and
confidentiality’ with a confidentiality offset of 0"
The packet-mka.c value string for 2 says:
"MACsec Integrity with no confidentiality offset"
The updated value string now shows that integrity and
integrity+confidentiality are supported.
Update README.stats_tree including the sample implementation for
changes in the API, such as the enum return value and needing to
set the node datatype as either int or float.
Also update the comments in the stats_tree header to make it clear
that abbrev and name refer to the abbreviation used in the tshark -z
option, and the name of the menu and window in the GUI for the stats
tree.
This reverts commit d635ff4933.
A charconst cannot be a value string, for that reason it is not
redundant with unparsed.
Maybe character constants should be parsed in the lexical scanner
instead.
Before:
Filter: ip.proto == '\g'
dftest: "'\g'" cannot be found among the possible values for ip.proto.
After:
Filter: ip.proto == '\g'
dftest: "'\g'" isn't a valid character constant.
For double quoted strings. This is consistent with single quote
character constants and the C standard. It also avoids common
mistakes where the superfluous backslash is silently suppressed.
Try to retrieve the per packet info data first, and create it if
it doesn't exist, rather than assuming it is there on the second
pass. Prevents segfaults in cases with strange TCP sequence issues
(that still show up as bugs in the TCP dissector.) Fix#17737.
A number of protocols have IDs that can be reused that are used as
lookup keys. In most cases the frame number should be used as well
to differentiate repeat appearances of an ID. For response/request
matching, it is frequently useful to find the most recent frame number
(greatest value less than or equal to the current one) that contained
an ID.
We can achieve that by using a multimap that stores values with a given
ID in a tree keyed with the frame number. This works better than using
a map or a tree alone:
1) A map isn't ordered, so doesn't allow for less than or equal comparison.
2) Using a tree requires an ordering on all the ID components, and then
having to test all the components other than the frame number separately
for equality after retrieval.
Currently the multimap does not support inserting items without specifying
the tree key (and having the multimap generate a key), because the total
capacity of trees (including deleted nodes) is not tracked. If other use
cases are needed, this could be added later along with more generic
multimap support.
Use a multimap in ANSI MAP, ANSI TCAP, and GSM SMS, all of which need to
match lookup IDs that can be reused. Fix#7653.
Change our developer.gnome.org/glib URLs to
developer-old.gnome.org/glib. The official documentation for GLib
appears to be at https://docs.gtk.org/glib/, but it has a different
layout than the gnome.org content (and is surprisingly resistant to
exploration IMHO). We can switch to developer-old.gnome.org using a
simple substitution and it still seems to be updated, so do that for
now.
The column parameter in PacketListRecord::columnString() must be
below cap_file->cinfo.num_cols to be valid. An issue with this check
may be triggered when switching profile.
João Valverde