| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
proto: Return internal error on TRUNCATE
See merge request tpo/core/arti!3675
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is not yet implemented, so we should just return an error for now
(`todo!()` will cause a panic, shutting down the thread the reactor is
running on. We don't want this happening when we start manually testing
our WIP impl, because depending on which thread it happens on, it can
make the entire relay process unusable).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We will want our channel selection functions (`open_channel_is_allowed`,
`pending_channel_maybe_allowed`, and `choose_best_channel`) to inspect
the requested target addresses in the future (see their TODOs), so these
functions need to take a `HasAddrs` to get those addresses.
|
| |/ / /
| | |
| | |
| | |
| | | |
This will be needed later so that our channel selection functions can
take a `HasAddrs`.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
proto: Handle backward cells in the reactor
Closes #2345
See merge request tpo/core/arti!3666
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Closes #2345
|
| | | | | |
|
| | | |/
| |/|
| | |
| | | |
This will tell the base `BackwardReactor` how to handle the cell.
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| | |
Without this change `arti` fails to compile with the `onion-service-cli`
and `onion-service-service` features enabled.
Closes #2347
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
A client can have the relay feature enabled. The presence of
"identities" is what dictates if we are a relay or not.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Also, allow the `ChanMgr::runtime` to be unused as client don't use it
yet but might one day.
Simpler this way than feature gating it for relay only.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Implement the accept_from_transport() in the ChanBuilder.
This returns a `Channel` and spawns a reactor.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| | |
This type is needed in the tor-chanmgr crate in order to decide to
verify or not the underlying relay channel.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This requires the `TlsKeyAndCert` so be passed on the TLS acceptor
settings. We assume that `RelayIdentities` has this information.
The ChanBuilder::new() was getting a bit too convoluted and feature
gated to instead we introduce new_client() and new_relay() and remove
the need for `with_identities()`.
Because of this, the ChanMgr::new() now returns a `Result<>`.
Related to #1597
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
This makes it that we can get a server TLS acceptor provider which we
need for incoming connections.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Set package.metadata.docs.rs.all-features to true for all crates
Closes #2307
See merge request tpo/core/arti!3656
|
| | | |
| | |
| | |
| | | |
Makes docs.rs also document types behind optional feature flags.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
proto: Start handling EXTEND2 in the relay reactor
Closes #1447
See merge request tpo/core/arti!3648
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
See discussion at
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3648#note_3339863
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implements this part of the spec:
```
To tear down a circuit completely, a relay or client sends a DESTROY
cell to the adjacent nodes on that circuit, using the appropriate
direction’s circID.
```
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This doesn't need to be async, as it delegates the handling to a
background task.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To handle EXTEND2, the relay `ForwardHandler` impl spawns a background
task, which reports back the result via the `CircEvent` MPSC stream.
This stream is polled from the `ForwardReactor` main loop, and each
`CircEvent` is passed back to `ForwardHandler::handle_event()` for
handling.
|
| | | | |
| | | |
| | | |
| | | | |
These will be used by the relay code too (for circuit extension).
|
| | | | |
| | | |
| | | |
| | | | |
Users reading the log won't necessarily know what a "forward channel" is.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This will enable us to obtain implementation-dependent asynchronous
events (such as the outcome of an extend handshake).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will be needed by relays, for wrapping tor_linkspec decode errors
(which can happen if the link specifiers in the EXTEND2 cell can't be
converted to a channel target).
|
| | | | |
| | | |
| | | |
| | | | |
To match the `ChannelProvider::get_or_launch()` function signature.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We need the unique_id here, because the Forward handler will soon start
using the `ChannelProvider::get_or_launch()` to launch outbound
channels, which takes the reactor unique_id as an argument.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The channel provider is relay-specific, so I am moving it to the relay
`ForwardHandler` implementation. This enables us to get rid of some of
the feature gating from the generic reactor.
|
| | | | |
| | | |
| | | |
| | | | |
This is currently very similar to its client counterpart.
|
| | | | |
| | | |
| | | |
| | | | |
We will need the ability to build one from within tor-proto.
|
| | | | |
| | | |
| | | |
| | | | |
Needed for handling the linkspecs in an EXTEND2 cell.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This was leftover from back when this command was only for Sendmes.
|
| | | | |
| | | |
| | | |
| | | | |
This just removes an unnecessary `async`.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
proto: Make ChannelProvider::get_or_launch() synchronous
See merge request tpo/core/arti!3647
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This just removes an unnecessary `async`.
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | | |
Allow to set paths in CLI arguments
See merge request tpo/core/arti!3556
|