Filter: max(1,_ws.ftypes.int8) == 1
** (dftest:64938) 01:43:25.950180 [DFilter ERROR] epan/dfilter/sttype-field.c:117 -- sttype_field_ftenum(): Magic num is 0x5cf30031, but should be 0xfc2002cf
Similar to commit dbb9fe2a37, proto_item_fill_display_label
now uses address_to_display for FT_IPv4, FT_IPv6, and FT_FCWWN,
the other three address types that double as field types and which
have optional name resolution.
Add these to the list of types that, if present in a custom column,
has the GUI enable the checkbox to switch between "resolved" (names)
and not (values).
This allows adding custom columns with these field types with both
resolved and non resolved text. Note that the appropriate Name
Resolution preference settings must be enabled for the type as well.
Comparison relations should be allowed to commute but they can not
because we need type information to resolve literals to fvalues. For
that reason an expression like "1 == some.field" is invalid. Solve
that by commuting the relation if the first try did not succeed in
assigning a type to the LHS.
After the second try give up, that means we have a relation with
constants on both sides and that is not semantically valid.
Other relations like "matches" and "contains" are not symmetric and
should not commute anyway.
Before:
Filter: _ws.ftypes.int32 == 10
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.int32 <FT_INT32>)
1 FVALUE(10 <FT_INT32>)
Instructions:
00000 READ_TREE _ws.ftypes.int32 <FT_INT32> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == 10 <FT_INT32>
00003 RETURN
Filter: 10 == _ws.ftypes.int32
dftest: Left side of "==" expression must be a field or function, not 10.
10 == _ws.ftypes.int32
^~
After:
Filter: _ws.ftypes.int32 == 10
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.int32 <FT_INT32>)
1 FVALUE(10 <FT_INT32>)
Instructions:
00000 READ_TREE _ws.ftypes.int32 <FT_INT32> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == 10 <FT_INT32>
00003 RETURN
Filter: 10 == _ws.ftypes.int32
Syntax tree:
0 TEST_ANY_EQ:
1 FVALUE(10 <FT_INT32>)
1 FIELD(_ws.ftypes.int32 <FT_INT32>)
Instructions:
00000 READ_TREE _ws.ftypes.int32 <FT_INT32> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ 10 <FT_INT32> == reg#0
00003 RETURN
Add all the valid bytes at once when we get to the end of the
length (or hit an invalid sequence) instead of one byte or character
at a time. This makes for a considerable speedup.
When the new-value element of the change-of-discrete choice contains context
tag zero, the tag content should be decoded as a BACnetDateTime. Closes#18747.
Use a consistent style for grammar rules.
Remove a comment that is too generic. The current code should
conform to how Python operates and does not need additional error
checking.
That reduces the number of get_progfile_dir() calls, leaving only the
calls that are done either to 1) get the pathname in order to display it
or 2) get the pathname in order to reset the library path.
That makes it easier to figure out which get_progfile_dir() calls are
made to find the directory in which (non-extcap) binaries from Wireshark
are installed and which - if any - are made to figure out the directory
in which *the currently-running executable* are stored. (Currently,
get_progfile_dir() attemps to get the former, not the latter, so
extcaps in an extcap subdirectory, for example, will get the parent
directory of that subdirectory, *not* the directory in which they weere
installed.)
Display it as a pathname in the native format (e.g., C:\this\is\wrong),
not as the path component of the URL supplied (e.g., /C/this/is/wrong).
Fixes some confusion that appeared in a comment in #15592 (but not the
underlying bug - fixing that bug should prevent that dialog from popping
up in the first place).
If our program file directory has a trailing "/extcap" or "\extcap",
trim it off. This should let extcaps determine the proper data file and
plugin directories. Fixes#15592.
Different QUIC connections can be multiplexed on the same network
5-tuple. Handle this, including checking for Stateless Reset tokens
on all connections on the same 5-tuple.
Create a CONVERSATION_QUIC type using our internal QUIC connection
ID, and set the conversation elements so that subdissectors like
TLS that set conversation data only alter data for the one QUIC
connection instead of all multiplexed connections.
Various failures are expected, per RFC 9000, if zero-length connection
IDs are used when multiplexing connections on the same local IP addresses
and ports.
Fix#17099
When building using msvc implicit changes of the integer sizes in
fmt_dect_nwk_ipei are treated as error due to possible loss of
information.
This is now forecome by explicitely masking the shifted value to fit in
guint16 and by typecasting in calculation to guint16 (the maximum value
that needs to fit here is sum(x=1..x=12)(9x)=702 )
João Valverde