[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #15937 [Tor]: Clients fail on the 7th rapid SOCKS request to the same HS
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs