- 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>
This enforces a non-zero return code if any input file is longer than
expected and shows a validation error in that case
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This reads the SPP packet payload data after parsing the SPP packet
header and validates that not more and not less bytes than reported
in the header are read.
Fixes#257
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 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>
Otherwise memory is leaked so we cannot run negative tests with memory
leak detection (ASAN) enabled.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This enables us to differentiate from sanitizer errors - e.g. the UB
sanitizer returns 1 as exit status.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We have adapted the length fields inside bundles to 64 bits, so we need
to use a 64-bit format specifier here.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Changes all occurrences of the old script paths from tools/ to the
scripts installed by python-ud3tn-utils.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
Otherwise the program aborts on `ASSERT(result != NULL)` in this case.
See also the BPv7 tests for an explanation of the parser's behavior.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We also need argv to be non-const for this to work. Switching to const
everywhere collides with out handling of command line arguments in
`cmdline.c`.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a target `data-decoder` which builds a binary to decode a
specified binary file using uD3TN's parsing logic (based on the CLA RX
subsystem) and print details about it. In this first version only the
decoding of BPv7 bundles is implemented.
This binary can be used, e.g., for fuzz testing.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
