This version should be compatible and available on most current systems.
(A compatible protoc version is needed to (re-)generate the modules.)
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
It is often required to print a proper error message if an unexpected
ResponseStatus is received from µD3TN. Because ResponseStatus is an enum
generated by Protobuf, there seems to be no easy-to-use `name` property.
Thus, we provide a function for mapping the integer values to a readable
string representation in the AAP2Client class.
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 adapts the v1 tools to the recent changes in the AAPv2 tools so
they use the same return codes and (error) messages.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We are using exceptions for signaling users of the AAP2Client that
communication with µD3TN failed when receiving data, however, we did not
differentiate between normal connection closure and abnormal conditions.
This adds a `AAP2ServerDisconnected` exception to signal that µD3TN has
closed the connection. The supplied tools are adapted to properly handle
both this new exception and other usual cases for termination such as
keyboard interrupts, so that no unnecessary stack traces are printed.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This extends the message printed by aap_contact_plan_reader.py to
explain that it can still be used if we launch µD3TN with the
--allow-remote-config commandline flag.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This script is outdated as it does not support the newest approach to
filter bundles and also does not support the authorization required by
the storage agent (the flag is set via AAP 2.0).
aap2_storage_agent.py should be used instead.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This uses the value provided via AAPv2 to reduce the size of the
scheduled bundles to ensure the maximum bundle size is not exceeded.
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>
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>
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>
`pyproject.toml` is the new unified Python project settings file
that replaces `setup.py` and other build-systems by introducing a
build-system independent format for source trees. The installation of
setuptools and wheel is no longer necessary as it is automatically
bootstrapped.
https://peps.python.org/pep-0517/
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>
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 "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 adds an asynchronous implementation of the AAP 2.0 client classes
so they can be used with asyncio.
Note that only some functions are concurrency-safe:
If we access the AAP2AsyncClient from multiple places concurrently, the
calls to `send()` and `receive_response()` may overlap. When it is not
intended to use multiple connections, an `asyncio.Lock` together with
functions to send and receive the response directly in sequence now ensure
that this cannot happen. The new `_rpc` functions are provided for that
purpose. Which functions are concurrency-safe is also indicated in the
docstrings.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Previously, in some cases, we might otherwise return None which can
result in misleading error messages. This makes the connection breakage
explicit also in `_receive_all`.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This allows us to receive delimited messages longer than 127 bytes.
Previously we only used the last-received byte as length even though we
correctly decoded the full varint.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds functionality to dispatch bundles and control the FIB to AAP
2.0 and the bundle processor, replacing the old "router" completely.
AAP 2.0 is extended slightly to enable fragmentation.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds the data structures necessary for controlling the set of CLA
links and dispatching bundles from AAP 2.0 Clients.
See also the new documentation in doc/aap20.md.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- Introduces a CompoundBundleId to filter exactly one bundle
- Filter bundles either by their ID or selected metadata
- Transfer the entire StorageCall object to the CLA via the agent queue
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
Adds protobuf Python language bindings and a build target to create them
to the python-ud3tn-utils package.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
This makes AAP2Client.send() write everything to the socket at once to
better leverage OS optimizations (e.g. if Nagle is disabled we would
send 2 packets otherwise). Also it prevents our tests for the connection
closing behavior of AAP 2.0 for failing randomly because of a race
between the two send() operations and cloding the AAP socket from uD3TN
side.
See: #188Fixes: #188
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- pyd3tn: Fix pinned cbor version
- python-ud3tn-utils: Update protobuf to version 2.24.4
- tools: Update flake8 to version 6.1.0
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
On some platforms, notably macOS, the `shutdown()` methos will return an
error when the socket is not connected anymore. This raises an exception
if we use an `AAP2Client` in a `with` block and the connection is
terminated before the end of the block, e.g., because the peer closed
it. This commit changes the behavior such that any `OSError` raised by
the `shutdown` method is ignored (it is just there to cleanly signal
termination to the other end anyway and if this is not possible it is
unnecessary).
Fixes: #174
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
protobuf==4.21.12 requires python>=3.7[^1]. To resolve the version
conflict between μD3TN and the protobuf package, the required minimum
Python version is set to >=3.7.
[^1]: https://pypi.org/project/protobuf/4.21.12/Closes: #153
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
Since protobuf==4.24.4 is not (currently) part of nixpkgs, but
protobuf==4.21.12, the pinned version is changed to reduce the effort
for packaging version 4.24.4 itself.
The protobuf Python language bindings have been regenerated to
incorporate the changes from the modified version.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
This adds proper docstrings including documenting return values and
exceptions for the `aap2_client` module.
Signed-off-by: Felix Walter <felix.walter@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>
There might be incompatible changes in those messages before their
public release. As we only support basic send/receive functionality over
AAPv2, we do not need to include the definitions of other messages.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This defines exception classes for specific types of errors that may
occur within the AAPv2 client, so we can drop the assert statements and
the user of the client can handle errors appropriately.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds the option to enable keepalive messages for AAPv2 in the
aap_receive and aap_ping tooling, so that the AAPv2 connections stay
alive until bundles are received.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
If there is already an agent registered for the other direction of
communication, registration will fail as long as the provided secrets do
not match.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
We specify AAP 2.0 to be an RPC protocol whereas the direction of calls
can be switched during configuration. Each call needs to be answered.
This change adds the answer for bundle reception by a client.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a DispatchRequest message containing a DispatchReason in
extension to the bundle headers. By that we can pass more information to
the BDM about why the dispatch request was triggered and have it
extensible in the future.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
