-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 08/10/14 02:55, John Brooks wrote:

...

1. Each time the network's enabled, don't try to build

introduction circuits until we've successfully built a circuit. This avoids a problem where we'd try to build introduction circuits immediately, all the circuits would fail, and we'd wait for 5 minutes before trying again.

This sounds like a useful patch. Do you mean that status/circuit-established currently returns true after DisableNetwork is set?

Yup, that's right. So when the network is re-enabled we try building intro circuits straight away, in contrast to startup when we wait for the first circuit to be built.

I suggest submitting that separately from the control changes.

Thanks, I'll do that.

...

2. Added a command to the control protocol to purge any cached

state relating to a specified hidden service. This command can be used before trying to connect to the service to force Tor to download a fresh descriptor. It's a more fine-grained alternative to SIGNAL NEWNYM, which purges all cached descriptors and also discards circuits.

You?ll need to update control-spec. I?m curious what would happen if you use this command on a HSDir or for a local service - those cases need to be defined.

Hmm, good point. The behaviour will be similar to SIGNAL NEWNYM but only affecting a single service. I'll look into the details.

I wonder what problem you?re trying to solve, and if this is the best solution. From a quick reading of the code tor?s behavior is:

1. If an intro point remains, try it 2. If we run out of intro

points, re-fetch the descriptor 3. If we?ve tried fetching the descriptor from all HSDirs within the past 15 minutes, fail 4. If the descriptor is re-fetched, try all intro points again

The list of HSDirs used in the past 15 minutes seems to be cleared when a connection succeeds, when we give up connecting to a service, or on rendezvous failures.

Even if you hit that 15-minute-wait case, it looks like another connection attempt will re-fetch the descriptor and start over. See rendclient.c:1065, leading to purge_hid_serv_from_last_hid_serv_requests. Can you point out where your client gets stalled, or where I?ve read the logic wrong?

I agree with your reading - this change is meant to avoid the first failed connection attempt in cases where we know it's likely to fail.

Another way to approach the problem would be to make the retention time of the HS descriptor cache configurable. Then clients connecting to mobile hidden services could set a shorter retention time than the default. But that would affect all hidden services used by the client. What I'm trying to achieve with this patch is a way of saying "I know this specific descriptor is likely to be out-of-date, don't bother trying it".

Cheers, Michael

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 08/10/14 08:34, grarpamp wrote:

I've added a link to this thread to the below ticket. Somewhere therein I and Qingping were describing need and syntax to flush/fetch hidden service descriptors via control. For which your HS descriptor purge may be a useful component. If it is able to flush both single specified, or all, HS desc's that could be good semantic so as not to disturb other state. Thanks.

# Allow controllers to retrieve HS descriptors from Tor https://trac.torproject.org/projects/tor/ticket/3521

Thanks! The patch only supports purging a single descriptor at present, but it would be easy enough to make the hostname optional and purge all descriptors if it's absent.

Cheers, Michael