Create a Wireshark.dSYM bundle for our debugging symbols. Create a
separate .dmg for the dSYM bundle, similar to what we do for Windows.
`dwarfdump --uuid run/Wireshark.dSYM` returns what app
This reduces the size of the application bundle and .dmg quite a bit
(sizes measured with `du -sm`):
51 Wireshark 3.7.0 Intel 64.dmg
81 Wireshark dSYM 3.7.0 Intel 64.dmg
182 Wireshark.app
262 Wireshark.dSYM
For an expression starting with a colon (a literal) try to parse
the value with and without colon. This avoids excluding some
valid representations like the IPv6 address "::1".
Comparisons require a field-like value on one of the sides,
or both. Change this to require on the LHS or both. There is
realy no reason that I can see to allow the relation to commute,
and it allows removing a lot of unnecessary code and extra tests.
For unparsed values on the RHS of a comparison try
to parse them first as a literal and only then as
a protocol. This is more complicated in code but
should be a use case a lot more common and useful in
practice.
It removes some annoying special cases and applies this
rule consistently to any expression. Consistency is
important otherwise the special cases and exceptions
make the language confusing and difficult to learn.
For values on the LHS the rule remains to first try a
protocol value, then a literal.
Related with issue #17731.
A literal value is a value that cannot be interpreted as a
registered protocol. An unparsed value can be a literal or
an identifier (protocol/field) according to context and the
current disambiguation rules.
Strictly literal here is to be understood to mean "numeric
literal, including numeric arrays, but not strings or character
constants".
The syntax for protocols and some literals like numbers
and bytes/addresses can be ambiguous. Some protocols can
be parsed as a literal, for example the protocol "fc"
(Fibre Channel) can be parsed as 0xFC.
If a numeric protocol is registered that will also take
precedence over any literal, according to the current
rules, thereby breaking numerical comparisons to that
number. The same for an hypothetical protocol named "true",
etc.
To allow the user to disambiguate this meaning introduce
new syntax.
Any value prefixed with ':' or enclosed in <,> will be treated
as a literal value only. The value :fc or <fc> will always
mean 0xFC, under any context. Never a protocol whose filter
name is "fc".
Likewise any value prefixed with a dot will always be parsed
as an identifier (protocol or protocol field) in the language.
Never any literal value parsed from the token "fc".
This allows the user to be explicit about the meaning,
and between the two explicit methods plus the ambiguous one
it doesn't completely break any one meaning.
The difference can be seen in the following two programs:
Filter: frame == fc
Constants:
Instructions:
00000 READ_TREE frame -> reg#0
00001 IF-FALSE-GOTO 5
00002 READ_TREE fc -> reg#1
00003 IF-FALSE-GOTO 5
00004 ANY_EQ reg#0 == reg#1
00005 RETURN
--------
Filter: frame == :fc
Constants:
00000 PUT_FVALUE fc <FT_PROTOCOL> -> reg#1
Instructions:
00000 READ_TREE frame -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_EQ reg#0 == reg#1
00003 RETURN
The filter "frame == fc" is the same as "filter == .fc",
according to the current heuristic, except the first form
will try to parse it as a literal if the name does not
correspond to any registered protocol.
By treating a leading dot as a name in the language we
necessarily disallow writing floats with a leading dot. We
will also disallow writing with an ending dot when using
unparsed values. This is a backward incompatibility but has
the happy side effect of making the expression {1...2}
unambiguous.
This could either mean "1 .. .2" or "1. .. 2". If we require
a leading and ending digit then the meaning is clear:
1.0..0.2 -> 1.0 .. 0.2
Fixes#17731.
Extract the FCS length information from that field, and reject captures
that have a non-zero "class" field (the 10-bit reserved field that was
once intended to allow other "classes" of link layer type, with class 0
being "LINKTYPE_ values", but the original use case doesn't appear ever
to have been used).
Behave like other protcols that call tcp_dissect_pdus and don't set
COL_PROTOCOL or add a proto item before the call to tcp_dissect_pdus.
This avoids adding an empty tree in cases where there isn't enough
of the PDU to actually dissect anything. This makes the protocol
tree the same in the first pass (and thus tshark output), as in later
passes where the HTTP2 dissector won't get called.
Adds check for frame_data::has_ts in col_set_delta_time before calling
set_time_seconds. This is the same check that is done in multiple other
methods in column-utils.c. Because frame_data::tsprec might not be
initialized if has_ts is false, this resulted in a failed assertion in
set_time_seconds if the user created a column with "Delta time".
Also adds an assertion for frame_data::has_ts in set_time_seconds.
Add items for major type, additional information and lengths.
Create an entry for each element which contains the header details.
Change error handling from returning a proto_item to return a boolean.
Change naming to Indefinite length instead of Undefined length.
Dissect "break" using dissect_cbor_float_simple_data().
Add supports for exporting objects transferred
over FTP. The max size for files to be
exported can be configured via preferences,
and is unlimited (0) by default.
The server may push the following messages to the client:
ClustermapChangeNotification - If the client asked for it via
a hello flag the server will push out notifications to the
client when the topology changed
There are also a few "internal" messages which are used
between various components on the server:
Authenticate - Try to authenticate the externally defined user
ActiveExternalUsers - Push the list of active externally
defined users.
GetAuthorization - Request the authorization profile for the
given user.
* link multiple transfers to commands
* link multiple transfers to transfer requests
* link multiple transfers to each other (prev and next)
* track offset of each transfer
* display offset of each transfer.
Dissection of payload is enabled by default. If it is disabled the user gets a
hint.
Corrected some typos.
Intention: It is very confusing for non expert users of wireshark when some
major protocol features are disabled by default.
When desegmenting TCP, we only want to call subdissectors when processing
the last segment. With encapsulation, TCP might appear at more than one
layer in the frame, so check that the layer number of the last segment
matches the current layer number too, just like in
process_reassembled_data()
When there is more than one TSP in a frame, the fragment at the
end of one TSP and the first fragment in the next have the same
layer number as well as frame number. So use other information
about whether we have the last fragment to avoid calling subdissectors
extra times (which can interfere with retrieving the packet analysis
proto data on the subsequent passes.)
Just have a single switch for all packetlogger packet types, with a
routine doing the common code for all packets treated as Bluetooth H1
interface packets.
This means that unknown types are never handed off to the Bluetooth H1
interface dissector; it is probably best not to hand it to that
dissector, as the packet might not be a Bluetooth H1 interface packet.
This also fixes the setting of bthci.sent, which is a gboolean that
should be TRUE for sent packets and FALSE for received packets, which
means it should *NOT* be set to P2P_DIR_SENT for sent packets and
P2P_DIR_RECV for received packets - P2P_DIR_SENT is 0, meaning it looks
like FALSE, not TRUE. and P2P_DIR_RECV is 1, meaning it looks like TRUE,
not FALSE. (In practice, this doesn't appear to matter, as the only
places that look at bthci.sent look it it *before* the packetlogger
dissector is called, but it's better to do it correctly, in case
anything else *does* end up looking at that field after the packetlogger
dissector is called.)
Use a dissector table instead of manually managing an array of dissector
handles with a hardcoded size. This also prevents a buffer over-read
from unexpected payload format values (either in a later version of
the protocol or just malformed data.)
Sake Blok