[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] Re: #1346 [Tor - Tor client]: Reachability Testing passes, yet Relay is marked as down by authorities
#1346: Reachability Testing passes, yet Relay is marked as down by authorities
--------------------------------+-------------------------------------------
Reporter: Sebastian | Type: defect
Status: closed | Priority: minor
Milestone: Tor: 0.2.2.x-final | Component: Tor - Tor client
Version: 0.2.2.10-alpha | Resolution: fixed
Keywords: | Parent:
--------------------------------+-------------------------------------------
Changes (by arma):
* status: new => closed
* resolution: None => fixed
Old description:
> We've had reports from many operators of historically stable and well-
> running
> relays that their relays have lately been falling out of the consensus.
> They do
> test reachability successfully for both dirport and orport, and publish a
> descriptor to the authorities, which they acknowledge as valid.
>
> In debugging and testing this more, I looked at
> BarkerJrParis B1BFFE96D67CC1BD7EF6A9D4AC618AF681012A3E 92.243.8.139:21
> Trying to use this relay as a bridge fails, as circuit building times
> out. Using
> openssl s_client -connect 92.243.8.139:21 gives a valid-looking cert,
> though;
> and the connecting Tor doesn't provide any debug log messages that
> would have helped me to track down the cause.
>
> BarkerJR mentioned that this occurred after restarting Tor. A few weeks
> earlier,
> he had updated openssl, but not restarted Tor since then. I have no data
> from the other relay operators on openssl versions, platform, tor version
> etc that they're using, but will try to get them to update the bug report
> here.
>
> My current theory is that something prevents a circuit to be established
> with the relay, after the initial connection is made, and that this
> connection and sending of certs is enough to make reachabilitytesting
> pass, thus confusing the relay into believing that it is in fact
> reachable.
>
> [Automatically added by flyspray2trac: Operating System: All]
New description:
We've had reports from many operators of historically stable and well-
running
relays that their relays have lately been falling out of the consensus.
They do
test reachability successfully for both dirport and orport, and publish a
descriptor to the authorities, which they acknowledge as valid.
In debugging and testing this more, I looked at
BarkerJrParis B1BFFE96D67CC1BD7EF6A9D4AC618AF681012A3E 92.243.8.139:21
Trying to use this relay as a bridge fails, as circuit building times out.
Using
openssl s_client -connect 92.243.8.139:21 gives a valid-looking cert,
though;
and the connecting Tor doesn't provide any debug log messages that
would have helped me to track down the cause.
BarkerJR mentioned that this occurred after restarting Tor. A few weeks
earlier,
he had updated openssl, but not restarted Tor since then. I have no data
from the other relay operators on openssl versions, platform, tor version
etc that they're using, but will try to get them to update the bug report
here.
My current theory is that something prevents a circuit to be established
with the relay, after the initial connection is made, and that this
connection and sending of certs is enough to make reachabilitytesting
pass, thus confusing the relay into believing that it is in fact
reachable.
[Automatically added by flyspray2trac: Operating System: All]
--
Comment:
We still find people running Centos and Tor 0.2.1.19, but at this point
it's pretty rare. I'm going to close this.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1346#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online