Sometimes we use CLA addresses such as "smtcp:" or "tcpclv3:", without
an actual next-hop address on the CL. In this case, we do not drop all
FIB entries referencing the "generic" CLA link if a FIB request for
deleting an entry is received.
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>
If an agent finds out it has a broken connection (the client
disconnected) on a liveliness check (e.g., if another client wants to
register the same agent ID), the agent manager will de-register it, as
it needs to register the new agent immediately and there is a race
condition otherwise. In this case, a warning was shown that should
however only be a debug information.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This makes aap-config / aap_config.py (AAPv1) work again in the default
configuration (debug build, default BDM, no secret set). This way,
pre-existing documentation (YouTube videos, ...) stays usable.
The security properties will not be impacted by this change as AAPv2
clients will be able to do administrative actions anyways if no secret
is set.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a check for detecting EOF and differentiate such an "error"
from actual Protobuf decoding errors so people do not get confusing
log messages.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Allowing both "cla:" and "cla" may lead to issues for single-connection
CLAs (those that do not use CLA-specific addresses): the FIB may contain
entries for both and only one may be marked as "up" if both forms are
used interchangeably.
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>
Everything related to single bundle transmissions only triggers DEBUG log
messages. Non-critical errors trigger warnings. State changes that
potentially affect many transmissions but are part of normal operation
trigger info messages.
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>
If either the CLA to be used reports a maximum bundle size larger than
the anticipated serialized size of the bundle or a smaller global
maximum bundle size has been set on the command line, the bundle to be
sent must be fragmented before sending it to the next hop.
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>
We now treat this value specifically and it is easier to handle in AAPv2
as Protobuf will not transmit fields that have been assigned their
default value (0 in this case).
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>
It is not necessary anymore to secure our configuration. Loops in DTNs
should be allowed and only be controlled through the bundle lifetime.
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>
This value makes no sense as it does not represent a valid state of the
Link. A discovered Link is only added to the FIB in case it is really
active. We may make this an additional flag in the future but, for now,
it is not used and can be safely removed.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
If an existing agent has set an empty secret, we now disallow the
registration of another agent under the same sink to make secure
operation the default.
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>
In the unit test runner we do not start the uD3TN tasks, but tried to
terminate them cleanly if we send a signal to the application.
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>
If we receive a dispatch result for an already-fragmented bundle that is
to be fragmented further, we need to calculate the offset inside the
bundle as it is expected by the bundle fragmenter in this way.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
On TX success, we issue a dispatch request, which typically receives an
empty result (-> ok; bundle can be dropped). This was treated as a
transmission failure, which it clearly is not.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
cpppcheck as well as clang-analyzer report a memory leak as they cannot
infer that the pointers are pushed through the queue to a consumer
free()ing them.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
