Opened 7 years ago

Closed 7 years ago

#9633 closed defect (fixed)

Reachability test fails sometimes

Reported by: bastik Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: Tor bridge, Tor Relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Since version 0.2.4.x-alpha (I guess the whole branch up to I saw the reachability test fail on my bridge which, as far as I know, didn't show this message with 0.2.3.x.

I can't reproduce it, but it happened yesterday and the day before that, without me noticing. It runs on Windows, like always and is up part-time. Today it took extremely long (compared to previous times) to validate that it is up.

It happened before and all I did back then was to exit Vidalia (and Tor) and start it again.

Strange enough is that Tor retries the test, but keeps failing if it failed the first one. To what I have experienced it appears that this does not happen in you restart it, though I can't say that for sure.

Another bridge that was set-up during the 0.2.4.x-alpha phase on a Linux server failed this reachability test at least once and all I did was restart the Tor daemon to make the test succeed.

Both bridges are obfsproxy bridges, which are configured like normal bridges with lines for the transport. No NoAdvertise or no NoListen. There's nothing special about them.

Child Tickets

Change History (3)

comment:1 Changed 7 years ago by arma

You're in luck!

This sounds like a duplicate of #9546, yes?

comment:2 in reply to:  1 Changed 7 years ago by bastik

Replying to arma:

You're in luck!

This sounds like a duplicate of #9546, yes?

Maybe, as I understand it it's unrelated from clock-skew, which should not apply to my bridge, because I'm just seeing the symptoms.

I saw #9119, where I assumed it would be the NoAdvertise and/or NoListen stuff, as I read that bridges fail when they set something like this.

I will not change the level of logging. However I'm awaiting binary release of and will keep an closer eye on that one. I'll remember this ticket and either add new information or close it.

comment:3 Changed 7 years ago by bastik

Resolution: fixed
Status: newclosed

Closing as fixed. I'm not running for an extended period of time, but I watched if the Windows machine would pass the test. It's better to close it and re-open if necessary, than to rely on my ming that has to remember to close it.

Note: See TracTickets for help on using tickets.