[tor-bugs] #15937 [Tor]: Clients fail on the 7th rapid SOCKS request to the same HS
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Feb 18 00:41:03 UTC 2016
#15937: Clients fail on the 7th rapid SOCKS request to the same HS
----------------------+------------------------------------
Reporter: teor | Owner: dgoulet
Type: defect | Status: reopened
Priority: Low | Milestone: Tor: 0.2.8.x-final
Component: Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs | Actual Points:
Parent ID: | Points: small/medium
Sponsor: SponsorR |
----------------------+------------------------------------
Comment (by teor):
Replying to [comment:12 dgoulet]:
> Hrm ok it's a fun puzzle but I think I figured it out and the solution
could be simple.
>
> In `rend_client_refetch_v2_renddesc()`, at the bottom if the fetch
request fails by not finding a new HSDir because all 6 have been queried
already, we call `rend_client_desc_trynow()` which closes all
`RENDDESC_WAIT` connections for a .onion thus losing all previous 6.
>
> I can't figure out why we do that if we can't find an HSDir... so can we
simply remove this?:
> {{{
> if (ret <= 0) {
> /* Close pending connections on error or if no hsdir can be found.
*/
> rend_client_desc_trynow(rend_query->onion_address);
> }
> }}}
>
> When the fetch succeeds (in `connection_dir_client_reached_eof()`), we
already call that function to move to the next stage for HS connection so
I propose we remove the above.
Makes sense to me, but do we limit the number of pending connections to
one per HSDir?
And do we retry when the connections actually fail?
(I don't know this code very well. I am concerned that we could end up
asking a HSDir multiple times, or end up stalling if the network is slow
when we first try all 6, but speeds up later.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15937#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list