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>
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>
- 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>
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 `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>
If the write method of the CLA fails, the serailizers will now return
early and this failure is handled properly by the TX task.
In the case of the BPv6 serializer, we add the necessary flow control to
the `write_bytes` macro, to prevent needing a conditional for every
write* or serialize* statement.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Previously the fragmentation logic was very specific to uD3TN's
forwarding approach, modifying the original bundle in the process. With
BDMs supporting fragmentation we must make this more flexible. Thus, we
now pass an offset and length and always create a copy of the required
contents based on the original bundle.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This moves all definitions from config.h to individual header files and
makes them configurable (i.e., does not define when already defined).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The node and service number are 64 bit unsigned integers. This fixes the
validation and EID serialized size calculation and adds appropriate
tests to the serializer unit tests.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
ud3tn is available under multiple licenses and we want to reflect this in
our source code. But which license information should appear first and how
can we manage this efficiently in the future? The Linux Kernel uses SPDX
expressions instead of boilerplate sections. This seems to be a great
approach, so we do the same here.
Signed-off-by: Georg Alexander Murzik <georg.murzik@d3tn.com>
There was an issue in reports.c, that an error at specific points in
the code could lead to already malloc'ed fields not being freed properly.
This commit fixes this issue by introducing the function
free_record_fields() which frees all potentially malloc'ed fields in
the bundle_administrative_records struct before the struct itself
is freed.
Signed-off-by: Tobias Nöthlich <tobias.noethlich@d3tn.com>
Based on a contribution by @mnitsch, 351e1dae9.
This removes `hal_*` dependencies in the bundle processing components,
with the goal that these parts can be re-used without depending on the
uD3TN core functions and underlying system state. The required variables
are passed as function arguments from the uD3TN core components.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds the bundle sequence number as an argument to the bundle
creation functions and passes a sequence number which increases when
multiple bundles are generated by the application agent with the same
creation timestamp.
Fixes: #59
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The Bundle Age block [...] contains the number of milliseconds
that have elapsed between the time the bundle was created and time at
which it was most recently forwarded. It is intended for use by nodes
lacking access to an accurate clock, to aid in determining the time at
which a bundle's lifetime expires. [...] If the bundle's creation time
is zero, then the bundle MUST contain exactly one (1) occurrence of this
type of block.[1]
In this implementation the age block is only evaluated if the creation
timestamp is 0. If a bundle age block exists, it will be updated
according to the specification, but an age block will never be
proactively inserted.
[1]: https://tools.ietf.org/html/draft-ietf-dtn-bpbis-30#section-4.4.2
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
To be compatible with the latest version of BPv7, the internal
representation of DTN timestamps, for both uD3TN and the Python library,
is changed to milliseconds.
For compatibility reasons, a conversion to seconds is performed during
the de-/serialization of BPv6.
Furthermore, additional test cases are added and the creation_time_ms of
the test bundle is set to a non-trivial timestamp.
Also, the Python functions for converting POSIX timestamps to DTN
timestamps are removed, as there is now a distinction between BPv6 and
BPv7 DTN timestamps. The conversion is now done in the corresponding BP
implementations themselves.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
The re-name to "enum ud3tn_result" broke the indentation in some
function signatures, which is fixed by this commit.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This is the initial commit for uD3TN. uD3TN is a fork of uPCN v0.8.0,
which will be developed and maintained in a public Git repository.
For questions concerning the history of and code provided with uPCN,
please get in touch with us via: contact <at> d3tn <dot> com
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
