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 function to decode JSON configuration via Jansson to the
router agent. The JSON functionality and, thus, the dependency on
Jansson, can be disabled during the build process by setting the
`DISABLE_JSON` compile-time flag (see `config.mk.example` for details).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Previously it was not possible to disable SQLite because of a linker
error. Also, `sqlite3.h` was always required to be present. This adds
an example to `config.mk.example` and fixes both issues.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
It only controls how status reports should look like, not which status
reports are requested. We only want to check for the latter. ION appears
to always set this flag.
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>
The defaults for the AAP and AAP 2.0 TCP ports were the same. Thus, if
we specify a TCP host for both, µD3TN will terminate on startup as the
port is already in use by one agent but it tries to bind to it with
both.
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 allows for using AAP 2.0 over TCP, which the Python tools support
already. Note that the user must make sure that the socket is not
exposed externally.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This was confusing users. We are adding a detailed explanation in the
man page and informing in the help text that the parameter refers to the
administrative endpoint of uD3TN.
Fixes: #213
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We do not need this anymore. If we need it again in the future we should
possibly choose a more modern syntax (it is now available in C23).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This improves const correctness, at least for pointers (making the
pointed-to data const where possible).
Some suppressions are added for false positive warnings, such as in
`simple_queue.c` where an arithmethic operation is used on the pointer
to calculate a non-const pointer that is returned (thus, the passed
pointer should also not point to const).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The stylecheck complains that we do not use the argument there. We now
explicitly ignore it by casting it to `void`.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This fixes another potential deadlock: The BP calls the "start contact"
function of a CLA, which in turn discovers that the link is already
active and attempts to put a notification of link establishment into the
BP queue, which may be full and is not consumed as this is running in
the BP thread.
The solution here adds an extended return value for the start and end
contact functions in the CLA interface, enabling them to indicate to the
BP whether a link change has been initiated (and will be performed
asynchronously), is not necessary (the state is already the intended
one), or was performed synchronously.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The FIB fulfils two purposes: 1) map node IDs to next-hop CLA addresses
and 2) store the current status of a link associated with a given CLA
address.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This prefixes all compile-time options of the compat. router with
`ROUTER_` and adds them to config.mk.example so they can be easily
discovered and adapted.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This makes µD3TN behave the same as v0.13.0 when executed without an
additional commandline argument. A new commandline argument `-d` /
`--external-dispatch` is added, which enables the use of external BDMs.
The default forwarding implementation is now again provided using the
v0.13 code, extracted from e1621765a4 and
adapted to the new agent-based forwarding implementation.
Central changes to the old code include:
- A new "Routing Agent" that handles incoming configuration commands,
FIB updates, and BDM dispatch requests.
- The use of the BDM authorization flag to authorize contact
configuration commands.
- The Contact Manager now only triggers the creation and removal of
links / FIB entries; bundle dispatch is triggered through the FIB and
BDM callback functions of the Routing Agent.
- The fragmentation logic is adapted to store the original bundle along
with an offset and length value, instead of pre-creating and storing
the fragments.
- The bundle re-scheduling logic integrated into the Routing Agent is
simplified and does not support changing the fragmentation parameters.
A new function is added to the Router that searches for a new route
for such fragments that were already scheduled at some point,
considering them as un-fragmentable bundle with overridden fragment
offset and length.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds the code from e1621765a4 back
into the tree unchanged, but moved into two new directories, in
preparation of the following commit, which adds a routing agent on this
basis, to make it possible to review the diff properly.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
In agents performing such functions we do not need to add elements to
the queue if we can directly call the corresponding BP function.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
It prevents us from declaring the array in a function body without
malloc() and also has a possible risk out-of-bounds accesses when not
used carefully.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The bundle block length, fragment offset, and total ADU length fields
were using 32-bit uint types, effectively reducing the maximum bundle
payload size to 4 GiB. This changes the field types to 64-bit uint, so
we can support larger bundles.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This ensures that internal counters do not overflow and we can prevent
DoS by BDM responses containing lots of next hops (e.g. in case of BDM
bugs) to some extent.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The main reason here is to not initialize a CLA that has a hard limit on
the maximum bundle size (TCPSPP) by default. TCPSPP is rarely used anyway,
so we can disable it and save some memory in the default configuration.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We should be able to honor the fragmentation threshold again. This
passes the maximum bundle size variable to the AAPv2 agent. The value is
determined as the minimum of all maximum bundle sizes reported by the
CLAs and the one specified on the command line, with the special case
of the value 0, which means a maximum bundle size of 2^64 ("unlimited").
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
With the addition of the storage agent and the compat. BDM we have the
issue that two new agents accept configuration through bundles, which
cannot check that those bundles come from trustworthy sources. In the
past we restricted contact configuration messages to local clients and
performed an "EID spoofing detection" so that we could check the source
EID - if it is the same as the local node ID, we allowed the
configuration bundle to be processed. With AAPv2 and potentially more
security-relevant components (such as BDMs) appearing in the future, we
need a new mechanism.
The idea behind the implemented mechanism is to reuse the existing AAP
2.0 shared-secret authentication that is applied for BDMs themselves
also for sending configuration messages: We add the possibility to
register an AAP 2.0 RPC agent (one that sends commands *toward* uD3TN)
with the "dispatch" authorization flag. This client can then request a
special flag to be added when sending bundles. The new flag is only
added internally by uD3TN to its in-memory data structure and is
delivered to all internal agents as well as AAP 2.0 clients receiving
the marked bundles. Those agents and clients (such as the sqlite/storage
agent) can then easily check for the flag to be present and thus
determine whether the bundle comes from an authenticated and authorized
source.
Note: The `adu_flags` field for the BundleADU AAP 2.0 message is now a
`repeated` field to represent the option of multiple flags being present
(Protobuf does not support bit fields for this purpose).
Fixes: #187
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Adds support for a volatile in-memory database by enabling support for
URI-based database file names. Since the in-memory DB can only be
accessed within the process, the integration tests are changed so that
external SQL queries are only performed when a persistent DB file is
used.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
We do not want to deal with the complexity of recursive fragmentation
when potentially re-dispatching fragments. Additionally, we need to be
able to properly report forwarding success or failure as per BP. This is
achieved by tracking everything based on the original bundle and
associating created fragments with it.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
When transmission had been attempted and generated a "TX
success/failure" result, the BDM will need the information which
transmission is affected by the generated dispatch. Additionally, the
term "DispatchRequest" is imprecise, as uD3TN does not require the BDM
to dispatch the bundle in any case (it can do so, but especially after
TX success/failure, oftentimes, it is intended to just proceed with
normal bundle processing).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a flag to the bundle data structure indicating whether the
bundle is a fragment created in the current process. Based on that, a
log message is issued when re-dispatching such a bundle, as this may
be a BDM bug. We should evaluate whether or not to forbid this
altogether in the future.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This was never used in the new version of AAP 2.0 - we will decide
whether or not to dispatch externally based on a flag in the FIB in the
future.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a "flags" field to the FIB link, allowing for configuring a
link for "direct dispatch", i.e., to make it usable without first
contacting a BDM. It is important to make this optional as otherwise
contact-based routing and QoS could not be implemented properly via a
BDM.
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>
Some CLAs may block sending to the underlying layer, e.g., the storage
CLA may wait for the DB to become ready. This increases the default
queue length to prevent blocking the BP in such cases.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Read transactions need a short, blocking, lock for the database, during
which no write transaction can be started - this means the interaction
of the agent, TX, and RX tasks may block each other if anything takes
longer than 1 ms. Thus, we increase the timeout for blocking locks to
100 ms to significantly reduce that probability.
See: https://www.sqlite.org/src/doc/204dbc15a682125c/doc/wal-lock.md
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We are not using it anymore. As the BDM decides on anything related to
fragmentation, the parameter perspectively needs to be passed there,
either directly or through the mechanism we use for the minimum bundle
size (the `BundleDispatchInfo` message as part of the `DispatchRequest`
message).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This enables a clean termination of all agent connections on program
exit without memory leaks that might previously occur due to the "pipe
queue" still holding some data (pointer to allocated memory) when
close() is called on the pipe. For that purpose, the "pipe queue" is
replaced by our standard hal_queue implementation, which also has a
higher performance as it does not require a syscall on every read/write
operation.
As hal_queue does not support poll() (it does not provide a fd), we
cannot check whether the socket has been closed by a subscribing AAP2
client while concurrently waiting for the internal queue. As an
alternative, this implements a liveliness check, which checks the sub.
connection opportunistically from the agent manager: When a new
registration is requested, existing registrations are first
"health-checked" and removed if down, so the new connection can take
over if an old one is down and this was not detected previously.
Based on the new infrastructure, a clean termination routine is
implemented that terminates all tasks transitively by terminating the
listener.
An AAP2 connection handler ("comm task") can terminate in two ways:
1. During runtime, when the connection is closed, it must clean up its own
resources.
2. On program termination, all connections must be cleanly closed and
all outstanding mesages handled.
For 1., we keep using detached threads and allow them to release all the
resources. This commit mainly introduces a mechanism for 2.: A list
tracking all comm. tasks is added that can be used to terminate and wait
for all of them on program termination. A "termination flag" indicates
whether tasks should clean up by themselves or the listener task takes
it over. Everything needs to be protected by mutexes for safe
concurrency.
There is specific handling for macOS, which does not signal other
threads clocking on a socket that the socket has been closed when
calling shutdown() but only when calling close() - thus, close() is
executed earlier on macOS. Also, macOS does not unblock poll() when the
socket is close()d, so we do not use it anymore to wait for data on an
RPC connection, but rather set SO_RCVTIMEO for active-client (RPC)
connections to enforce the keepalive timeout.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This enables us to check if an agent connection went down synchronously
when trying to register a new agent, removing the need to wait until
uD3TN detects it on its own (if it even can).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This makes it much more unlikely that the queue fills up, even under
high load. We however still need a long-term solution for the loop
issues sketched in #189.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
