> On 8 Jun 2017, at 18:44, Scott Bennett <bennett@xxxxxxx> wrote: > > Roger Dingledine <arma@xxxxxxx> 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. 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 ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays