Opened 11 years ago

Last modified 7 years ago

#767 closed defect (Fixed)

Rendezvous Descriptor Upload Failures

Reported by: karsten Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: karsten, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Roger Dingledine wrote on June 20, 2008:

It looks like hid_serv_get_responsible_directories() looks at
routerstatus entries, but ignores whether we actually have descriptors.
So if I don't have the descriptor it chooses, I end up with this in my

Jun 19 19:21:22.045 [warn] Requested exit point

'$68333D0761BCF397A587A0C0B963E4A9E99EC4D3' is not known. Closing.

Jun 19 19:21:22.045 [warn] Making tunnel to dirserver failed.

Right, that's the same bug that is described in the NLnet mid-June report:

"Descriptor Upload Failures: The current logic to upload rendezvous service
descriptors does not handle failures in a reasonable way. In case of a
failure, Tor waits for a solid hour before making the next attempt. There
should either be a smaller timeout or an individual handling of failures
per directory."

In the mid-June measurements and when using v0 rendezvous descriptors this
bug affected 481 of 3270 cases (14.7 %); only in very few cases it affected
all three hidden service authorities and became visible, because clients
couldn't access the hidden service. In my yesterday evaluations with v2
rendezvous descriptors, this bug occurred in 1298 out of 9460 attempts
(13.7 %). This means we really need to fix this bug to increase

The fix you suggested above only avoids those nasty warnings and
unnecessary upload attempts, but it doesn't help to maintain rendezvous
descriptor availability.

My first idea was to put all upload attempts that cannot be performed due
to missing router descriptors in a queue. As soon as new router descriptors
arrive, this queue should be checked, and rendezvous descriptors be

However, this idea does not work. Tor doesn't seem to make any attempts to
download missing router descriptors when it thinks it has enough (I'm not
so sure about its behavior, could you confirm?). In one test case a Tor
providing a hidden service failed to upload v0 rendezvous descriptors to
the three hidden service authorities for more than two hours.

So, my second idea was to request router descriptors as soon as we realize
that we need them and implement the queuing idea, so that a second attempt
will be performed as soon as router descriptors have arrived.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (3)

comment:1 Changed 11 years ago by karsten

Some progress on the fix of this nasty bug. We already knew that when
uploading or fetching a rendezvous service descriptor, Tor requires the
router descriptor of the hidden service directory to extend a circuit to.

Last month Nick told me that Tor downloads *all* router descriptors that it
thinks are useful, so that my second idea to download router descriptors on
demand makes no sense any more. There must be a bug that prevents Tor from
downloading specific router descriptors, as they are apparently not
available (even after an hour or more).

Today I tracked this bug down! When Tor fails to extend a circuit to a
router for which it has *not* yet downloaded the router descriptor, it
marks the router as down in the local network status. The effect is that no
attempt will be made to download the router descriptor in the future
(probably unless the next consensus is downloaded that marks the router as
up again).

The fix to this bug is to refrain from marking a router as down when an
extend operation fails due to absence of the router descriptor.

(My first idea of queueing failed upload attempts becomes valid again and
should be implemented, too, in addition to fixing this bug.)

comment:2 Changed 11 years ago by karsten

flyspray2trac: bug closed.
Fixed in r16808, r16810, r16817, r16818.

comment:3 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.