Re: [tor-relays] Loss of Guard and HS Dir flags
On 10/18/2021 1:03 AM, Georg Koppen wrote: Eddie: On 10/13/2021 11:29 PM, Eddie wrote: I currently run 3 relays, across different servers and today I noticed that one has now lost it's Guard and HS Dir flags. What's surprising is that this particular relay has the highest Bandwidth and Consensus Weight of all 3 and has not been restarted for over a month. The stats for all 3 can be found with: OhNoAnotherRelay I know that just running the relay is the important part and caring about what flags it has is a side issue, but I'm just interested in seeing why this has happened. Cheers. Now the relay has lost the Long-Lived Circuits flag despite showing an up-time of 34 days. You mean the Stable flag? Seems to be back now at least. I've filed a ticket[1], though, to look a bit closer at what is going on but am not sure how fast we get to that (help is welcomed!). And the Stable flag has gone again. There's something strange going on here. Maybe. :) Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/128 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Overloaded state indicator on relay-search
David Goulet: > On 17 Oct (13:54:22), Arlen Yaroslav via tor-relays wrote: >> Hi, > > Hi Arlen! > >> >> I've done some further analysis on this. The reason my relay is being marked >> as overloaded is because of DNS timeout errors. I had to dive into the >> source code to figure this out. >> >> In dns.c, a libevent DNS_ERR_TIMEOUT is being recorded as an >> OVERLOAD_GENERAL error. Am I correct in saying that a single DNS timeout >> error within a 72-hour period will result in an overloaded state? If so, it >> seems overly-stringent given that there are no options available to tune the >> DNS timeout, max retry etc. parameters. Some lower-specced servers with less >> than optimal access to DNS resolvers will suffer because of this. > > Correct, 1 single DNS timeout will trigger the general overload flag. There > were discussion to make it N% of all request to timeout before we would report > it with a N being around 1% but unfortunately that was never implemented that > way. And so, at the moment, 1 timeout is enough to trigger the problem. > > And I think you are right, we would benefit on raising that threshold big > time. FWIW: that's tracked in https://gitlab.torproject.org/tpo/core/tor/-/issues/40491 We had that on our radar previously but it fell through the cracks. :( Georg OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Bridge Question
Quoting Suspicious Actions (2021-10-17 12:32:51) > On 10/17/21 1:59 AM, Josh Lawson via tor-relays wrote: > > I work for a bank and was informed that when I connect to my employer > > network, it shows I am coming from a Tor IP and sets off an alert that then > > leads to me being on a call with an investigative team for my employers. I > > was running a Tor relay, but had to shut it down because of these alerts. I > > am not thinking of running a bridge instead, but I have a question. Are the > > bridge IP addresses private enough to not likely trigger an alert by bank > > fraud detection software? Please let me know if I am not phrasing this > > well. > > I would like to donate some bandwidth and was thinking maybe running a > > bridge would be less likely to set off alerts. > > The bridge IPs should be private enough. I agree, it should be safe to run a bridge. All the relay IP addresses are publicly available, but bridges are not easy to list. To be fair some entities like China's Great Firewall does manage to get the full list of IP addresses of bridges. But I will assume your employer doesn't have the resources of the GFW just to figure out employees that run bridges. Thanks for helping the tor network. Bridges are very useful, remember to configure it with obfs4 :) -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
