[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18929 [Core Tor/Tor]: Fix selection of directories with non-preferred address families
#18929: Fix selection of directories with non-preferred address families
-------------------------------------------------+-------------------------
Reporter: teor | Owner:
Type: defect | Status:
Priority: Medium | needs_review
Component: Core Tor/Tor | Milestone: Tor:
Severity: Normal | 0.2.8.x-final
Keywords: must-fix-before-028-rc, | Version: Tor:
TorCoreTeam201605 | 0.2.8.1-alpha
Parent ID: #18483 | Resolution:
Reviewer: isis,nickm | Actual Points: 2 hours
| Points: small
| Sponsor:
-------------------------------------------------+-------------------------
Old description:
> In #17840 in 0.2.8.1-alpha, we sometimes fail to fall back to directories
> with addresses in non-preferred IP families:
> * we didn't identify relays that we could fall back to correctly;
> * we incorrectly assumed that every node would have an IPv4 address -
> this doesn't apply to bridges;
> * we counted relays when we had already fallen back to non-preferred
> addresses.
>
> This likely affected bridge clients with IPv4 bridges, and clients in
> small networks.
New description:
In #17840 in 0.2.8.1-alpha, we sometimes fail to fall back to directories
with addresses in non-preferred IP families:
* we didn't identify relays that we could fall back to correctly;
* we incorrectly assumed that every node would have an IPv4 address~~ -
this doesn't apply to bridges~~;
* we counted relays when we had already fallen back to non-preferred
addresses.
This likely affected ~~bridge clients with IPv4 bridges, and~~ clients in
small networks.
--
Comment (by teor):
Wow, you're right, let's do it the simple way - delete the bad check:
bug18929-v3
(I thought I was saving client speed at the cost of complexity. For most
clients, this would have imposed more checks on every directory for no
benefit, and for clients where it mattered, I didn't have actual
performance figures.)
I will need to rebuild a simpler #18483 branch now there's no dependency
between them.
For the record:
> NM2 For router_has_non_preferred_address_node -- an unlisted bridge has
a node_t, but does not have a routerstatus. Can this function ever get
called on a bridge? Do we care?
This function never gets called on a bridge, as
directory_get_from_dirserver handles bridges.
So this bug never affected bridges or bridge clients, sorry, isis!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18929#comment:12>
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