aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/relay/reactor.rs
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: add `StreamHandler::flowctrl_sidechannel_mitigations()`Steven Engler7 days1-0/+6
|
* proto: Extend test to check DESTROY is sent to the next hopGabriela Moldovan8 days1-0/+16
| | | | | | | | | | | | | 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.
* proto: Move assert_cell_is_destroy macro out of helper functionGabriela Moldovan8 days1-15/+15
| | | | I am about to need this in a test.
* proto: Add comments explaining why the tests use DestroyDirection::BackwardGabriela Moldovan8 days1-2/+14
|
* proto: Remove misleading comment and rename misnamed variableGabriela Moldovan8 days1-3/+2
| | | | This fixes an old bad copy-paste that I've just noticed.
* proto: Clarify what read_{inbound,outbound} are forGabriela Moldovan8 days1-0/+14
| | | | This adds an example suggested by opara.
* proto: Update the tests to check DESTROY is only sent when neededGabriela Moldovan8 days1-25/+72
|
* proto: Allocate a real circ id in the circ reactor testsGabriela Moldovan8 days1-13/+47
| | | | | | | | | | | | | | | | | | | | | 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
* proto: s/client/next hop in test commentGabriela Moldovan8 days1-1/+1
| | | | This test simulates the *next hop* sending us a DESTROY.
* proto: Remove redundant headingGabriela Moldovan9 days1-2/+0
| | | | | | 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).
* proto: Update table to mention all the other commands we handleGabriela Moldovan9 days1-2/+8
|
* proto: Be more specific about where the meta messages are handledGabriela Moldovan9 days1-14/+15
|
* proto: Say how forward DESTROY are handledGabriela Moldovan9 days1-1/+2
|
* proto: Clarify that "it" refers to the forward reactorGabriela Moldovan9 days1-1/+2
|
* proto: Update docs to clarify they apply to RELAY_EARLY tooGabriela Moldovan9 days1-3/+2
|
* proto: Update docs to say EXTEND2 is supportedGabriela Moldovan9 days1-5/+2
|
* proto: Update reactor docs to say TRUNCATE is unsupportedGabriela Moldovan9 days1-2/+3
|
* proto: Rename uniq_id to circ_unique_id mostly in loggingDavid Goulet2026-08-031-2/+2
| | | | | | | | | 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]>
* proto: Log both UniqId and CircId when possibleDavid Goulet2026-08-031-2/+4
| | | | | | | | | | 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]>
* proto: Re-enable IncomingCmdChecker test (fmt)Gabriela Moldovan2026-07-011-2/+6
|
* proto: Re-enable IncomingCmdChecker testGabriela Moldovan2026-07-011-14/+7
| | | | | These assertions no longer fail now that the stream reactor is able to handle non-`BEGIN` streams.
* proto: Add test for the incoming stream cmd allow listGabriela Moldovan2026-06-301-0/+48
| | | | | | | 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.
* proto: Update tests to pass the incoming cmd allow list to the reactor (fmt)Gabriela Moldovan2026-06-301-12/+21
|
* proto: Update tests to pass the incoming cmd allow list to the reactorGabriela Moldovan2026-06-301-10/+12
|
* proto: Pass the allowed incoming commands to the relay reactorGabriela Moldovan2026-06-301-1/+2
| | | | | | | | 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
* proto: Remove confusing blurb about IncomingStream handlingGabriela Moldovan2026-06-291-3/+5
|
* proto: Clarify wording in relay reactor constructorGabriela Moldovan2026-06-291-1/+5
|
* proto: Say why INCOMING_BUFFER is set to STREAM_READER_BUFFERGabriela Moldovan2026-06-291-0/+5
|
* proto: Return IncomingStreams stream from relay reactor constructor (fmt)Gabriela Moldovan2026-06-291-4/+4
|
* proto: Return IncomingStreams stream from relay reactor constructorGabriela Moldovan2026-06-291-50/+117
| | | | Part of #2582
* proto: Support passing a stream request filter to the reactorGabriela Moldovan2026-06-291-3/+33
| | | | | | | | | Relay circuits always need a filter, so it's best to set it via the constructor. Part of #2582 Closes #2577
* proto: Make the new reject_stream() test check the END cell tooGabriela Moldovan2026-06-231-1/+5
|
* proto: Factor helper macro out of test functionGabriela Moldovan2026-06-231-17/+17
| | | | This is just code motion
* proto: Refactor test macro to not rely on function contextGabriela Moldovan2026-06-231-6/+7
| | | | | | 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.
* proto: Add a test for rejecting an incoming stream in the relay reactorGabriela Moldovan2026-06-231-0/+40
| | | | | | | | This test currently fails, because `IncomingStream::reject()` calls `RelayCirc::close_pending()` under the hood, which isn't implemented yet. Part of #2590
* maint: Run maint/add_warning to deny string slicesClara Engler2026-06-091-0/+1
| | | | | | | | | | | | 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.
* Merge branch 'destroy-cell3' into 'main'gabi-2502026-06-081-2/+2
|\ | | | | | | | | proto: Add a new channel -> circuit queue type See merge request tpo/core/arti!4025
| * proto: Update the tests to use the new CircuitRx{Receiver,Sender}sGabriela Moldovan2026-06-081-1/+1
| |
| * proto: Remove now-unused importGabriela Moldovan2026-06-081-1/+1
| | | | | | | | | | `CircuitRxSender` is no longer a `Sink`, so we don't need this import anymore.
* | proto: Enable the relay exit stream testGabriela Moldovan2026-06-081-1/+0
|/ | | | | This passes now that we can build a `DataStream` without a `ClientDataStreamCtrl`.
* proto: Make TRUNCATE trigger a proto violationGabriela Moldovan2026-05-201-0/+20
|
* proto: Add some tests for DESTROY handlingGabriela Moldovan2026-05-201-1/+60
|
* proto: Make do_create2_handshake() check EXTENDED2 was sentGabriela Moldovan2026-05-201-1/+19
| | | | | | | | | | | | | | 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.
* proto: Extend helper to check that DESTROY was sent in both directionsGabriela Moldovan2026-05-201-7/+21
|
* proto: Rename a test helper and adjust its docsGabriela Moldovan2026-05-201-7/+6
| | | | | | | | 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.
* proto: Return the CircId from test handshake helperGabriela Moldovan2026-05-201-2/+4
| | | | I'll soon need this for a DESTROY test.
* proto: Add test helper for sending AnyChanMsgsGabriela Moldovan2026-05-201-0/+5
|
* proto: Add test ensuring we won't extend to the previous hopGabriela Moldovan2026-04-231-1/+43
|
* proto: Give the ExtendRequestHandler a copy of the inbound peer infoGabriela Moldovan2026-04-231-0/+1
| | | | | This will soon be used for preventing the circuit from being extended to the previous hop (#2415).
* proto: Remove dummy suffixes from variable nameGabriela Moldovan2026-04-201-4/+4
| | | | | | | | 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...