- 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>
- Validate payload block presence and its number.
- Validate bundle age block presence.
- Validate requirements concerning no hop count and previous node block
duplicates.
- Validate block numbers and check for duplicates.
- Fix parsing of BPv7 block number to explicitly reject numbers > 255
(we only support uint8_t for this atm.)
Closes: #248, #249, #250, #251
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 is a remnant from our "EID manager" with which we were trying to
reduce copies of strings in memory. This module has long been removed as
it lead to only small gains while complicating everything. However, it
seems that during the removal process we introduced an unnecessary
strdup() here, which is removed by this change.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
It may be the case that `block_type` is invoked directly at a chunk
boundary, leading to it returning CborErrorUnexpectedEOF.
This ensures that the already-constructed block entry is reused when, in
this case, `block_type` is invoked again after filling up the chunk
buffer.
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>
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>
For arbitrarily-long data such as block payload data, a "BULK_READ" operation
is requested, normally to be handled by the RX task. Though, sometimes we can
handle this on our own (if we have enough data in the current buffer).
Thus, we first check whether, given the bytes in the buffer, we can perform
the bulk read operation on our own. However, before doing this, we
sometimes attempted to re-initialize the TinyCBOR parser (in case
cbor_value_at_end returned true), which resulted in an error if the head
of the current buffer points to some binary data that is not valid
CBOR. With this change we always perform the "BULK_READ" first and
re-initialize the parser only after it is done.
Fixes: #49
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>
