When Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offline
If your Tor client goes offline, it will keep trying to establish circuits, and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2) but we never actually mark down the last few relays, either because we don't have enough left to make a circuit so we don't ever try another TLS connection, or because none of the remaining relays are suitable exit nodes so we can't pick a path that would be a useful circuit so we don't try.
I think we need to catch the case where we failed to pick a path because we don't have enough circuits, and if it case occurs and many of our relays are marked down, we should mark them up.
That will cause us to attempt circuits for a lot longer than currently, but on the other hand Tor will actually work when you come back to the network and try to make a new application request.
[Automatically added by flyspray2trac: Operating System: All]
Activity
changed milestone to %Tor: unspecified
I feel like this means that we should create a different flag variable for clients. The variable is_running in routerinfo_t for example is marked as local only, yet we still appear to updating the routerstatus_t version when we fail to reach a relay as a client. The problem seems to be that router_set_status() sets both versions of the flag.
If we differentiate, we can then safely re-copy all of the consensus versions of is_running over our local versions, as opposed to marking every router as now up.
That sounds great. Let's talk about how best to do this. Immediately, just adding a new flag might do. But in the meantime, I'm planning a related change for microdescriptors, where we stop using routerinfo_t as a repository of local per-router knowledge. What we make a new shiny router_t that tracks the local Tor's knowledge and opinion of each router, and turn all the routerstatus_t in a consensus, and every routerinfo_t, into a nice immutable thing?
-
Ok. This bug is blocking some of my circuit build times and bandwidth weight tests. Can I start out by just moving the mutable version of this flag into routerinfo_t and implementing this reset by copy method in the meantime? I can try to look for any other instances of modification of either routerstatus_t or routerinfo_t and mark them with comments in the branch I do this in.
-
There are a lot of things that touch flags in routerstatus_t and routerinfo_t. If you're going to do this, we should think closely about what the new status is, and how you're going to make sure that everything that currently sets or examines the old flag is changed as needed. Then we should write it in or-dev so that we know what design we're going for.
-
Ok, I meant to simply stop the modification of is_running in routerstatus_t and move those modifications to routerinfo_t. As for when to read which version, I think that Tor should primarily use the routerinfo_t version, except when it detects that it runs out of routers, in which case it should retry every so often by resetting all of the is_running flags to their routerstatus_t consensus versions. I can describe this in more depth on or-dev when I start looking through the code again.
As far as commenting, I was planning on only marking weird modifications of routerstatus_t that I happen to see while making this change. I feel like routerstatus_t is the first thing we should try to make readonly. I don't intend on being exhaustive here, just a 'while I'm at it' kind of thing.
-
Trac:
Description: If your Tor client goes offline, it will keep trying to establish circuits, and as each TLS connection fails, it will mark that relay down.In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2) but we never actually mark down the last few relays, either because we don't have enough left to make a circuit so we don't ever try another TLS connection, or because none of the remaining relays are suitable exit nodes so we can't pick a path that would be a useful circuit so we don't try.
I think we need to catch the case where we failed to pick a path because we don't have enough circuits, and if it case occurs and many of our relays are marked down, we should mark them up.
That will cause us to attempt circuits for a lot longer than currently, but on the other hand Tor will actually work when you come back to the network and try to make a new application request.
[Automatically added by flyspray2trac: Operating System: All]
to
If your Tor client goes offline, it will keep trying to establish circuits, and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2) but we never actually mark down the last few relays, either because we don't have enough left to make a circuit so we don't ever try another TLS connection, or because none of the remaining relays are suitable exit nodes so we can't pick a path that would be a useful circuit so we don't try.
I think we need to catch the case where we failed to pick a path because we don't have enough circuits, and if it case occurs and many of our relays are marked down, we should mark them up.
That will cause us to attempt circuits for a lot longer than currently, but on the other hand Tor will actually work when you come back to the network and try to make a new application request.
[Automatically added by flyspray2trac: Operating System: All]
Owner: N/A to mikeperry
Status: new to assigned
Milestone: N/A to N/A
Keywords: N/A deleted, N/A added 
Triaging: this is an old bug. it requires some finesse to solve right. it's a bug on 0.2.1.x so we don't hurt anything by switching stable to 0.2.2.x. It might be that Nick's refactoring work for microdescriptors (#1757 (moved)) will make #1136 (moved) easier to solve.
I think this bug shouldn't block 0.2.2.x stable.
-
See #675 (moved) for a very related bug. Maybe even the same bug.
#675 (moved) is in 0.2.3.x-final, moving this one there too
Trac:
Milestone: Tor: unspecified to Tor: 0.2.3.x-finalmentioned in issue #16120 (moved)
moved to tpo/core/tor#1136 (closed)
