Otherwise, we may get dependency conflicts, depending on the order in
which we install the modules and requirements file with pip.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We should not need to wait between setting up individual contacts, as
the commands are even sent to different BPA instances. We only need to
wait after configuring the contacts and before sending the bundle, so
that the contact has definitely started.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We must ensure that the receiving end can start before injecting
bundles, otherwise this becomes a race condition. We saw this issue in
the ION-BIBE interoperability test.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
As discussed in #215.
Note: The basis of this code has been AI-generated using Claude Sonnet 4,
but it was reviewed line-by-line and heavily refactored.
Prompts:
- "Create a new integration test in `test/integration` that tests the
newly-introduced status report feature. The test should send a bundle with
a set report-to EID, which may be the (local) sender. The created status
report should then be received and checked that it contains the
correct data."
- There is an issue in `_wait_for_status_report`: `sub_client.receive_msg`
can block indefinitely and there is no possibility to specify a timeout.
However, you could make the test async which allows aborting the receive
function. There is an async AAP2 client and an example for a test based
on it in `test_aap2_async_client.py`.
- I updated the test file. Adapt it so it passes the flake8 check which
gives the following errors: (pasted line-length issues)
- Extend the check of the received status report in the test by parsing it
as valid BPv7 (RFC 9171) status report. An implementation that can be
used for serializing status reports can be found in lines 525-566 of
`pyd3tn/bundle7.py`. The status report is in CBOR format. We use the
`cbor2` library in the project. The BPv7 spec can be found here:
https://www.rfc-editor.org/rfc/rfc9171.html#name-bundle-status-reports
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 the JSON parser logic as an alternative to the custom legacy
format and also adds necessary tests.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This introduces a JSON contact configuration format for the
deterministic first-contact forwarding (DFCF) implementation as a modern
alternative to our homebrewn configuration messages. For now, it is only
supported in the external DFCF BDM, but integration into the "router
agent" is planned.
Example JSON configuration string (from our tests):
```
{
"command": "ADD",
"node_id": "dtn://ud3tn2.dtn/",
"cla_addr": "mtcp:127.0.0.1:4223",
"reachable_eids": [
"ipn:1.0"
],
"contact_list": [
{
"start": 1401519306972,
"end": 1401519316972,
"data_rate": 2400,
"reachable_eids": [
"dtn://66553/",
"dtn://89326/"
]
},
{
"start": 1401519506972,
"end": 1401519516972,
"data_rate": 1200,
"reachable_eids": [
"dtn://12349/",
"dtn://89326/"
]
}
]
}
```
Closes: #15
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a test for the new JSON-based query feature of the BDM. The
test is only enabled in the debug integration test for the external
dispatcher and does not run by default, as it does not specify an AAP
2.0 secret and also does not work with the built-in DFCF forwarding
module.
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>
As Python 3.8 is end-of-life and the latest python-protobuf package
requires at least Python 3.9, the minimum Python version is set to 3.9.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
When the system is under load, 500 ms may not be sufficient for the
instances to start. In this case, aap2-config terminates as it does not
find the socket. When this happens, the `TMPDIR` variable is still
unset, triggering another error message. This fixes both issues.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Otherwise memory is leaked so we cannot run negative tests with memory
leak detection (ASAN) enabled.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This enables us to differentiate from sanitizer errors - e.g. the UB
sanitizer returns 1 as exit status.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We have adapted the length fields inside bundles to 64 bits, so we need
to use a 64-bit format specifier here.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This makes the test show *all* logs in a sensible order and also enables
the display of memory leaks plus backtrace in case ASAN with leak checker
is active.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This restarts µD3TN and the BDM after sending a bundle and triggers
sending it again after restarting both services.
Closes: #222
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>
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>
There have been recent changes in ION's BIBE implementation [1], which
necessitate adapting the configuration files. As a result, they do not
work with IONe anymore, which uses the old syntax. Thus, we will only
support BIBE interoperability with ION mainline and remove the
corresponding test. Nevertheless, some comments have been added to make
it work with IONe.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- ION: 4.0.1 => 4.1.3
- IONe: 1.0.1 => 1.1.0
- HDTN: 1.0.0 => 1.3.1
- DTN7: 0.19.0-732d1a0 => 0.21.0
For ION-DTN>=4.1.1 the official distribution site has moved to
GitHub[^1].
[^1]: https://github.com/nasa-jpl/ION-DTN
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>
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>
Since the last update of the cbor[^1] library was in 2016 and the
repository no longer even exists, the cbor2[^2] python library is now
used instead.
[^1]: https://pypi.org/project/cbor/
[^2]: https://pypi.org/project/cbor2/
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
Use the `run_aap_recv()` function from the python-ud3tn-utils package
instead of copying the code.
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>
- Moves `tools/aap` + `tools/aap2` to `python-ud3tn-utils/aap*/bin/` to
add the scripts to the python package
- Adds a `main()` function to each script to reference it
- Define `logger` as global variable
- Adds a symbolic link to keep compatibility with existing tooling
- Moves `tools/aap/aap_test.py` to `test/functional/`
- Adds additional dependencies (pyd3tn, cbor) to python-ud3tn-utils and
the corresponding nix package
- Add scripts to python-ud3tn-utils `pyproject.toml`
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
We must either allow accepting configuration from an external source or
use the AAPv2 method with authentication for the integration tests to
work. This uses one of both approaches in each of the tests, so both are
also validated to work.
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>
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 an argument to use either BDM-based or direct (FIB) dispatch
through pre-configured persistent links and makes the latter the
default. Also an AAP2 secret is passed, so uD3TN release builds can be
evaluated.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
