[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #11297 [BridgeDB]: 'No bridges currently available' if you want IPv6



#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs