Roger Dingledine arma@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 addressesfrom 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 * **********************************************************************