On 8 Jun 2017, at 18:44, Scott Bennett bennett@sdf.org wrote:
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 andrestarting 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.
If your firewall is blocking connections that tor needs to make, turning off that rule is precisely the solution to the problem.
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).
It's possible. But to confirm, you'd need to provide the sections of the firewall log that show what happens when a directory authority tries to check the reachability of your relay.
(As an aside, I'd encourage you not to keep logs at this level on an ongoing basis, they would contain client IP addresses and connection times.)
Or perhaps your firewall collected enough state to want to block tor while it was running, and lost that state when you turned it off and on again.
You have a complex enough system that there are probably more possibilities neither of us have thought of.
I'd keep an eye on things over the next few weeks.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------