Opened 5 years ago

Closed 5 years ago

#11297 closed defect (not a bug)

'No bridges currently available' if you want IPv6

Reported by: mttp Owned by: isis
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords:
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Requesting IPv6 bridges over the web interface returns the error message in the title and no bridges. I've reproduced this over several days from different parts of the internet, and it has been reported to the help desk.

Child Tickets

Attachments (1)

2014-03-26-061323_1073x698_scrot.png (69.8 KB) - added by isis 5 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 5 years ago by mttp

Cc: isis added

Changed 5 years ago by isis

comment:2 in reply to:  1 Changed 5 years ago by isis

Replying to mttp:

You mean it looks like this:
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. And that is normal behaviour, that means it doesn't have enough IPv6 bridges to give you some. I'm not sure if you saw my IRC messages to you which explain the process of this behaviour, 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
Last edited 5 years ago by isis (previous) (diff)

comment:3 Changed 5 years ago by isis

Owner: set to isis
Status: newassigned

comment:4 Changed 5 years ago by isis

Resolution: not a bug
Status: assignedclosed
Note: See TracTickets for help on using tickets.