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.
For most file types, blocks for which we don't have a wtap_block_type_t
aren't "custom", they're just "file-type specific". Add
WTAP_BLOCK_FT_SPECIFIC_REPORT and WTAP_BLOCK_FT_SPECIFIC_EVENT block
types; the "mandatory" part of those blocks includes a
file-type-specific block type value, with specific values assigned to
specific block types (either as part of the file type's definition, or
by us if necessary).
For pcapng files, blocks for which we don't have a wtap_block_type_t are
either "local" (block type has the high-order bit set), are defined in
the current spec but aren't supported yet (which we should fix), or are
*not* defined in the current spec and are *not* "local" (in which case
whoever's using the block number should submit a pull request to the
spec to register the block type *and* give it a specification, so we can
add support). For "local" block types and for not-yet-supported
non-"local" block types, they should be handled as file-type-specific
blocks with the file-type-specific block value being the pcapng block
type code, with plugin support in the pcapng code to read *and* write
those blocks.
Move the structures for the "mandatory" parts of blocks to
wiretap/wtap_opttypes.h, right after the definition of
wtap_block_type_t.
The init functions of the gsm statistics tables call gsm_a_stat_init, which
allocates some strings. We have to register gsm_a_stat_free_table_item to
free these table items again.
This is already done correctly for gsm_a_bssmap_stat_table. Fix it for the
other tables.
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
If so, we can safely assume that its rows have already beend initialized.
All we have to do is clear the data that was collected by the tap.
When registering a custom block type, set the block type field of the
wtap_blocktype_t structure. (We may do custom blocks differently, so
this is just for now.)
When registering a standard block type, don't pass in the block type, as
we can just use the type in the wtap_blocktype_t structure.
Guy Harris