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>
