Opened 9 months ago

Last modified 2 months ago

#26542 assigned defect

Distribute IPv6 bridges though bridges.torproject.org

Reported by: teor Owned by:
Priority: High Milestone:
Component: Obfuscation/BridgeDB Version:
Severity: Normal Keywords:
Cc: jan@… Actual Points:
Parent ID: #24264 Points: 3
Reviewer: Sponsor: Sponsor19

Description

A relay operator can't find any IPv6 bridges on bridges.torproject.org:
https://lists.torproject.org/pipermail/tor-relays/2018-June/015512.html

Perhaps this is a bridge authority or BridgeDB issue.

Child Tickets

Change History (9)

comment:1 Changed 3 months ago by teor

As of 19 December 2018, there are still no IPv6 bridges on bridges.torproject.org with PT none or obfs4.

comment:2 Changed 3 months ago by teor

Parent ID: #28888

comment:3 Changed 3 months ago by teor

Parent ID: #28888#24264

We should check this ticket when Serge sets AuthDirHasIPv6Connectivity 1.

comment:4 Changed 3 months ago by darkspirit

Cc: jan@… added

comment:5 Changed 3 months ago by sysrqb

INFO      L81:request.withIPversion()  HTTPS request for bridges with IPv6 addresses.
INFO     L146:request.withPluggableT() HTTPS request for transport type: 'obfs4'
DEBUG     L78:geo.getCountryCode()     Looked up country code: CH                                                                                                                                                  
INFO     L125:request.withoutBlockIn() HTTPS client's bridges also shouldn't be blocked in their GeoIP country code: CH
INFO     L244:bridgerequest.generate() Adding a filter to HTTPSBridgeRequest for ${exit_node_address} for IPv6 obfs4 bridges not blocked in ch...
INFO     L300:distributor.getBridges() Attempting to get bridges for ${exit_node_address}...
DEBUG    L159:distributor.getSubnet()  Client IP was within area: ${exit_node_ip_netblock}
DEBUG     L44:filters.bySubring()      Creating a filter for assigning bridges to subhashring 1-of-3...
DEBUG    L325:distributor.getBridges() Client request within time interval: 1545318000
DEBUG    L326:distributor.getBridges() Assigned client to subhashring 1/3 
DEBUG    L327:distributor.getBridges() Assigned client to subhashring position: ${hash}
DEBUG    L328:distributor.getBridges() Total bridges: 1000
DEBUG    L329:distributor.getBridges() Bridge filters: bySubring1of3 byTransportNotBlockedIn(obfs4,ch,6)
DEBUG    L333:distributor.getBridges() Cache hit frozenset([<function bySubring1of3 at 0x7f50c6784c80>, <function byTransportNotBlockedIn(obfs4,ch,6) at 0x7f50bb0817d0>])
DEBUG    L269:distribute.bridgesPerR() Returning 1 bridges from ring of len: 0
DEBUG    L276:Bridges.filterDistinct() Got 0 possible bridges to filter

Where BridgeDB thinks the source address of the request was in CH.

comment:6 Changed 3 months ago by teor

Serge has enabled IPv6 reachability testing (#24264) and IPv6 bridge addresses appear in metrics (#28888).

But bridges.torproject.org still does not give out IPv6 bridges.

Is the IPv6 GeoIP missing?
Should we wait a few more days?

comment:7 Changed 3 months ago by gman999

Ok. So we can assume the issue is on bridges. and not the bridge dir auth at this point.

I consistently see ~50 IPv6 connections to what I assume are IPv6 bridges on Serge at any moment.

comment:8 Changed 2 months ago by gaba

Owner: isis deleted
Points: 3
Priority: MediumHigh
Sponsor: Sponsor19
Status: newassigned

comment:9 in reply to:  7 Changed 2 months ago by teor

Replying to gman999:

Ok. So we can assume the issue is on bridges. and not the bridge dir auth at this point.

I consistently see ~50 IPv6 connections to what I assume are IPv6 bridges on Serge at any moment.

Relays don't extend via IPv6, so any outbound IPv6 connections you see on an authority are reachability tests.
(We'll need better reporting of IPv6 once we do IPv6 extends, I added #29113 so we remember to add them to the heartbeat.)

Any inbound IPv6 connections you see are from clients using your authority as an entry. (Which should be rare.)

Note: See TracTickets for help on using tickets.