[tor-relays] [SOLVED] published descriptor missing from consensus

[Scott Bennett]

Roger Dingledine <arma at mit.edu> wrote:

     Or at least partially solved, at any rate.  The problem is solved,
but the mystery remains.

> On Sun, Jun 04, 2017 at 07:14:06PM -0500, Scott Bennett wrote:
> >      Which versions are the Running votes coming from versus the non-Running?
>
> You can see the votes at
> https://www.seul.org/~arma/moria1-v3-status-votes
>
> >      I have a few commands in a crontab entry that extract relay IP addresses
> > from the most recently received consensus, sort them, and load them into a
> > table in pf.  They run every 15 minutes.  Anything coming from the addresses
> > in the table is immediately passed.  Anything not passed gets checked against
> > a much larger table of probers, attempted intruders, etc. and is blocked if it
> > matches a table entry.
>
> Well heck. Sounds like we have a winner here.
>
> Turn off your weird censorship infrastructure, confirm that things
> start working after a while, and now you have something to debug. :)
>
     The misuse of the word "censorship" aside, I tried disabling pf and
restarting tor.  To my surprise, the authorities connected to my relay
successfully and distributed its information in subsequent consensuses!
I do not know why, which is the remaining mystery.  However, having to
turn off one's firewall in order to run tor is not a solution to the
problem.
     But, while going back through the logs, I noticed the following among
tor's startup messages.

Jun 05 23:25:46.849 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 100020bf: OpenSSL 1.0.2k  26 Jan 2017; running with 100020cf: OpenSSL 1.0.2l  25 May 2017).
Jun 05 23:25:46.895 [notice] Tor 0.3.0.7 (git-cfd9c1bdc0582656) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2l and Zlib 1.2.8.

The date of 25 May 2017 means that my last run of 0.3.0.6 was using an older
OpenSSL version, but 0.3.0.7 was using the newer one, although it had been
compiled with the earlier version shown in the first message.  I'm not sure
how that might interact badly with pf at all.  However, I rebuilt 0.3.0.7,
stopped the running copy, enabled pf, and restarted tor to run from the
rebuilt version.  Enough authorities must be happy with it because they are
now distributing its information in the consensus and also its most recent
descriptor.
     In summary, the problem is resolved, but the mystery remains unsolved.
What I think I know is that the mismatched openssl stub and library versions
somehow interact with pf and pre-0.3.0.7 tor authorities in some mysterious
manner that causes connections from those authorities to my relay to fail,
but connections from 0.3.0.7 authorities to work just fine.  Having the stub
version and the library version be identical apparently avoids the erroneous
interaction(s).


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************