Note that the -B argument is in units of MiB.
Put --update-interval in a "Capture display" section for TShark, as it
affects how the output is displayed (printed). Don't duplicate it for
Wireshark, and put it at the end of the list.
--only-protocols takes a list of protocol, not a single protocol; make
the Wireshark output match the TShark output.
In commit 1c0f9cd3aef81ce76360af4d094b450e34b1e251, inclusion of
packet-ipv6.h was added to several installed files, but the file
itself is not installed.
Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
For the main GUI application for a given application favor, the
lower-cased version of the application flavor name happens to be the
same as the name of the application as a command, but don't rely on
that.
Have programs set the program name, at the beginning of main(), with
g_set_prgname(). That lets other code call g_get_prgname() to get the
program name.
This lets us replace a bunch of xxx_cmdarg_err() and
xxx_cmdarg_err_cont() routines with common code, as they differ only in
the command name printed in error message, and the common routine can
use g_get_prgname().
This also means that ws_log_init() doesn't need to be passed the
program name; it can juse use g_get_prgname(). The same applies to
extcap_log_init(), which calls ws_log_init().
While we're at it, have a common routine for extcaps to use ws_logv() to
log warnings, replacing some other xxx_cmdarg_err() and
xxx_cmdarg_err_cont() routines.
Use g_get_prgname() in ws_getopt.c; this means that you don't run the
risk of a pathname, rather than a command name, show up in the error
message.
When determining how many bytes are transferred on UDP multicast
streams, use the UDP datagram length instead of the frame length
from the frame that sent the tap. The latter isn't correct when
there's IP fragmentation, because only the last fragment's frame
length gets counted without knowing all the frames that were used
to reassemble the current IP packet.
This method ignores overhead at layers before UDP; some users might
wish that at least the IP header if not the link layer frame header
also be accounted for. Counting the link layer frame header is more
difficult because of tunneling and encapsulations like DVB-S2 Baseband
Frames that can contain more than one IP packet. Consistently handling
the same multicast being captured with different link layers (e.g. a
Linux "cooked capture" over the "any" device vs a standard Ethernet
link layer) is also difficult.
Also switch total bytes for the entire stream to a 64 bit integer.
Fix#20253
The ftypes are divided into equivalence classes of compatible types.
Multiple fields can be registered to the same abbrevitation so long
as all the fields have the same type. The handling is inconsistent
and scattered, however.
README.dissector gives a list of the types and one set of classes.
proto.c has an implementation, used only when hf conflict check is
turned on when compiling.
ftypes.c has an implementation, used in Lua for registering ProtoFields.
The most consequential version is in the DFilter semantic check, which
determines whether a filter is considered valid at all based on which
fields can be compared. It also determines the type to use when
converting various literal tokens to fvalues. (Note that this does
not always work properly, both for arithmetic operation with multiple
operands, and for fields that multiple compatible types registered,
but where one type is more restrictive in what literals it accepts.)
None of these are quite the same.
Have proto.c's hf conflict check use the same function in ftypes.c
used by Lua registration. Add some types to that function so that
it splits the difference between README.dissector and the dfilter
semcheck version. (The differences are with the time types and
whether the OID group is part of the BYTES group.) Add some
comments to the implementations where they differ. Move FT_AX25
in the README to the STRING group, as already done in the dfilter
semcheck as part of commit 92d958ad45a500d8074c7ca9f393eb41619a5df7.
Actually free the large buffers when resetting the tap.
Only shallow copy addresses when looking up the temporary key.
When creating a permanent new stream entry, then do a full copy.
Free addresses when we're done with them. Use copy_address_wmem
for NULL scoped memory as well, just to remind of the need to free them.
FT_GUID is not a bytes type, and is not compatible with the FT_BYTES
family. This has been the case since 923855bb20845f55472dfe8e62b7b43660f2f63b
in order to support both big and little endian GUIDs.
This prevents:
[GLib CRITICAL] -- g_bytes_compare: assertion 'bytes2 != NULL' failed
(and always returning "equals") when comparing a member of the bytes
equivalence class on the left hand side to a FT_GUID on the right hand
side of a filter comparison (e.g. eth.addr == smb2.client_guid), and
when the FT_GUID is on the left side, doing a memcmp with type-punning
of the byte type to a e_guid_t.
Also, use guid_cmp from "epan/guid-utils.h" to compare the e_guid_t
structs element by element instead of using memcmp.
Remove the configuration namespace routines and macros in
filesystem.[ch] with an application flavor API defined and implemented
in application_flavor.[ch].
When parsing a CHOICE type with untagged choices that are themselves
CHOICEs (and implicit tagging instead of AUTOMATIC tagging), we
set the tag as a special value of -1 so that dissect_ber_choice()
will know to try various choices at the next level.
(This is an internal tag value not something encoded in the packet.
The tag as actually encoded is from the type ultimately chosen,
and should be unique once all the choice levels are traversed,
see ITU-T X.680 29.3 and the examples in 29.9.)
We add to the tree an item that represents which choice was taken;
rather than adding a single item that reflects the ultimate choice
we add items for each level of choice. Those items get value strings -
the value string values can either be directly from the tags used in
the CHOICE, or can be assigned incremently from 0 enumerating the
choices. We shouldn't use these special tag numbers of -1 in a value
string for the choice; we should always fall back to assigning values
for each choice enumerated from 0.
Most of the time our existing checks catch this either at least one
of the tags will be something other than a CHOICE, and thus will have a
different tag class, or AUTOMATIC tagging is used.) However, if all the
choices of a CHOICE are themselves a CHOICE and IMPLICIT tagging is used
the current checks don't catch it.
IPAddress from GPRSCDR is such a type. This change causes
iPBinaryAddress to have a value of 0 and iPTextRepresentedAddress to
have a value of 1, instead of both having a value of -1 (4294967295),
eliminating a large number of warnings of the form:
[Epan WARNING] epan/proto.c:9249 -- tmp_fld_check_assert(): Field 'iPAddress' (gprscdr.iPAddress) has a conflicting entry in its value_string: 4294967295 is at indices 0 (iPBinaryAddress) and 1 (iPTextRepresentedAddress)
when ENABLE_CHECK_FILTER is defined (as in the Clang + Code Checks job)
This allows unique filtering on gpsrcdr.iPAddress and other fields using
that ChoiceType, like gprscdr.ggsnAddress.
Use QCPAxisTickerSi to show SI-prefixed units on the TCP Stream
Graph axes, as appropriate for each graph. (Sequence numbers could
be no units or units of bytes; Bytes was used already so it's used
here.)
Fix#20197
Fix
../../../../../epan/dissectors/asn1/acp133/acp133.cnf:23: UserWarning: Too few parameters. At least 1 parameters are required
##.CLASS OBJECT-CLASS
../../../../../epan/dissectors/asn1/acp133/acp133.cnf:29: UserWarning: Too few parameters. At least 1 parameters are required
##.END
../../../../../epan/dissectors/asn1/acp133/acp133.cnf:31: UserWarning: Too few parameters. At least 1 parameters are required
##.CLASS ATTRIBUTE
../../../../../epan/dissectors/asn1/acp133/acp133.cnf:42: UserWarning: Too few parameters. At least 1 parameters are required
##.END
The Yahoo Messenger service has been defunct since August 2016
(according to Wikipedia), so it seems unnecessary to describe a Yahoo
Messenger protocol oddity in the FAQs.
Genus names are conventionally shown with an initial capital letter; I
guess this rule extends to mascot shark "species". :-)
Fix an incorrect reference which resulted from the movement of the
Ethereal naming discussion to the end of the document.
Remove a stray backtick.
Commit 2d34c48c changed the buffer argument to epan_dissect_run from a
"tvbuff_t *tvb" to a "const uint8_t *data". This broke fuzzshark's
functionality without breaking its build under clang (which suppresses
"-Werror"). The resulting fuzzshark binaries would run and use a lot
of CPU while providing zero coverage.
Adjust fuzzshark to suit the changed prototype. fuzzshark once again
achieves meaningful coverage.
The erf_interface_id_from_flags() macro has an operator precedence error such that the mask is shifted before the comparison.
This causes the returned interface_id value to be incorrect on most trace files.
Fix adds brackets for operation order.
MSVC, after optimizing a function parameter to being unused, will then
warn about it, and if warnings are errors, will error out. Mark a
parameter used in an assert that can be optimized out as maybe-unused.
Add support for converting to double to the integer, time, and IEEE
11073 floating point formats. Add a display filter function that
explicitly converts fields to these types, so that the result can
be used for further calculations and, e.g., put in a column.
Also add a float function
Fix#20219
(There might be value in having more implicit conversions, but that's
a bigger task.)
There's "the length field isn't a valid number" and there's "the length
field is a valid number but it's too large"; report them differently, so
it's obvious which one was encountered.
If parseFieldLength received a length of greater than 8 and parseFieldData was
not subsequently called, the memcpy at the end of cllog_read_common could read
beyond the end of the eight-byte buffer in logEntry.data on the stack. This
condition could arise if the column header in a malicious input file stipulated
that the Length field appeared _after_ the Data field, or perhaps if the Data
field was absent.
The result would most likely be just some garbage data from the stack appearing
in the packet contents, but there's a chance it might also cause a crash if
length is large enough to read beyond the top of stack.
Clean up a related magic number "8" and an unnecessary loop counter.
Ping #19937
Added a trivial CL2000 capture file format sample, as obtained from:
https://canlogger.csselectronics.com/clx000-docs/cl2000/log/index.html
The cllog parser is modified to recognize the "Logger type" name in
that sample capture, which differs slightly from that already known to
the parser ("CL2000" versus "CANLogger2000"). Corresponding changes
are made for the CL1000 capture file, also available on the above
website -- but not added here because it provides no additional
coverage beyond the "Logger type" value, and for CL3000 just for the
sake of consistency.
Add a python testcase to read the added file.
Additional testing with two further sample captures available from
https://canlogger.csselectronics.com/clx000-intro/log-file-tools/
revealed a defect which caused file parsing to terminate as soon as
any packet was shorter than 8 bytes; Fix it by accepting NUL to
terminate the packet (in addition to CR/LF).
It's possible to register multiple fields to the same abbreviation.
We don't actually enforce field compatibility, but even if we did,
FT_FRAMENUM is considered compatible with other integer fields.
So it's theoretically possible to register a integer field with a
value string to the same abbreviation as a FT_FRAMENUM with a non-NULL
strings - FT_FRAMENUM overloads that field to store ft_framenum_type,
and treating it as a value_string *will* crash. (I don't believe
we have any such fields currently.)
Add a couple other comments regarding treatment of value strings -
we shouldn't actually optimize tests against strings that represent
value strings in cases where multiple fields are registered to the
same abbreviation and don't share exactly the same value string.
(See #19111 for a specific example.)
Actually verify protocol field names for the Uat PT_TXTMOD_PROTO_FIELD
type, to keep from writing invalid entries to the field, and properly
show bad values.
The only current user of this is the I/O Graph UAT
