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>
After Link deletion (by request), there is no node mapping anymore, but
we need to report the CLA link being down anyway. Thus, we check if
there is a node reference in the link structure and, if not, which also
means that `fib_foareach` did not call `send_fib_to_agent` at least
once, we explicitly send the DOWN notice to the connected agents.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Otherwise, the BP will push the whole FIB again to all subscribers even
if just a tool like aap2-configure-link connects to make a single
change.
Closes: #271
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
As with `FIB_REQUEST_CREATE_LINK`, on `FIB_REQUEST_DROP_LINK` we want to
inform agents in case there is no change or the CLA applied the change
instantly.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This cleans up the bundle delivery procedures:
- `bundle_deliver_adu` and the reassembly functions return a new result
type, specifying the action to be taken on the bundle (effectively,
this determines the kind of report to be generated).
- Fragments are now reassembled as specified in RFC 9171, by replacing
the payload of one fragment with the reassembled ADU payload. This
way, we can return the reassembled bundle as a full bundle structure
and perform proper reporting on it.
- The order of actions in `bundle_deliver_local` is corrected to match
the specification.
- The second set of `bundle_deliver_local_*` and `bundle_dispatch_*`
functions without fragmentation support is removed: these were only
provided for internal use in sending status reports so this function
can still take a `const struct bp_context *`. We now just document
that the parameter will not be accessed and, thus, can cast away the
`const` for the invocation.
Closes: #270
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This may happen for status reports addressed to the administrative
endpoint. Before we would just call `strcmp`, leading to a segfault.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This should generally only happen on internal errors / invalid bundles,
but we can handle this case easily.
Signed-off-by: Felix Walter <felix.walter@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>
The handling of the `is_custody_signal` flag was wrong: it had to be
`true` to encode the status report reason (and we also passed `true`
when generating status reports, but this set the AR type code to
"custody signal"). As we do not support custody anymore, we just always
generate status reports.
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>
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>
From RFC 9171, 4.2.4:
> For each bundle whose bundle processing control flags indicate that the bundle's
> ADU is an administrative record, or whose source node ID is the null endpoint ID
> as defined below, the value of the "Transmit status report if block can't be
> processed" flag in every canonical block of the bundle MUST be zero.
Fixes: #264
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>
Previously we were assuming that all but the payload block are "unknown
blocks", which is only true for BPv6.
Fixes: #268
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>
ipn EIDs with a FQNN of UINT32_MAX (0xFFFFFFFF) are LocalNode EIDs. This
adds special handling for them:
- represent the node number using an exclamation mark as recommended by
RFC9758
- support all valid representations (ipn:!.x, ipn:4294967295.x,
ipn:0.4294967295.x)
- dispatch bundles addressed to such EIDs (only) locally
- filter any incoming bundle containing LocalNode EIDs as source,
destination, or report-to EID
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This extends the BPv7 parser and serializer such that:
- the parser can decode both the 2- and 3-element EID formats
- the serializer produces the appropriate representation depending on
whether an allocator != 0 is present
Note that this means that incoming BPv7 bundles with a nonzero allocator
in an EID represented as a 2-tuple will have this EID converted to the
3-element format. It is assumed that this is the canonical form of the
bundle. In case we discoveer interoperability issues with this behavior,
we may decide to add a flag to the `ipn_eid` structure specifying which
representation should be used upon serialization of the bundle.
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>
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>
This provides a proper error log message (and AAP2 return value) in case
an invalid dest EID is provided by the client.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Previously, we only checked the agent ID, which meant that attempting to
register "ipn:1.1" on node "ipn:2.0" would succeed and in fact register
EID "ipn:2.1". As this is unexpected behavior and can hide bugs in
setups using µD3TN, we check for it and make it an (explicit) error.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This also allows sending anonymous ADUs. We might consider allowing this
for regular clients in the future.
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>
