Add command-line options for cppcheck to the CI job:
- `--suppress=constParameterCallback`
- `--check-level=exhaustive`
information: Limiting analysis of branches.
Use --check-level=exhaustive to analyze all branches.
- `--force`
information: Too many #ifdef configurations - cppcheck only checks 12
configurations. Use --force to check all configurations.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
In outgoing status reports, previously, we did not send timestamps, even
in case they were requested for BPv7 bundles. This refactors the
corresponding functions to generate status reports, so we assign the
proper timestamp depending on the status flag.
Note that we never supported sending a status report capturing multiple
events at once -- only the BPv7 SR serializer supports the generation.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Incoming status reports can contain multiple timestamps, depending on
which flags are set, as in BPv7. In outgoing bundles, we do not support
this, but we must support it when parsing received SRs.
The approach to parse the conditionally-present fields is to always fall
through all the `case` labels and only stop (+ parse) where we see the
corresponding flag. Otherwise we would need a big jump table for every
individual step (checking if any of the remaining flags is present). As
the `switch` construct already represents such an overall jump table, we
just leverage it (and tell the compiler that it is fine to fall through
there).
This also adds two functions to initialize AR and SR data structures, so
we do not miss initializing any fields (which we were, previously!) and
cause UB.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We never fully implemented custody and removed the corresponding
(prototypical) infrastructure long ago. We do not need to be able to
parse BPv6 custody signals.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This has been changed before standardization of RFC9171: "report custody
acceptance" is 0x008000 (bit 15) in BPv6, which is reserved in BPv7.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Note that at the moment we cannot easily terminate the CLA tasks. Thus,
we return UD3TN_FAIL if any task is running and do not free resources in
that case. This is not important for the uD3TN daemon as all runing CLAs
are only terminated on process termination and the resources are then
deallocated by the system anyway.
Fixes: #192
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
See: #267
This adds a compile-time flag to reject such bundles, if needed.
Making this part of the validation routines all the time breaks our
interoperability with DTN7 (at least in the configuration we are using
in our interop. test).
Note that we cannot currently check the security targets, which is an
unordered CBOR array part of the BIB payload data. Thus, bundles without
CRC and with a BIB targeting *any* block, even if this excludes the
primary block, will be accepted when the option is turned on. See
follow-up issue #273.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- The standard defines 64 bits for all flags.
- Also see https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.3-6:
"Bundle processing control flags that are unrecognized MUST be ignored,
as future definitions of additional flags might not be integrated
simultaneously into the Bundle Protocol implementations operating at
all nodes."
- Similar for blocks:
https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.4-2
- The primary block length is calculated internally based on the bundle
length -- to prevent overflow, we use 64 bit here as well. (We might
introduce additional checks in the future, but the input being CBOR
with the validations in the BPv7 parser should already work to
only allow a "sane" primary block length. For BPv6 we enforce still
parsing only 16 bits for it.)
- Also define a bit mask for BPv6 flags (`BP_V6_FLAGS`)
Closes: #247, #237
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
ION uses a 32-bit unsigned integer length field as header for the MTCP
packets. To be compatible with that, we add a compile-time setting
`CLA_MTCP_ION_STCP_COMPATIBILITY`.
Closes: #202
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This extends the conversion and validation functions for ipn EID strings
to implement support for the RFC9758 3-element format.
The only point that changes behavioral-wise by default is that now
`eid_to_string` returns the "ipn:a.n.s" for all EIDs with FQNN > 2^32-1,
except if the new compile-time configuration option
`EID_IPN_FORCE_2_ELEMENT` is enabled.
This also introduces a variant of `eid_to_string` with a second argument
to enforce the use of the 2-element format, which is used in the BPv6
implementation for constructing outgoing bundles (there is no 3-element
format in BPv6).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This avoids confusion with the new "node number", as RFC9758 also calls
the lower 32 bits (assigned by the allocator).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Type punning via unions in C is not portable as the order of the inner
struct members depends on the endianness of the platform.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds an anonymous union for decomposing the node number into an
allocater ID plus an assigned node number as per RFC9758.
NOTE that this is partially reverted in the following commit and is kept
for reference that we considered and abandoned the union approach.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Some older functions have not been renamed previously to simplify the
review of the "struct eid" change. This adapts the remaining EID-string
handling functions to have consistent naming and return types with the
other EID-related functions and make them more intuitive to use.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We handle these EIDs gracefully: we consider them as the null endpoint
and set the service number to zero when reading them from a string.
When parsing and serializing BPv7 bundles, the EIDs are kept unchanged.
In the case of BPv6 bundles, they will be normalized when the dict is
rewritten on serialization (this is done anyway).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- A new `struct eid` is introduced, which can represent EIDs in a
scheme-based manner; specifically, this means that `ipn` EIDs are
now represented as tuples of two 64-bit integers and the `dtn` null
endpoint is now represented as a `NULL` pointer (similar to the CBOR
representation in RFC 9171).
- We assume that any `struct eid` instance has been validated before,
e.g. by decoding a string via `eid_from_string`.
- Note that the FIB is still using the (normalized) string format of
node IDs. It performs a lookup in a hash table anyway and, later, we
plan to support EID patterns (current IETF draft).
- Changes to parsers and serializers:
- The BPv7 parser validates EIDs separately from `eid_from_string`.
This is intentional: No full normalizationis performed for incoming
bundles; as long as the EID is valid, it is passed through, to
prevent changes to the immutable (as per RFC9171) primary block.
This means that, e.g., there are two representations of the null
endpoint (`dtn:none` and `ipn:0.0`), which are kept as such now.
- The BPv6 parser and serializer will rewrite the primary block of
passing bundles -- they do this anyway as the "dictionary" is
re-constructed by the serializer.
- Dedicated string representations of the EIDs (`source_str`, etc.)
are added to the bundle struct on reception (`cla_contact_tx_task`)
and creation -- this is done for convenience when processing the
bundle further (especially to still be able to print log messages
referring to the EIDs in the BP and so on). We may remove it in the
future to reduce the number of EID-to-string conversions.
- Other changes:
- Some terminology is cleaned up in the process: e.g., variables
referring to the local administrative endpoint identifier are
renamed as such. The previously-used terms "local node ID" or,
worse, "local EID" are inaccurate -- according to the standards,
any locally registered singleton EID is a node ID of the local
bundle node.
- In some places, log messages are harmonized (e.g. by always using
quotes around EIDs and no quotes for agent sink IDs). Sometimes,
EIDs were printed in logs which have been removed now to prevent
an unnecessary EID-to-string conversion.
- `aap2_agent`: the manual deallocation of string parts of the AAP2
message is now replaced by a less fragile `pb_release` in most
cases.
- `bundle.h`: `struct endpoint_list` is replaced in BPv6 by a
`struct eid_list` containing the new `struct eid`; the DFCF
("compat") router still uses the old variant with strings
- `init`: `preprocess_local_eid` is simplified and moved to
`cmdline.c`. It now uses `eid_from_string`, which tolerates missing
trailing slashes for `dtn`. Also, we do not support `ipn:x` without
service number anymore on the command line, as it is an invalid
format and only makes the coe more complex.
It is recommended to review the changes to `ud3tn/eid.[c|h]` and the
associated unit tests (`test_eid.c`) first, to get an overall idea of
the added and adapted functionality plus the expected behaviors. Before
reviewing the individual changes to all functions dealing with EIDs, it
is also advisable to take a quick look at the other associated
(following) commits.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This function duplicated functionality from bundle7_eid_sizeof (and
improperly represented the IPN Null Endpoint) + was untested. Thus, we
remove it and replace uses with bundle7_eid_sizeof().
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Newer versions check that enums indeed declare every value that is
assigned to variables with the given type.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This removes the Unified-API-specific code from the AAP2 client. As
dicussed in !238, it fits better in the upstream repo.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
AAP2 uses uint32, so we do, too. This moves the check for a negative
value to the UAPI backend implementation.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This implements an AAP 2 C client based on the Unified API code for the
µD3TN AAP 2 interface. The implementation consists of two parts; a
generic AAP 2 client (aap2_client.c) and a Unified API compatibility
layer (aap2_unified_api_backend.c). The core difference between the two
is that the Unified API compatibility layer automatically creates two
sockets (a sending and a receiving one) and generates a common AAP 2
secret shared between the two. Moreover, the generic client offers some
additional AAP 2 options that are not available in Unified API. Thus,
the generic client features slightly higher flexibility and is intended
as the default solution when developing applications that only need to
interact with µD3TN.
The following design considerations for the generic AAP 2 client are
noteworthy:
- The client struct is an opaque object that is fully managed inside the
generic AAP 2 client implementation. This way, we have full
flexibility for adaptations in the future.
- Inspired by the Unibo code, the `aap2_client_register` and send/recv
functions use dedicated spec structs, which are more extensible than
using individual function arguments (fields can be added flexibly).
- Support for timeout and keepalive is added where applicable to enable
recognition of broken TCP connections and keep firewalls happy.
- Log messages typically use the "debug" level, except if they indicate
a broken connection ("warn") or a danger to overall continued program
execution ("error").
The generic AAP 2 client contains some minor bits from the original
Unified API client code:
- The `receive_payload` was mostly moved to the generic part, only
adding special handling for (valid) zero-length payloads.
The Unified API compatibility layer was implemented based on the
original Unified API code, adapting it to make use of the generic AAP 2
client implementation.
The following changes to the coding style were performed to adapt it to
µD3TNs style guidelines (Linux kernel coding style):
- use tabs according to the Linux kernel style guide
(`ERROR:CODE_INDENT`, `WARNING:SPACE_BEFORE_TAB`, `WARNING:LEADING_SPACE`)
- add some spaces after declarations (`WARNING:LINE_SPACING`)
- do not assign inside if statements (`ERROR:ASSIGN_IN_IF`)
- use parentheses for `sizeof` everywhere (`WARNING:SIZEOF_PARENTHESIS`)
- adapt indent (`ERROR:SWITCH_CASE_INDENT_LEVEL`)
- remove trailing whitespace (`ERROR:TRAILING_WHITESPACE`)
- adapt function declarations
- adapt block comment style (`WARNING:BLOCK_COMMENT_STYLE`)
- use `__func__` instead of `__FUNCTION__` (`WARNING:USE_FUNC`)
- remove unnecessary braces (`WARNING:BRACES`)
- put opening brace after declarations of e.g. `enum`
(`ERROR:OPEN_BRACE`)
- make pointer `*` location consistent (`ERROR:POINTER_LOCATION`)
- use memcpy and snprintf instead of string functions such as str(n)cpy
The following additional changes to the original Unified API code were
performed:
- removal of legacy and deprecated code (commented check in
`ud3tn_free_payload`, function `ud3tn_ping_aap`)
- removal of status report features/stubs: the actual integration was
not implemented; we can add it back in the future when support for
decoding status reports in the generic portion is implemented
- re-implement ping feature based on AAP 2 keepalive mechanism: the
generic client features a keepalive method, which we can use in the
Undified API compatibility layer
- adaptation of all `DEBUG_*` log statements to the corresponding µD3TN
`LOG[F]_*` macros
This means that functions that will be reused in the AAP2 client are
moved to a common `aap2_util` file. Slight adaptations to the naming of
individual functions are made as they are not `static` anymore. This
also adds handling for the status report ADU flag in
`aap2_get_adu_flags`, which was missing beforehand.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This enables AAP 2.0 clients to receive status reports with a new ADU
flag (as we already deliver BIBE bundles). Moreover, it allows clients
to set a report-to EID and sets all of the status report flags on newly
created bundles in case a report-to EID is provided.
Closes: #241
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a function to decode JSON configuration via Jansson to the
router agent. The JSON functionality and, thus, the dependency on
Jansson, can be disabled during the build process by setting the
`DISABLE_JSON` compile-time flag (see `config.mk.example` for details).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Previously it was not possible to disable SQLite because of a linker
error. Also, `sqlite3.h` was always required to be present. This adds
an example to `config.mk.example` and fixes both issues.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
It only controls how status reports should look like, not which status
reports are requested. We only want to check for the latter. ION appears
to always set this flag.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a `bundle_is_valid` function checking for further MUST
constraints defined by the spec., which further processing inside uD3TN
may depend on.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The defaults for the AAP and AAP 2.0 TCP ports were the same. Thus, if
we specify a TCP host for both, µD3TN will terminate on startup as the
port is already in use by one agent but it tries to bind to it with
both.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Previously the conversion to `enum bundle_block_type` could result in an
unsigned integer overflow, triggering the assertion in rare cases.
This change 1. adapts the assertion such that the check is performed
using the correct data type and 2. introduces a range check for the
bundle block type (only type codes 0-255 are defined).
Closes: #227
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This allows for using AAP 2.0 over TCP, which the Python tools support
already. Note that the user must make sure that the socket is not
exposed externally.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This was confusing users. We are adding a detailed explanation in the
man page and informing in the help text that the parameter refers to the
administrative endpoint of uD3TN.
Fixes: #213
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
