Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
Recommend the use of wtap_name_to_file_type_subtype() to get filetype
values, unless you need to run on older versions of Wireshark that don't
have it.
Don't even *mention* wtap_filetypes in the documentation for the new
wtap_ routines, as, if you have those routines, you have
wtap_name_to_file_type_subtype(), because it's one of those routines.
Fix references to "nul" while we're at it - it's "nil" in Lua.
(That part of the WSDG - the Lua reference - is generated, so this
involves changing the source code implementing the Lua routines.)
In 2018 Modbus Organization published a document named
"Modbus/TCP Security"[1] that specifies the use of Modbus/TCP over TLS.
This commit register a new dissector, "mbtls", reusing "mbtcp" proto. A
new option is added to define the Modbus/TLS port to be use in
`classify_mbtcp_packet`.
[1] https://modbus.org/docs/MB-TCP-Security-v21_2018-07-24.pdf
Whenever we receive a BSSGP message indicating an error, set
in_error_pkt accordingly. This will prevent higher layer dissectors
from clearing COL_INFO.
Like many transport protocols, NS has the ability to include
the "erroneous message" when reporting errors to its peer in
NS-STATUS PDUs.
The current UX however is super annoying: The BSSGP dissector
clears COL_INFO and hence if you look at the packet list in wireshark,
it looks like a valid higher-layer message is transmitted over NS,
and there is no mention that this is an error (NS-STATUS).
By simply setting in_error_pkt, the behavior changes: The erroneous
message is still dissected in the protocol details, but COL_INFO
remains what the NS decoder has to say: NS-STATUS with a decoded
cause information.
The "short name" is really just the name, used to look it up. The
"name" is really a description intended solely for human consumption.
Rename the fields, and the functions that access them, to match.
The "description" maintained by Lua for file type handlers is used
*only* for one debugging message; we should probably just eliminate it.
Call it an "internal description" for now.
Provide Lua version of wtap_file_type_subtype_string(),
wtap_file_type_subtype_short_string(), and
wtap_short_string_to_file_type_subtype().
This will be backported to the 3.2 and 3.4 branches, to allow scripts
not run on the bleeding-edge version to use them.
List the minimum set of tools required.
We have scripts to do the setup work on a number of platforms. Let the
user know about them.
Give instructions on using CMake; we're not using the traditional
autoconf stuff any more.
Give instructions on building the Developer's and User's Guides in the
UNIX section, and, in both that section *and* the equivalent Windows
section, give the name of the build target for building all guides.
Details:
* At this point works for single RDMA transfer per command
* Commands are linked to RDMA requests
* RDMA requests are linked to commands (read and only first write)
* RDMA read requests are linked to read responses (only first response)
* RDMA read responses are linked to requests (only first response)
* RDMA read responses are linked to commands (only first response)
This reverts commit 05d5506324.
Due to a wrong order of merge requests, and squashing the history,
I would like to split the commit into two independent changes.
packet-wccp.c:2423:11: warning: Although the value stored to 'length_remaining' is used in the enclosing expression, the value is never actually read from 'length_remaining'
packet-ieee80211.c:23771:5: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-ieee80211.c:23905:9: warning: Value stored to 'offset' is never read [deadcode.DeadStores
packet-ieee80211.c:23994:9: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-ieee80211.c:24083:9: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-ieee80211.c:24146:9: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-ieee80211.c:26495:7: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
Details:
* At this point works for single RDMA transfer per command
* Commands are linked to RDMA requests
* RDMA requests are linked to commands (read and only first write)
* RDMA read requests are linked to read responses (only first response)
* RDMA read responses are linked to requests (only first response)
* RDMA read responses are linked to commands (only first response)
When you load a correct wireshark config for SOME/IP responding
hashtable entries are created. If you load afterwards a new config
(empty or not) the old entries are updated.
However, Wireshark does not call the uat's post update callback,
when there was a bug in the config. This leads to an inconsistent
state, which may result in a crash on dissecting SOME/IP messages.
This patch adds code to the SOME/IP dissector to avoid inconsistent
state.
Fixes: #17227
In our first pass through our options, look for ones that might require
extcap. Call extcap_register_preferences() only when that's the case.
Warn about missing extcap preferences only when we've loaded them.
Show values that are sequence numbers, counts, lengths, and the like in
decimal, with the hex value after it in parentheses for the benefit of
those who count to 16 rather than 10.
Show values that are sequence numbers, counts, lengths, and the like in
decimal, with the hex value after it in parentheses for the benefit of
those who count to 16 rather than 10.
Git Protocol version 2[1] defines 0x0001 as a delimiter packet that
separates the sections of a message, as well as 0x0002 as a response_end
packet that indicates the end of a response for stateless connections.
Add parsing and checking of the delim-pkt and response_end-pkt lines,
adding them as items to the tree for ease of reading and filtering while
handling pre-existing "malformed" errors. For additional consistency,
the terminator 0x0000 is now referred to as Flush packet.
[1] https://www.kernel.org/pub/software/scm/git/docs/technical/protocol-v2.html
Part of #17093
When the method name was not found it needs to be set to null. By
accident the service name was set to null instead.
This is wrong and fixed by this patch.
Fixes#17204
Add a new timestamp encoding format ENC_TIME_NSECS, like ENC_TIME_SEC but
for nanosecond values. Needed for my work-in-progress dissector for Apple
push notifications.
Guy Harris
Harald Welte