This removes the Unified-API-specific code from the AAP2 client. As
dicussed in !238, it fits better in the upstream repo.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
AAP2 uses uint32, so we do, too. This moves the check for a negative
value to the UAPI backend implementation.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This implements an AAP 2 C client based on the Unified API code for the
µD3TN AAP 2 interface. The implementation consists of two parts; a
generic AAP 2 client (aap2_client.c) and a Unified API compatibility
layer (aap2_unified_api_backend.c). The core difference between the two
is that the Unified API compatibility layer automatically creates two
sockets (a sending and a receiving one) and generates a common AAP 2
secret shared between the two. Moreover, the generic client offers some
additional AAP 2 options that are not available in Unified API. Thus,
the generic client features slightly higher flexibility and is intended
as the default solution when developing applications that only need to
interact with µD3TN.
The following design considerations for the generic AAP 2 client are
noteworthy:
- The client struct is an opaque object that is fully managed inside the
generic AAP 2 client implementation. This way, we have full
flexibility for adaptations in the future.
- Inspired by the Unibo code, the `aap2_client_register` and send/recv
functions use dedicated spec structs, which are more extensible than
using individual function arguments (fields can be added flexibly).
- Support for timeout and keepalive is added where applicable to enable
recognition of broken TCP connections and keep firewalls happy.
- Log messages typically use the "debug" level, except if they indicate
a broken connection ("warn") or a danger to overall continued program
execution ("error").
The generic AAP 2 client contains some minor bits from the original
Unified API client code:
- The `receive_payload` was mostly moved to the generic part, only
adding special handling for (valid) zero-length payloads.
The Unified API compatibility layer was implemented based on the
original Unified API code, adapting it to make use of the generic AAP 2
client implementation.
The following changes to the coding style were performed to adapt it to
µD3TNs style guidelines (Linux kernel coding style):
- use tabs according to the Linux kernel style guide
(`ERROR:CODE_INDENT`, `WARNING:SPACE_BEFORE_TAB`, `WARNING:LEADING_SPACE`)
- add some spaces after declarations (`WARNING:LINE_SPACING`)
- do not assign inside if statements (`ERROR:ASSIGN_IN_IF`)
- use parentheses for `sizeof` everywhere (`WARNING:SIZEOF_PARENTHESIS`)
- adapt indent (`ERROR:SWITCH_CASE_INDENT_LEVEL`)
- remove trailing whitespace (`ERROR:TRAILING_WHITESPACE`)
- adapt function declarations
- adapt block comment style (`WARNING:BLOCK_COMMENT_STYLE`)
- use `__func__` instead of `__FUNCTION__` (`WARNING:USE_FUNC`)
- remove unnecessary braces (`WARNING:BRACES`)
- put opening brace after declarations of e.g. `enum`
(`ERROR:OPEN_BRACE`)
- make pointer `*` location consistent (`ERROR:POINTER_LOCATION`)
- use memcpy and snprintf instead of string functions such as str(n)cpy
The following additional changes to the original Unified API code were
performed:
- removal of legacy and deprecated code (commented check in
`ud3tn_free_payload`, function `ud3tn_ping_aap`)
- removal of status report features/stubs: the actual integration was
not implemented; we can add it back in the future when support for
decoding status reports in the generic portion is implemented
- re-implement ping feature based on AAP 2 keepalive mechanism: the
generic client features a keepalive method, which we can use in the
Undified API compatibility layer
- adaptation of all `DEBUG_*` log statements to the corresponding µD3TN
`LOG[F]_*` macros
This means that functions that will be reused in the AAP2 client are
moved to a common `aap2_util` file. Slight adaptations to the naming of
individual functions are made as they are not `static` anymore. This
also adds handling for the status report ADU flag in
`aap2_get_adu_flags`, which was missing beforehand.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
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>
