Opened 6 years ago

Closed 2 years ago

#9119 closed defect (user disappeared)

Bridge reachability detection not reliable

Reported by: hsn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.4.14-alpha
Severity: Normal Keywords: tor-relay, bridge, 025-triaged, tor-bridge, tor-03-unspecified-201612
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I have following bridge configuration

ORPort 443 NoListen
ORPort 10.0.0.7:9443 NoAdvertise

and port forwarding configured at router correctly, i can connect to its public address at port 443 and do sockstat and see that connection is established with 9443 local port.

Tor determines its public IP corectly, but fails to determine reachability.

Your server (A.B.C.D:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ....

Child Tickets

Change History (20)

comment:1 Changed 6 years ago by hsn

I added AssumeReachable 1 to work around problem, checked bridge list and i am listed there.

I checked my bridge with current stable release of TOR browser set to use it and it works correctly.

comment:2 Changed 6 years ago by hsn

I think that reachability detection error is at client side. After getting error message about unreachable ORPort i started arm and see inbound connection from Snafu with lifetime 1.4h but i restarted node again and this time did not reset in arm, so real connection lifetime should be less.

But my point is that even if node successfully does incoming tor handshake with other tor nodes checking reachability, then it fails its reachability check.

Make reachability logic simple. If other node can connect, then node is reachable and publish descriptor to directory.

comment:3 Changed 6 years ago by hsn

I assume that its safe to publish descriptor at first incoming connection from known tor node because directory authorities will recheck node anyway before giving him Running flag.

Currently i see 6 incoming connections and node will still think that its unreachable and do not publish anything.

comment:4 Changed 6 years ago by hsn

If i switch from bridge mode to relay mode then reachability check works.

comment:5 Changed 6 years ago by nickm

Keywords: tor-relay bridge bufferevents added
Milestone: Tor: 0.2.5.x-final

This is apparently with bufferevents.

comment:6 Changed 6 years ago by hsn

I retested it with compilation without bufferevents and it still fails reachability check.

comment:7 Changed 6 years ago by hsn

0.2.3.25 has same problem.

comment:8 Changed 6 years ago by hsn

I did lot of testing and thing which makes it work is switching between bridge and relay mode. If reachability depends on external server connecting in then most likely servers for checking relay reachability are configured differently from servers checking bridges.

comment:9 Changed 5 years ago by cypherpunks

Still not fixed in Tor v0.2.4.21. It is broken only in bridge mode. In relay mode it works fine. I can reproduce this only on some of my bridges. Some works 100%, some fail 100%, and some sometimes works and sometimes not.

comment:10 Changed 5 years ago by nickm

Keywords: bufferevents removed
Summary: Reachability detection not relieableBridge reachability detection not relieable

I don't think we can go with "assume you're reachable if you have any incoming connections", because the reachability test is really checking for two things:

  1. Is the bridge reachable?
  2. Is the bridge reachable at the IP that it thinks is has?

So we're going to need to figure out what's going wrong with the regular reachability detection here. Is anybody else seeing this one? Has anybody managed to reproduce it?

comment:11 Changed 5 years ago by hsn

In my case bridge is sitting behind NATed firewall, but port is correctly forwarded and guessed IP address in reachability checking message is right.

comment:12 Changed 5 years ago by nickm

We're hoping we can reproduce this. Could you paste your whole torrc, in case there's anything else there that's affecting this somehow? (Please remove any sensitive bits as appropriate)

comment:13 Changed 5 years ago by arma

Can you post a debug-level (or at least info-level) log from the bridge? I have a few theories but none of them make sense, and a log might help give me better hints.

comment:14 Changed 5 years ago by nickm

Status: newneeds_information

comment:15 Changed 5 years ago by nickm

Keywords: 025-triaged added

comment:16 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

Putting this in 0.2.???; they should get moved back into a more timed milestone once they're no longer in needs_information.

comment:17 Changed 4 years ago by isis

Cc: isis added
Keywords: tor-bridge added
Summary: Bridge reachability detection not relieableBridge reachability detection not reliable

comment:18 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:19 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:20 Changed 2 years ago by nickm

Resolution: user disappeared
Severity: Normal
Status: needs_informationclosed
Note: See TracTickets for help on using tickets.