[tor-bugs] #22042 [Core Tor/Tor]: HSFETCH not followed by HS_DESC_CONTENT event

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Apr 24 13:35:33 UTC 2017


#22042: HSFETCH not followed by HS_DESC_CONTENT event
--------------------------+------------------------------------
 Reporter:  nickler       |          Owner:  atagar
     Type:  defect        |         Status:  closed
 Priority:  Medium        |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.2.9.10
 Severity:  Normal        |     Resolution:  not a bug
 Keywords:  tor-hs        |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Changes (by dgoulet):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 This is currently expected behavior and here is why. For every .onion,
 there are 6 HSDirs so after 6 HSFETCH, your client has gone over all 6
 HSDirs for which each of them is put in a "lookup cache" and you won't be
 able to query them again for the same onion address in the next 15
 minutes.

 This is to avoid (maybe buggy) tor client to hammer HSDir for the same
 .onion... Thus, in this case, you can only HSFETCH the onion address after
 15 minutes of wait period. So even waiting 24 hours won't do it here, you
 need to do the HSFETCH again after 15 minutes because the 7th one just
 didn't work in the first place thus no control event.

 We could think of a new control port HS_DESC event that tells you "No more
 HSDir can be used" or something. Let's open a new ticket if we want that.

 Side note: Hammering the HSDirs every 60 seconds is really not a good idea
 overall. It puts load on the network ultimately degrading it.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22042#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list