__DisablePredictedCircuits causes bootstrap to hang at "Connecting to Tor Network"

changed milestone to %Tor: unspecified

added bootstrap component::core tor/tor milestone::Tor: unspecified points::small priority::low severity::minor sponsor8-maybe status::new tor-hs type::defect labels

A workaround is to set:

LongLivedPorts
PredictedPortsRelevanceTime 0 seconds
LearnCircuitBuildTimeout 0

But there's no option to reduce the number of hidden service server preemptive circuits (see #17360 (moved)).

Hm! I think our definition of 100% bootstrapped is that we made a circuit. Is that so terrible a definition?

What situation is causing us to set DisablePredictedCircuits without a controller generating its own circuits? That is, is this just a pathological config, or is it actually a thing that somebody wants to do?

And lastly, be aware that "80% connecting to tor network" is the initial bootstrap message if you start Tor with enough cached dir info. That is, seeing 80% doesn't mean anything at all in this case about whether the network is plugged in.

Replying to arma:

Hm! I think our definition of 100% bootstrapped is that we made a circuit. Is that so terrible a definition?

It's an excellent definition. But we require 100% bootstrapped to make circuits in some configs, so it's a circular dependency (on hidden/onion services, and without predicted circuits). Perhaps a solution is to make introduction point connections dependent on 80%, not 100%? (This would also fix the scenario where each type of predicted circuit is disabled individually by a specific option.)

What situation is causing us to set DisablePredictedCircuits without a controller generating its own circuits? That is, is this just a pathological config, or is it actually a thing that somebody wants to do?

It's useful for load-balancing hidden/onion service configurations like (Rendezvous) Single Onion Services (RSOS - #17178 (moved), SOS - prop#252), where (almost) every connection is one-hop, and several hundred tor instances might be running. In this case, predicted circuits will never be used (except for descriptor uploads, and not every instance uploads descriptors due to OnionBalance). Predicted circuits represent unnecessary load on the server and network in this case.

And lastly, be aware that "80% connecting to tor network" is the initial bootstrap message if you start Tor with enough cached dir info. That is, seeing 80% doesn't mean anything at all in this case about whether the network is plugged in.

Indeed. I was using chutney on localhost, and it worked without !__DisablePredictedCircuits set, so I know the network was plugged in and chutney was working.

Trac:
Keywords: N/A deleted, tor-hs added

It is impossible that we will fix all 226 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "new" and tickets, looking for things to move to 0.2.9.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

Trac:
Priority: Medium to Low
Points: N/A to small
Reviewer: N/A to N/A

tickets market to be removed from milestone 029

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

This is related to #21073 (moved), where PredictedPortsRelevanceTime 0 eventually causes a tor hidden service to stop updating its descriptor. The root cause is that tor relies on predicted circuits to generate network activity, and network activity causes tor to perform certain actions on a regular basis.

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: tor-hs deleted, tor-hs bootstrap sponsor8-maybe added

#27849 (moved) fixes a similar issue with SOCKSPort 0.

This issue might have caused sbws #28639 (moved), see #28701 (moved).

This issue is related to #28714 (moved), but #28714 (moved) probably won't fix it.

Replying to teor:

A workaround is to set:

LongLivedPorts
PredictedPortsRelevanceTime 0 seconds
LearnCircuitBuildTimeout 0
}}}
But there's no option to reduce the number of hidden service server preemptive circuits (see #17360).

In #17592 (moved) in Tor 0.3.1.1-alpha, we replaced PredictedPortsRelevanceTime and CircuitIdleTimeout with CircuitsAvailableTimeout.

So the current workaround is: {{{ LongLivedPorts LearnCircuitBuildTimeout 0

and

PredictedPortsRelevanceTime 0 seconds

or

CircuitsAvailableTimeout (a small timeout? a large timeout?)


We can't disable predicted ports separately any more, which is annoying.

Replying to teor:

In #17592 (moved) in Tor 0.3.1.1-alpha, we replaced PredictedPortsRelevanceTime and CircuitIdleTimeout with CircuitsAvailableTimeout.

So the current workaround is: {{{ LongLivedPorts LearnCircuitBuildTimeout 0

and

PredictedPortsRelevanceTime 0 seconds

or

CircuitsAvailableTimeout (a small timeout? a large timeout?) }}}

We can't disable predicted ports separately any more, which is annoying.

I'm having this issue with Exitmap and the above workaround do not work :S ...

No circuit activity stalls bootstrap progression basically :(.

Trac:
Description: When __DisablePredictedCircuits is set in the torrc, bootstrap hangs at 80% - "Connecting to Tor Network".

This happens in hidden service configurations, it may happen in other client or server configurations as well.

I think this is because:

no predicted circuits are being built, and therefore
tor never completes an OR connection, and therefore
tor never thinks it has bootstrapped, and therefore
tor doesn't make any of the OR connections it would make as part of its configured function

To fix this, we need to either:

assume tor is connected to the network if it gets to "Connecting to Tor Network" and __DisablePredictedCircuits is set, or
make at least one connection at "Connecting to Tor Network" even if __DisablePredictedCircuits is set

The first risks repeatedly making connections if tor isn't connected to the network, the second risks making connections the user doesn't want.

to

When __DisablePredictedCircuits is set in the torrc, bootstrap hangs at 80% - "Connecting to Tor Network".

This happens in hidden service configurations, it may happen in other client or server configurations as well.

I think this is because:

no predicted circuits are being built, and therefore
tor never completes an OR connection, and therefore
tor never thinks it has bootstrapped, and therefore
tor doesn't make any of the OR connections it would make as part of its configured function

To fix this, we need to either:

assume tor is connected to the network if it gets to "Connecting to Tor Network" and __DisablePredictedCircuits is set, or
make at least one connection at "Connecting to Tor Network" even if __DisablePredictedCircuits is set

The first risks repeatedly making connections if tor isn't connected to the network, the second risks making connections the user doesn't want.

My first thought is that we should distinguish between "predicted" circuits, meaning circuits that are made for the purpose of having extra clean circuits sitting around if we need them, and other kinds of circuits, such as the ones we use to see if we can connect to the network.

And we should do all of the other things that we need circuits for, even if 'predicted' circuits are disabled.

__DisablePredictedCircuits causes bootstrap to hang at "Connecting to Tor Network"

Child items 0

Activity

and

or

and

or