This patch fixes some bugs that occur with padded Ethernet frames and
frames, when a Ethernet FCS is present. In the past that lead to wrong
detection of the ICV by the Ethernet dissector (trailer).
Such errors did occur for example with frames that were padded and
MACsec was added later; thus, being bigger than expected for the
heuristics in the packet-eth.c: "pinfo->fd->pkt_len >= 60 ..."
Format is defined by Wi-Fi EasyMesh™ Specification Version 4.0
* 5.2.2 Backhaul STA Configuration (Table 4. Multi-AP Default 802.1Q Setting
subelement format)
* 7.1 AP configuration (Table 15. Multi-AP Profile subelement)
We need to convert strings to valid UTF-8 for internal Wireshark
use. Since we aren't storing the code set service context as
conversation data (it's sent only when initially connecting, not
on a per-request basis), use the default of ISO-8859-1.
Also some automatic fixes of allocation patterns
Fix#18410
We amend the :<numeric> pattern to not eat the leading
colon. Because the colon can be part of the value (with IPv6 addresses
for example) we want to avoid doing that.
IPv6 addresses are covered by their own rules but this removes the
requirement in the future to handle any special cases and avoids
surprises.
For this reason the colon-prefix syntax is already explicitly defined to
work only for byte arrays and there is currently no universal
syntax for all literal values or even all numbers.
Other numbers can keep using the lexical type "unparsed".
```
run/dftest "_ws.ftypes.uint8 == :fd"
Filter: _ws.ftypes.uint8 == :fd
dftest: ":fd" is not a valid number.
_ws.ftypes.uint8 == :fd
^~~
run/dftest "_ws.ftypes.uint8 == fd"
Filter: _ws.ftypes.uint8 == fd
dftest: "fd" is not a valid number.
_ws.ftypes.uint8 == fd
^~
run/dftest "_ws.ftypes.uint8 == 0xfd"
Filter: _ws.ftypes.uint8 == 0xfd
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.uint8 <FT_UINT8>)
1 FVALUE(253 <FT_UINT8>)
Instructions:
00000 READ_TREE _ws.ftypes.uint8 <FT_UINT8> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == 253 <FT_UINT8>
00003 RETURN
run/dftest "_ws.ftypes.bytes == fd"
Filter: _ws.ftypes.bytes == fd
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.bytes <FT_BYTES>)
1 FVALUE(fd <FT_BYTES>)
Instructions:
00000 READ_TREE _ws.ftypes.bytes <FT_BYTES> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == fd <FT_BYTES>
00003 RETURN
run/dftest "_ws.ftypes.bytes == :fd"
Filter: _ws.ftypes.bytes == :fd
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.bytes <FT_BYTES>)
1 FVALUE(fd <FT_BYTES>)
Instructions:
00000 READ_TREE _ws.ftypes.bytes <FT_BYTES> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == fd <FT_BYTES>
00003 RETURN
```
The <...> syntax for literals, intended to be as generic as
possible, unintentionally introduced an ambiguity with the
relational expression "a < b or a > c".
Literals are values like numbers, bytes, IPv6 addresses or, one
could imagine, UNC paths for example, if an FT_UNC type were to
be added in the future.
We could use a new unique symbol like @...@ but the <...>
syntax is very recent and may not be necessary with ":xxx" so
just remove it.
A byte array can be explicitly declared by prefixing with a colon. It
is not as generic but the main ambiguity that this new syntax attempted
to solve is bytes vs protocol names. We don't want to introduce a new
reserved symbol for now, until other requirements if any are more clear.
Fixes#18418.
There are many screens with a display filter edit box but they should
not wallop the status line on the main window. Display syntax errors
on the local window in "hints" area.
Only update Status Line message when editing a display filter in the
Filter toolbar or Find Packet toolbar.
As of a change many years ago, Boolean values are stored as 64-bit (the
change was made to handle Boolean bitfields in 64-bit fields). Fix the
extractor for Boolean values to fetch from the 64-bit unsigned integer
field, and, while we're at it, add a change that the field in question
really *is* a Boolean field (the functions used to fetch the value in
the other extractors do such a check).
This change treats each data item value as a subset TVB which isolates its handling and allows using a dissection table to handle the type switching.
This also allows extending DLEP dissector outside of this dissector by, for example, a plugin.
The dialect name is technically an OEM string, in the local
OEM Extended ASCII DOS code page, but in practice there are
no known dialect names that use anything outside of ASCII.
We don't know what the local OEM code page is, anyway.
tvb_get_const_stringz does no translation into UTF-8, and should
only be used in rare instances.
Fix#18401.
Gerald Combs