| 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
|
| |
|
|
| |
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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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]>
|
| | |
|
| |
|
|
|
| |
These assertions no longer fail now that the stream reactor is able to
handle non-`BEGIN` streams.
|
| |
|
|
|
|
|
| |
Tests that the customizable `IncomingCmdChecker` added for #2606 is
doing its job, by ensuring that the circuit reactor doesn't emit
`IncomingStream`s for incoming streams created with commands that are
not in the reactor's allow list.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The `CreateRequestHandler` now passes the list of allowed "incoming
stream request" commands (i.e. BEGIN, BEGIN_DIR, or RESOLVE) to the
reactor, replacing the hard-coded command list.
Closes #2606
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Part of #2582
|
| |
|
|
|
|
|
|
|
| |
Relay circuits always need a filter, so it's best to set it via the
constructor.
Part of #2582
Closes #2577
|
| | |
|
| |
|
|
| |
This is just code motion
|
| |
|
|
|
|
| |
I am about to move this out of the `extend_and_forward()` test, because
I want to reuse it in the new `reject_stream()` test for checking that
the relay wrote an END cell to the stream.
|
| |
|
|
|
|
|
|
| |
This test currently fails, because `IncomingStream::reject()` calls
`RelayCirc::close_pending()` under the hood, which isn't implemented
yet.
Part of #2590
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |\
| |
| |
| |
| | |
proto: Add a new channel -> circuit queue type
See merge request tpo/core/arti!4025
|
| | | |
|
| | |
| |
| |
| |
| | |
`CircuitRxSender` is no longer a `Sink`, so we don't need this import
anymore.
|
| |/
|
|
|
| |
This passes now that we can build a `DataStream` without a
`ClientDataStreamCtrl`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds an extra assertion that ensures the relay reactor does in fact
send an EXTENDED2 on its towards-the-client channel after receiving the
CREATED2 response from the fake hop.
This check is nice to have in general, but the main reason I'm doing
this now is because for the DESTROY tests I'm about to add, I need the
inbound MPSC queue (towards the client) drained of these handshake
messages in order to check that the "next" cell we've sent is a destroy.
I could've added some custom code to drain it just for the purposes of
that test, but I think it's better to have `do_create2_handshake()` take
care of it.
|
| | |
|
| |
|
|
|
|
|
|
| |
The new name is (hopefully) a bit more descriptive.
I'm planning on extending this function soon to support checking if a
DESTROY has been sent on the outbound channel too, so I'm tweaking the
docs a bit in preparation for that.
|
| |
|
|
| |
I'll soon need this for a DESTROY test.
|
| | |
|
| | |
|
| |
|
|
|
| |
This will soon be used for preventing the circuit from being extended to
the previous hop (#2415).
|
| |
|
|
|
|
|
|
| |
I used these `_foo` suffixes to make sense of things during development:
at the time, I had multiple "forward" and "backward" types, and I needed
to distinguish them without spending too much time thinking of a
provisory name. I meant to remove them before upstreaming my branch, but
I forgot...
|