[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information
#25347: Tor stops building circuits, and doesn't start when it has enough directory
information
-------------------------------------------------+-------------------------
Reporter: teor | Owner: asn
Type: defect | Status:
| needs_review
Priority: Medium | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.3.0.6
Severity: Normal | Resolution:
Keywords: 031-backport, 032-backport, | Actual Points:
033-must, tor-guard, tor-client, tbb- |
usability-website, tbb-needs, |
033-triage-20180320, 033-included-20180320 |
Parent ID: #21969 | Points: 1
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by arma):
Five thoughts:
(A) if I were designing that patch, I would put the "if
circuit_get_cpath_opened_len is 0" clause up in
command_process_destroy_cell(), and then rename the function to the more
certain entry_guard_sent_destroy_cell(), or maybe something like
entry_guard_responded_with_destroy_cell(). That way the function is clear
what it's doing, and it's clear how you're deciding whether to call it,
and those are kept separate.
(B) Note that in the ddos mitigation stuff, we refuse circuits from
overloaders with reason resource-limit (see DOS_CC_DEFENSE_REFUSE_CELL).
And at least at the time, the goal was to soak up their overload circuits
at the guard level, i.e. keep them occupied at a point where we're able to
limit the damage they do. If we implement this ticket, overloader clients
will immediately skip off to hassle some other guard. Maybe that's ok? Or
maybe it would be a sad side effect? Maybe we should change the ddos
mitigation to use some other destroy reason, so we don't trigger
overloaders to move? I'm not sure what's best, but let's intentionally
choose something.
(C) I think you're right that END_CIRC_REASON_HIBERNATING is a good reason
to include if we're doing this ticket.
(D) You're fine with circuit_get_cpath_opened_len here, but for your
future knowledge: I believe clients only get a destroy cell from the guard
when the guard has failed to establish the first hop. If the circuit fails
after the guard, clients get a relay truncated cell back. That is,
destroys currently don't chain back to the client -- if the guard gets a
destroy from the middle relay, it keeps the circuit open at itself, and
converts the destroy into a truncated cell to send back. In theory this
design is to allow clients to say "well ok, how about extending to this
other relay then", but in practice clients just say "well screw that,
here's a destroy" and start over.
(E) For the advanced challenge mode of the game: I wonder if it would be
useful to distinguish between preemptive circuits that we tried to make,
where it's actually fine if we don't have them quite yet, vs reactive
circuits that we tried to make because we have some user request that
we're trying to handle right now. In the latter case we would want to try
another guard because we need things to work. But in the former case I
could imagine waiting for a second or two and *not* falling back to a
different guard immediately.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25347#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs