| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This is part of an implementation for proposal 368.
|
| | |
| |
| |
| |
| | |
`CircHop::relay_format()` returned the same thing as
`CircHop::relay_cell_format()`.
|
| |/
|
|
|
|
|
| |
I think this was addressed by @opara in
eca15143ba80b789382ba7cbe19601d3b98e42c2.
Spotted while refactoring `CircHop`.
|
| |\
| |
| |
| |
| | |
tor-proto: Reduce `high_water_mark` of ChannelFrame
See merge request tpo/core/arti!3447
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
proto: Rename RelayReatorHandle to RelayCirc, make it pub
See merge request tpo/core/arti!3410
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We don't really need this channel here, because we already have control
and command channels for checking if the reactor task is still alive.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
While this is technically a "reactor handle", I think RelayCirc sounds
better, because this is essentially our only public API for interacting
with a relay circuit (it will be used outside of tor-proto).
(This would also be consistent with our existing ClientCirc
client-side terminology).
|
| | | |
| | |
| | |
| | | |
This will soon become `pub`, so I am factoring it out of `reactor.rs`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
BackwardReactor is an implementation detail, so it shouldn't really be
mentioned in the soon-to-be-public-facing docs.
And besides, the control messages are no longer handled by the
BackwardReactor.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
proto: Move cell_sender out of the client module
See merge request tpo/core/arti!3407
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Soon we'll use CircuitCellSender in the relay reactor too (we need to,
because it provides a useful abstraction for handling block/unblock
padding actions, and because it has some handy helper functions such as
`congestion_signals()`).
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
This is in preparation for moving `CircuitCellSender` out of the client
module (it makes the next commit easier to review, because
`cell_sender.rs` will be moved without any modifications).
|
| | | |
| | |
| | |
| | | |
Run maint/add_warning
|
| | |/
|/| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Possible fix for #2232.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Unlike assert!(matches!(..)), assert_matches prints the value of the
expression on a failure.
Probably we should use this macro more widely in the future.
This might help diagnose recurrences of #2232
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This will replace ClientCircView in the IncomingStreamRequestFilter
APIs, which will enable us to use IncomingStreamRequestFilter for
incoming streams on the exit side too.
|
| |/ |
|
| |
|
|
| |
We replaced TunnelId with UniqId in the relay code a while ago.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is only done if we kept the AUTH_CHALLENGE cell and we have relay
identities. In other words, this is only when the UnverifiedChannel was
created from a RelayInitiatorHandshake.
Note: The check_internal() function is too large and should be
refactored in smaller pieces.
Note: It is also likely that we need to split UnverifiedChannel and
VerifiedChannel as it is getting client or relay members. Not great.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The client and relay channel builder don't share anything and return
different objects hence the seperation.
Furthermore, this seperation avoids having the client ChanMgr ability to
launch relay channels.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a intermediary object between tor-chanmgr and tor-proto that is
when building a relay channel, those keys/certs need to be set in the
ChannelBuilder so the tor-proto can use them to authenticate.
We avoid that way making tor-proto depending on tor-keymgr for the
ultimate goal to avoid tor-proto to have access to all the keys in the
KeyMgr.
Future commits will introduce a relay channel builder which will use
that object to set the keys.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit only adds a struct holding all the authentication data that
needs to be built during the verification process after all handshake
cells needed for authentication have been sent.
It lives in the VerifiedChannel struct so it can be used to build the
AUTHENTICATE cell and be sent before the NETINFO.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
This implements the relay initiator side of the handshake up to the
creation of an unverified channel.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Upcoming code for relay channels are put in the src/relay module and
thus we need visibility into some channel generic things.
Turns out also we don't need to re-export publicly UnverifiedChannel and
VerifiedChannel.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
We need to give the control channels higher priority here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|