| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| | | |
| | |
| | |
| | | |
This re-indents the body of the trapping IEFE.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The comment was entirely wrong. send_control_message returns as soon
as the message has been enqueued. So we actually *need* to wait for
the oneshot.
Also, given that a circuit collapse doesn't give us a real error, we
plumb the error through the oneshot. Introduce an IEFE to capture the
error from the decoding.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
No functional change other than to error cases.
Will fit better with code to come in a moment.
|
| | | |
| | |
| | |
| | | |
We're going to want to reuse this.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Apropose
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228#note_2910588
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With this I see this:
2023-06-09T12:26:27.698815Z DEBUG tor_hsclient::connect: hs conn to duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion: RPT $36acd600bc8ea6c2800434778909ce3d83621358: sending ESTABLISH_RENDEZVOUS
2023-06-09T12:26:27.699144Z TRACE tor_proto::circuit::reactor: Circ 1.0: reactor received SendMsgAndInstallHandler { msg: RelayCell { streamid: StreamId(0), msg: EstablishRendezvous(EstablishRendezvous { cookie: RendCookie(CtByteArray([220, 39, 37, 30, 37, 108, 111, 23, 127, 220, 50, 108, 161, 109, 229, 235, 110, 88, 233, 38])) }) }, sender: Sender { complete: false } }
2023-06-09T12:26:27.699238Z TRACE tor_guardmgr: Received report of guard status guard_id=FirstHopId(Guard(Default, GuardId(RelayIds { ed_identity: Some(Ed25519Identity { 6lORxW93KRbhHFPNG0g+oBkXZbRnpwBzyfDcta7ed/M }), rsa_identity: Some(RsaIdentity { $f0c9c07d1b7c6fc8547f52cac1015b4a79e2ac1a }) }))) status=Success
2023-06-09T12:26:27.699429Z TRACE tor_hsclient::connect: SEND CONTROL MESSAGE RETURNED
2023-06-09T12:26:27.699966Z INFO tor_guardmgr::guard: We have found that guard [scrubbed] is usable.
2023-06-09T12:26:27.700030Z TRACE tor_guardmgr::guard: Guard status changed. guard_id=GuardId(RelayIds { ed_identity: Some(Ed25519Identity { 6lORxW93KRbhHFPNG0g+oBkXZbRnpwBzyfDcta7ed/M }), rsa_identity: Some(RsaIdentity { $f0c9c07d1b7c6fc8547f52cac1015b4a79e2ac1a }) }) old=Untried new=Reachable
2023-06-09T12:26:27.700607Z TRACE tor_guardmgr: Known usability status guard_id=FirstHopId(Guard(Default, GuardId(RelayIds { ed_identity: Some(Ed25519Identity { 6lORxW93KRbhHFPNG0g+oBkXZbRnpwBzyfDcta7ed/M }), rsa_identity: Some(RsaIdentity { $f0c9c07d1b7c6fc8547f52cac1015b4a79e2ac1a }) }))) usable=true
2023-06-09T12:26:27.701481Z DEBUG arti_client::status: 45%: connecting successfully; directory is fetching authority certificates (8/8)
2023-06-09T12:26:27.765193Z TRACE tor_proto::circuit::reactor: Circ 1.0: handling cell: Relay(Relay { body: .. })
2023-06-09T12:26:27.765284Z TRACE tor_proto::circuit::reactor: Circ 1.0: Received meta-cell UnparsedRelayCell { body: [39, 0, 0, 0 [[[ eldied -iwj ]]]] }
2023-06-09T12:26:27.765352Z TRACE tor_hsclient::connect: SENDING VIA ONESHOT
2023-06-09T12:26:27.765363Z TRACE tor_hsclient::connect: SENDING VIA ONESHOT DONE
2023-06-09T12:26:27.765367Z TRACE tor_proto::circuit::reactor: Circ 1.0: meta handler completed with result: Ok(UninstallHandler)
2023-06-09T12:26:29.588045Z DEBUG tor_hsclient::connect: hs conn to duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion: attempt failed: error: internal error (bug) at /volatile/rustcargo/Rustup/Arti/arti/crates/tor-hsclient/src/connect.rs:725:28: RENDEZVOUS_ESTABLISHED not sent yet
This seems to suggest that send_control_message is returning sooner
than expected.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Just like for Sensitive.
|
| | | |
| | |
| | |
| | | |
Without this, the printed errors are very bland.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bugfix, without which this code wouldn't work.
Reported in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228#note_2910293
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228#note_2910286
Not thinking about this right now, but it seems like a reasonable
suggestion.
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228#note_2910284
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Be more specific about precisely what it's the context for, and its
lifetime.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Remove TODO comment; instead, replace with a comment about future use
for HS server side, inspired by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228/diffs?commit_id=ecfd39507c4e8d52788f4599d6275cab3b4a2a5f#c0123bb2f6b9a9ca50fa45886b667580a7dc951e_79_82
Do not implment `tor_error::HasKind`; the true kind depends on where
the bad information came from, which the calling code will understand.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228/diffs?commit_id=d63ad3ab041460bf85defb99b31d6ebe075a0eb1#c0123bb2f6b9a9ca50fa45886b667580a7dc951e_101_110
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We were able to get as far as we have, merely because all the new code
uses just Arc<ClientCirc> rather than the mockable version.
We want to change that, so we need to mock this function too.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This is the data structure for recording IPT outcomes and, later,
selecting a good IPT to try for a new connection.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This contains code to:
* Iterate over introduction points
* Make multiple attempts to connect
* Apply timeouts to the various phases of each attempt
* Establish a rendezvous point
* Represent errors that occur during the above
It provides places to add:
* Implementation of the INTRODUCE1/INTRODUCE_ACK handshake
* Reception of RENDEZVOUS2 and actual end-to-end circuit establishment
* Recording of the outcome of connection attempts via particular IPTs
* Using previous IPT outcome information for selecting IPTs to try
* Tests of the new code (although more mocking will probably be needed)
Much of this code works with a fixed type ClientCirc rather than going via
the Mockable traits. That is wrong, and it will be fixed later.
|
| | | |
| | |
| | |
| | |
| | | |
We're going to use this for rendezvous completion timeout, which could
be due to basically anything.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
We're going to want to report about rendezvous points in errors.
We'll do this by printing the "number" of the intro point in the descriptor.
|
| | | |
| | |
| | |
| | |
| | | |
We're going to want to report about rendezvous points in errors.
We'll be using this. And we'll want to convert it from a Relay.
|
| | | |
| | |
| | |
| | | |
The dead code warnings are a nuisance while this file is half-written.
|
| | | |
| | |
| | |
| | | |
This has the wrong return type at the moment.
|
| | | |
| | |
| | |
| | | |
The impl was in terms of itself. Sadly, nothing warns about this bug.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This basically always means we couldn't cope with the descriptor.
We need to extend the description of OnionServiceDescriptorValidationFailed
|
| | | |
| | |
| | |
| | |
| | | |
This factors out an ad-hoc AsRef impl. We're going to want to reuse
this for another error type.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
It returns a borrow (so whatever is passed remains borrowed) and the
next phase is going to need to perhaps mutate other parts of data, so
we must pass only what is needed.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Now Context can be usefully shared, across different
threads/tasks/functions, so long as only one of them needs to modify
`Data`.
|
| | | |
| | |
| | |
| | | |
It's going to appear in our public errors.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Expand arti-client docs to include error reporting section
See merge request tpo/core/arti!1213
|