[tor-bugs] #11297 [BridgeDB]: 'No bridges currently available' if you want IPv6
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Mar 26 06:24:53 UTC 2014
#11297: 'No bridges currently available' if you want IPv6
--------------------------+-----------------
Reporter: mttp | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: BridgeDB | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
--------------------------+-----------------
Comment (by isis):
Replying to [comment:1 mttp]:
You mean it looks like this:
[[Image(https://trac.torproject.org/projects/tor/raw-
attachment/ticket/11297/2014-03-26-061323_1073x698_scrot.png)]]
Because this is what I currently get, no matter where I try it from.
I'm not sure if you saw my IRC messages to you, but for posterity's sake:
{{{
22:37 isis ) mttp: i did see, i have not looked into it yet, but if
too many people
are requesting IPv6, then that is not a bug, that is
the correct
behaviour because it doesn't have enough bridges.
22:38 mikeperry ) how does bridgedb know how many users a bridge can
handle?
22:39 mikeperry ) (or when to stop handing it out)
22:40 isis ) it doesn't, it just knows how big IPv4 and IPv6 address
spaces are, and
it divides known bridges into the subhashrings
uniformly per address space
22:41 isis ) then a subhashring is created with the filters
pertaining to the client's
request (e.g. IPv6 + obfs3, etc.), and the client is
mapped to a position
within this second subhashring
22:43 mikeperry ) so requests may be ending up in a subhashing that is
empty in the first place?
22:44 isis ) if there are not bridges in a mapping close enough to
the client in the
second subhashring, or there are "not enough bridges in
total for that
set of filters" [1] then the client either gets less
bridges than the
normal number handed out... and in the worst case none
at all
22:46 isis ) [1] is a total crap algorithm with hardcoded constants
and no explanation
of why those constants were specifically chosen, nor
why they should be
better than anyone else's favourite integer for
determining the meaning
of "not enough bridges"
22:46 isis ) i believe the random integer in question was a 5
22:46 isis ) it would be funnier if it were a 4
22:47 isis ) or 42 or 23 or something that didn't make sense on a
programming level
but at least made sense on a geek level
22:47 isis ) mikeperry: did that answer your question? :)
22:50 mikeperry ) heh. I am still confused as to why no bridges would
come back. is it
because there are really less than 5 IPv6 bridges in
total?
22:51 mikeperry ) I am now beginning to doubt the entire hash ring idea
as being a sane one,
for sure. I am not sure if that counts as an answer,
but it does make me
feel bad for you for having to deal with it ;)
22:52 oak ) Does that mean that the bridges are distributed
somewhat uniformly over
ipv6 space?
22:52 mikeperry ) it seems like we should not be spreading these things
so thin based on
source IP either, but perhaps by distributor type or
some other property.
22:53 mikeperry ) yeah, that's a big space
22:53 mikeperry ) and also it seems unlikely for it to be common for
censored users to be
able to use an alternate space outside of their region,
where as the
crawlers sure can
22:53 oak ) And, unless it is too different from ipv4, subnets of
ipv6 are not
uniformily used
22:54 oak ) For instance latam almost solely uses ipv4
22:55 oak ) If most of that complaints are coming from a uniform
area, must be that
that area uses ipv6 more than the rest of the world
22:57 isis ) mikeperry: heh, no, there are other hardcoded
constants. somewhere there
is a line in this process of determining which says
"only give the amount
of bridges we're supposed to if there are more than 200
in the second
subhashring"
22:59 isis ) mikeperry:
https://gitweb.torproject.org/user/isis/bridgedb.git/blob/HEAD:/lib/bridgedb/Dist.py#l41
22:59 isis ) s/200/100/
23:01 isis ) and then the 5:
https://gitweb.torproject.org/user/isis/bridgedb.git/blob/HEAD:/lib/bridgedb/Dist.py#l152
23:02 isis ) oak: yes, the IPv6 bridges should be distributed evenly
over all of IPv6
space. :/
23:04 mikeperry ) that first function still shouldn't cause the bridges
left to be 0 by itself
23:05 isis ) mikeperry: yes, the bridges are assigned to their final
ring in roughly the
following order:
(1) to a specific distributor (i.e. email/HTTPS),
(2) by IPv4/6,
(3) by PT, if it's a PT,
(4) by the main(? iirc) IP address of the bridge, i.e.
the IP in the ORPort
torrc line
23:06 isis ) mikeperry: to answer your earlier statement: "but
perhaps by distributor
type or some other property"
23:07 mikeperry ) yeah, I am questioning the utility of step 2 for
anything other than IPv4,
and possibly even for that
23:07 isis ) mikeperry: if you scroll down a bit you will see the
beautiful bits of code
with create the HMAC functions and keys for the
(sub)hashring assignments,
in bridgedb.Dist
23:08 mikeperry ) Ipv4 barely even makes sense for just the HTTPS
distributor, IMO
}}}
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11297#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list