[tor-relays] published descriptor missing from consensus

[Roger Dingledine]

On Sun, Jun 04, 2017 at 12:30:20AM -0500, Scott Bennett wrote:
>      Late Wednesday afternoon, I restarted my relay (MYCROFTsOtherChild),
> which changed it from 0.3.0.6 to 0.3.0.7.  That was the only change I made.
> It went through a normal startup and published its descriptor.  After a few
> hours, tor noticed that its descriptor was still not in the latest consensus

Interesting mystery! You always have the most exciting mysteries. :)

I just instrumented moria1 to be more detailed on why it doesn't find
each relay reachable, and here's what I found:

Jun 04 18:12:44.147 [info] dirserv_single_reachability_test(): Testing reachability of MYCROFTsOtherChild at 73.246.41.113:32323.
Jun 04 18:13:47.147 [info] connection_handle_write_impl(): in-progress connect to 73.246.41.113:32323 failed. Removing. (Connection timed out)

Jun 04 18:34:04.205 [info] dirserv_single_reachability_test(): Testing reachability of MYCROFTsOtherChild at 73.246.41.113:32323.
Jun 04 18:35:07.205 [info] connection_handle_write_impl(): in-progress connect to 73.246.41.113:32323 failed. Removing. (Connection timed out)

So it would appear that it's trying to make a TCP connection, and
after 63 seconds, it decides it's not going to work.

It would seem that 6 of the 8 directory authorities are not voting the
Running flag, so I guess they are seeing something similar (or would be
if they hacked their logs up to display it).

This is weird, because when I telnet to your IP:port, it connects
easily. And when I set your IP:port as my bridge address, my Tor client
bootstraps fine.

So I am left wondering if there's something different about how Tor
requests that the system launch a TCP connection, or if Comcast or
your system is somehow filtering (or not being able to handle) certain
connection attempts.

--Roger