[tor-bugs] Re: #1346 [Tor - Tor client]: Reachability Testing passes, yet Relay is marked as down by authorities

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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