Bridge reachability detection not reliable

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, ....

Trac:
Username: hsn

changed milestone to %Tor: unspecified

added 025-triaged bridge component::core tor/tor milestone::Tor: unspecified priority::medium reporter::hsn resolution::user disappeared severity::normal status::closed tor-03-unspecified-201612 tor-bridge tor-relay type::defect version::tor 0.2.4.14-alpha labels

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.

Trac:
Username: 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.

Trac:
Username: 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.

Trac:
Username: hsn

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

Trac:
Username: hsn

This is apparently with bufferevents.

Trac:
Keywords: N/A deleted, tor-relay bridge bufferevents added
Milestone: N/A to Tor: 0.2.5.x-final

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

Trac:
Username: hsn

0.2.3.25 has same problem.

Trac:
Username: 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.

Trac:
Username: hsn

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.

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?

Trac:
Summary: Reachability detection not relieable to Bridge reachability detection not relieable
Keywords: tor-relay bridge bufferevents deleted, tor-relay bridge added

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

Trac:
Username: hsn

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)

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.

Trac:
Status: new to needs_information

Trac:
Keywords: tor-relay bridge deleted, tor-relay bridge 025-triaged added

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

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.???

Trac:
Summary: Bridge reachability detection not relieable to Bridge reachability detection not reliable
Keywords: tor-relay bridge 025-triaged deleted, tor-relay bridge 025-triaged tor-bridge added
Sponsor: N/A to N/A
Cc: N/A to isis

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Keywords: tor-relay bridge 025-triaged tor-bridge deleted, bridge, tor-relay, tor-bridge, tor-03-unspecified-201612, 025-triaged added
Milestone: Tor: 0.3.??? to Tor: unspecified

Trac:
Status: needs_information to closed
Severity: N/A to Normal
Resolution: N/A to user disappeared
Reviewer: N/A to N/A

closed

mentioned in issue #9633 (moved)

moved to tpo/core/tor#9119 (closed)