This allows the "needs to be reloaded" indication to be set in the close
process, as is the case for ERF; having a routine that returns the value
of that indication is not useful if it gets seet in the close process,
as the handle for the wtap_dumper is no longer valid after
wtap_dump_close() finishes.
We also get rid of wtap_dump_get_needs_reload(), as callers should get
that information via the added argument to wtap_dump_close().
Fixes#17989.
The type field in the IEC-60870-5-104 header is parsed wrongly. The type is
encoded in the headers third byte: I.e. a U-frame is encoded as xxxxxx11b, a
S-frame as xxxxxx01b and an I-frame as xxxxxxx0b. Yet the current parser reads
the information from the MSB.
The representation "~= has been superseded by "!==" with the same
meaning, making it superfluous and somewhat confusing. Deprecate
"~=" and recommend "!==" instead.
Added PQC key exchange algorithms and PQC signature algorithms
in "epan/dissectors/packet-tls-utils.c". Added PQC signature algorithms
in "epan/dissectors/packet-pkcs1.c".
OQS-OpenSSL_1_1_1-stable is a fork that integrates liboqs into OpenSSL 1.1.1,
which provides a simple prototype of quantum-safe cryptography in TLS 1.3.
liboqs is an open-source C library for quantum-safe cryptographic algorithms.
Both are part of the Open Quantum Safe (OQS) project.
For an expression starting with a colon (a literal) try to parse
the value with and without colon. This avoids excluding some
valid representations like the IPv6 address "::1".
Comparisons require a field-like value on one of the sides,
or both. Change this to require on the LHS or both. There is
realy no reason that I can see to allow the relation to commute,
and it allows removing a lot of unnecessary code and extra tests.
For unparsed values on the RHS of a comparison try
to parse them first as a literal and only then as
a protocol. This is more complicated in code but
should be a use case a lot more common and useful in
practice.
It removes some annoying special cases and applies this
rule consistently to any expression. Consistency is
important otherwise the special cases and exceptions
make the language confusing and difficult to learn.
For values on the LHS the rule remains to first try a
protocol value, then a literal.
Related with issue #17731.
A literal value is a value that cannot be interpreted as a
registered protocol. An unparsed value can be a literal or
an identifier (protocol/field) according to context and the
current disambiguation rules.
Strictly literal here is to be understood to mean "numeric
literal, including numeric arrays, but not strings or character
constants".
The syntax for protocols and some literals like numbers
and bytes/addresses can be ambiguous. Some protocols can
be parsed as a literal, for example the protocol "fc"
(Fibre Channel) can be parsed as 0xFC.
If a numeric protocol is registered that will also take
precedence over any literal, according to the current
rules, thereby breaking numerical comparisons to that
number. The same for an hypothetical protocol named "true",
etc.
To allow the user to disambiguate this meaning introduce
new syntax.
Any value prefixed with ':' or enclosed in <,> will be treated
as a literal value only. The value :fc or <fc> will always
mean 0xFC, under any context. Never a protocol whose filter
name is "fc".
Likewise any value prefixed with a dot will always be parsed
as an identifier (protocol or protocol field) in the language.
Never any literal value parsed from the token "fc".
This allows the user to be explicit about the meaning,
and between the two explicit methods plus the ambiguous one
it doesn't completely break any one meaning.
The difference can be seen in the following two programs:
Filter: frame == fc
Constants:
Instructions:
00000 READ_TREE frame -> reg#0
00001 IF-FALSE-GOTO 5
00002 READ_TREE fc -> reg#1
00003 IF-FALSE-GOTO 5
00004 ANY_EQ reg#0 == reg#1
00005 RETURN
--------
Filter: frame == :fc
Constants:
00000 PUT_FVALUE fc <FT_PROTOCOL> -> reg#1
Instructions:
00000 READ_TREE frame -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_EQ reg#0 == reg#1
00003 RETURN
The filter "frame == fc" is the same as "filter == .fc",
according to the current heuristic, except the first form
will try to parse it as a literal if the name does not
correspond to any registered protocol.
By treating a leading dot as a name in the language we
necessarily disallow writing floats with a leading dot. We
will also disallow writing with an ending dot when using
unparsed values. This is a backward incompatibility but has
the happy side effect of making the expression {1...2}
unambiguous.
This could either mean "1 .. .2" or "1. .. 2". If we require
a leading and ending digit then the meaning is clear:
1.0..0.2 -> 1.0 .. 0.2
Fixes#17731.
Behave like other protcols that call tcp_dissect_pdus and don't set
COL_PROTOCOL or add a proto item before the call to tcp_dissect_pdus.
This avoids adding an empty tree in cases where there isn't enough
of the PDU to actually dissect anything. This makes the protocol
tree the same in the first pass (and thus tshark output), as in later
passes where the HTTP2 dissector won't get called.
Adds check for frame_data::has_ts in col_set_delta_time before calling
set_time_seconds. This is the same check that is done in multiple other
methods in column-utils.c. Because frame_data::tsprec might not be
initialized if has_ts is false, this resulted in a failed assertion in
set_time_seconds if the user created a column with "Delta time".
Also adds an assertion for frame_data::has_ts in set_time_seconds.
Add items for major type, additional information and lengths.
Create an entry for each element which contains the header details.
Change error handling from returning a proto_item to return a boolean.
Change naming to Indefinite length instead of Undefined length.
Dissect "break" using dissect_cbor_float_simple_data().
Add supports for exporting objects transferred
over FTP. The max size for files to be
exported can be configured via preferences,
and is unlimited (0) by default.
The server may push the following messages to the client:
ClustermapChangeNotification - If the client asked for it via
a hello flag the server will push out notifications to the
client when the topology changed
There are also a few "internal" messages which are used
between various components on the server:
Authenticate - Try to authenticate the externally defined user
ActiveExternalUsers - Push the list of active externally
defined users.
GetAuthorization - Request the authorization profile for the
given user.
* link multiple transfers to commands
* link multiple transfers to transfer requests
* link multiple transfers to each other (prev and next)
* track offset of each transfer
* display offset of each transfer.