| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the `destroy_from_client()` test to also check that a
DESTROY received from the client (or, more generally speaking, from the
"inbound channel") is actually forwarded to the next hop.
The reason the `assert_destroy_sent()` assertion is commented out is
specified in the TODO that precedes it (tldr: testing the DESTROY
behaviour involves both the channel reactor and the circuit reactor, and
our test setup is currently quite limited, in that it doesn't actually
exercise the right channel reactor code paths for the *inbound*
channel). I plan to address this soon.
|
| |
|
|
| |
I am about to need this in a test.
|
| | |
|
| |
|
|
| |
This fixes an old bad copy-paste that I've just noticed.
|
| |
|
|
| |
This adds an example suggested by opara.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need this because the channel reactor now only sends DESTROY for
circuits that are still in the circ map (and we are about to test this
behaviour, so we need the circuit map to actually have an entry for our
test circuit).
Initially, these tests were meant to test the circuit reactor in
isolation, but they've gradually grown more complex, and now require
a semi-working channel reactor. In the long run, I think I'd like to:
* change the tests from `tor_proto::relay::reactor` to use a proper
relay channel reactor as opposed to a `working_dummy_channel()`, and
to initialize a circuit through the normal means, namely by sending
a CREATE2 through the channel reactor (naturally, this "proper relay
channel reactor" still wouldn't be connected to the network). These
will test the integration between the channel and the circuit
reactor, as well as the circuit reactor behaviour
* add new, implementation-agnostic tests for the generic multi-reactor
system. These will use a mock channel reactor
|
| |
|
|
|
| |
Now that we no longer respond to DESTROY by sending a DESTROY ourselves,
these tests need to be updated.
|
| |
|
|
| |
This test simulates the *next hop* sending us a DESTROY.
|
| |
|
|
|
|
| |
There is no `BackwardReactor` heading, because there isn't that much to
say about it (it moves `RELAY` cells in the opposite direction, and
rejects RELAY_EARLY and PADDING_NEGOTIATE).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
constructor
Replaces `TryFrom<SubprotocolRequest> for HandshakeSubprotocols`.
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
We have decided that instead of "uniq_id" in logging, we'll use the
"<domaine>-[<type>]-id" syntax to indicate who is that unique ID.
This commit only renames circuit's unique ID to "circ_uniq_id".
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This commit only affects logging. Whenever possible, log both the UniqId
and CircId.
This also changes the log lines which is now "uniq_id=" and "circ_id="
as the UniqId is internal and circ_id (CircId) is protocol level.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A CircId is now a circ_id and a UniqId is a unique_id so we stop
confusing them in the code.
Furthermore, channel_id that are CircId are now circ_id. Channel IDs are
different and encoded internally into a UniqId.
This is the first step to clarify semantic before we change the logging
to log both unique ID and circ ID.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| | |
tor-proto: Small improvements to circuit handshake tests
See merge request tpo/core/arti!4254
|
| | |
| |
| |
| |
| | |
Now that we read all of the cells from the connection inspector, we can
reuse the existing channel objects.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
These TODOs are for client issues, not relay isues.
|
| | |
| |
| |
| | |
Otherwise the new circuit gets closed immediately by the relay.
|
| |\ \
| |/
|/|
| |
| | |
tor-protover,tor-proto: Add and use a new `subprotocol_restricted_set` macro
See merge request tpo/core/arti!4241
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
`HopSettings::from_handshake_params()` checks that the parameters are
correct, so if there are invalid parameters we should fail early before
we initialize the `CryptStatePair`.
|
| | |
| |
| |
| | |
This is just to make ntor and CREATE_FAST handshakes consistent.
|
| |/ |
|
| |
|
|
|
|
| |
The advantage of this over using a `SubprotocolRequest` is that we can
use the type system to ensure it only has subprotocols that are allowed
during a handshake.
|
| |
|
|
|
| |
We never used this, it was just needed because we used to convert to a
`CircParameters` which required this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and also remove `CircNetParameters::as_circ_parameters()`.
We used to call `HopSettings::from_params_and_caps()` when handling
incoming circuit requests, but this didn't really make sense because we
already know exactly what settings we want.
The new `HopSettings::from_handshake_params()` takes the exact settings
we want, which means we can also skip constructing a `CircParameters`
and use the raw consensus `CircNetParameters`.
Most of the code in `CircNetParameters::as_circ_parameters()` has been
migrated in some form to `HopSettings::from_handshake_params()`.
|
| | |
|
| |
|
|
|
| |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4222#note_3437129
|
| |
|
|
| |
Applies @opara's suggested rephrasing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We need to return the "futures::Stream of Tor streams" from the CREATE
handler, because these need to be handled from `arti-relay`,
as per `doc/dev/notes/relay-streams.md`
This commit is intentionally (slightly) misformatted to make reviewing a
bit easier (the next commit will rustfmt everything).
Part of #2612
|
| |
|
|
|
| |
The inner type is an eyesore, and doesn't really need to be exposed
outside of tor-proto (we might even replace it at some point).
|