After merging !184, the description of how the storage can be accessed
when using the integrated routing agent must be moved to the
corresponding subsection.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@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 also fixes the CLA address specified with `aap2-config` - it has to
contain a colon at the end.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- Replace a), b) enumeration with 1., 2. because this was not displayed
correctly by Gitlab
- Fix figure link to `aap20-seq_link_dispatch.svg`
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
Changes all occurrences of the old script paths from tools/ to the
scripts installed by python-ud3tn-utils.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@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>
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>
Adds a brief description of the SQLite-based storage and a guide on how
to interact with the storage.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
In order to prepare the implementation of a SQLite-based storage CLA, a
basic structure of this CLA with empty functions is created and
adjustments are made to the configuration/initialization functions and
the build system.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
- remove comments on "callback-style" serialization (not needed)
- define magic number in Python AAP 2.0 client via descriptive var
- make `secret` in Python AAP 2.0 client a private variable (used
nowhere else and should not be a class property)
- add missing Python docstrings
- add some comments explaining behavior
- language enhancements and fixes in docs and comments
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adjusts the commands for the integration tests. uD3TN needs to be started with remote configuration enabled for the tests to work.
Signed-off-by: Oleksandr Nazymko <oleksandr.nazymko@d3tn.com>
Even if this uses a secure connection, piping stuff returned by `curl`
into an interpreter is bad practice and can lead to security problems.
We now assume that `pip` and `setuptools` are installed on the target
system, which is reasonable IMO.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This moves the commands to install up-to-date versions of all
Python dependencies to the `update-virtualenv` target, so it can be
executed on its own if the user is using an own venv manager.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
See the added description in the AAP documentation - this adds an
internal format to the 64 bit integer value returned as "bundle ID" in
the `SENDCONFIRM` AAP message to uniquely identify the created bundle in
conformance to RFC 9171.
Closes: #60
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Former releases of uD3TN have included support for STM32/FreeRTOS.
Having this support from the first moment on was a good thing in
order to optimize for platforms with limited resources. As this
platform is not used in current uD3TN setups and as it results in quite
some maintenance work, it is removed with this commit. The removed parts
cover the implementation itself, tests, tools, documentation, parts of
the build/make scripts as well as licensing information.
Signed-off-by: Marius Feldmann <marius.feldmann@d3tn.com>
This adapts the provided manual page so the current command line
arguments are properly reflected, in alphabetical order (like in the
--help output). Furthermore, some typos are fixed and the name of uD3TN
is mentioned consistently.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The quick start guide recommends to add a `--dest-eid` argument to the
call to `aap_config.py` when configuring the contact from node A to B.
This is indeed unnecessary as `aap_config.py` can automatically
determine the local configuaration endpoint. The `--dest-eid` argument
is only required in more advanced cases (configuration over multiple
nodes) and implies enabling remote configuration in uD3TN.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
-> https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-31#section-4.2.5
The previous validation methods were not sufficient to check validity of
dtn as well as ipn EIDs. This adds further functions to easily detect
the EID scheme and validate dtn plus ipn EIDs. Tests for the most common
cases where validity checks should be successful and where they might
fail are added as well.
Due to this change the default EID of uD3TN gets a slash appended, as
dtn EIDs always have to contain the name delimiter '/'.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Previously uD3TN implicitly assumed string EID in many places such as
the agent manager. This adds proper handling for ipn-scheme EIDs,
using numerical service numbers as agent IDs in case uD3TN is started
with an ipn-scheme EID. If the ipn scheme is used, uD3TN always has to
be configured with the service number 0. The config and management agent
IDs can be configured in config.h and are 9000 and 9001, respectively,
to keep the lower range of service numbers free. It is intentional that
agents can register with a service number of zero - uD3TN does not
provide specific functionality under this service number.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
In order to have SENDBIBE and RECVBIBE messages have the same kind of
payload data (BPDUs) the creation of the administrative record needed
for BIBE bundles was moved from the bibe_proto.c file to the application
agent.
Signed-off-by: Tobias Nöthlich <tobias.noethlich@d3tn.com>
This commit updates the AAP docs with explanations for the SEND- and
RECVBIBE message types. It also adds a short note regarding backward
compatibility with older AAP implementations that do not support BIBE.
Signed-off-by: Tobias Nöthlich <tobias.noethlich@d3tn.com>
This commit addresses some issues concerning the documentation of
µD3TN's implementation of Bundle-in-Bundle Encapsulation.
It mostly fixes typos and changes unclear wording to be more precise,
but also expands some parts of the docs with more information.
Signed-off-by: Tobias Nöthlich <tobias.noethlich@d3tn.com>
This commit fixes some typos in the BIBE documentation and removes
an unnecessary pair of curly brackets from the bibe_proto.c file.
Signed-off-by: Tobias Nöthlich <tobias.noethlich@d3tn.com>
In order to make BIBE useable for everyone a short documentation
containing information on what BIBE is, how it works in µD3TN and
how to use it has been added.
Signed-off-by: Tobias Nöthlich <tobias.noethlich@d3tn.com>
Previously, we had a build-time flag for enabling configuration via
bundles received from other nodes. Thus, changing the flag required a
re-build. As we are depending on it also for our integration tests and
it is often handy in further setups, this change makes it a command
line argument "--allow-remote-config".
As the STM32 platform does not support command line arguments, remote
configuration is enabled by default there via config.h.
See also: !13, #32
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
