[tor-relays] What is: Channel padding timeout scheduled
Noticed that one of my relays (OhNoAnotherRelay02) is showing as off-line. Looking at the logs, I see a bunch of these messages: Oct 18 08:39:16.000 [notice] Channel padding timeout scheduled 143041ms in the past. Oct 18 08:39:21.000 [notice] Channel padding timeout scheduled 156925ms in the past. Oct 18 08:39:24.000 [notice] Channel padding timeout scheduled 168712ms in the past. Oct 18 08:39:25.000 [notice] Channel padding timeout scheduled 166895ms in the past. . . . Oct 18 10:18:48.000 [notice] Channel padding timeout scheduled 194581ms in the past. Oct 18 10:35:22.000 [notice] Channel padding timeout scheduled 216311ms in the past. Oct 18 10:35:30.000 [notice] Channel padding timeout scheduled 224267ms in the past. What's the cause of this. I used this downtime as an excuse to do a bunch of upgrades and a re-boot. Cheers. ___ 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
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.
>
> Also, I was wondering why these timeouts were not being recorded in the
> Metrics output. I've done some digging and I believe there is a bug in the
> evdns_callback() function. The rep_hist_note_dns_error() is being called as
> follows:
>
> rep_hist_note_dns_error(type, result);
>
> but I've noticed the 'type' being set to zero whenever libevent returns a
> DNS error which means the correct dns_stats_t structure is never found, as
> zero is outside the expected range of values (DNS_IPv4_A, DNS_PTR,
> DNS_IPv6_). Adding the BUG assertion confirms this.
>
> Please let me know if I should raise this in the bug tracker or if you need
> anything else.
This is an _excellent_ find!
I have opened:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40490
We'll likely attempt to submit a patch to libevent and then fix that in Tor.
Until this is fixed in libevent and the entire network can migrate (which can
be years...), we'll have to live with DNS errors _not_ being per-type on the
MetricsPort likely going from:
tor_relay_exit_dns_error_total{record="A",reason="timeout"} 0
...
to a line without a "record" because we can't tell:
tor_relay_exit_dns_error_total{reason="timeout"} 0
Note that for a successful request that is reason="success", we can tell which
record type but not for errors because of that.
To everyone, expect that API breakage on the MetricsPort for the next 0.4.7.x
version and evidently when the stable comes out.
Big thanks for this find!
Cheers!
David
--
ntAC7gj16wctf1lTaBQoW+wcUkFG+MROtH5KheSa698=
signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] DirectoryAuthority & FallbackDir Only at Startup?
All: Are the DirectoryAuthority & FallbackDir directives only evaluated at startup of a Tor instance? I recently ran into an issue where my Tor Relay Farm went down, due to the manually configured DirectoryAuthority going down and the FallbackDir didn't seem to back it up. I know that the DirectoryAuthority & FallbackDir directives were intended to be used in a private Tor network, but as I'm running a Tor Relay Farm where all Tor Relay Nodes use a cloned .tordb–I need all the Tor Relay Nodes to talk to the same DirectoryAuthority & FallbackDir. Other than the DirectoryAuthority going down and a Medium-Term key update, loadbalancing to a Tor Relay Farm has been working very well for a month or so. Although, the fundamental Tor Relay client-based push reporting vs DirectoryAuthority server-based pull reporting doesn't lend itself well to accurately reporting Tor Metrics for a Tor Relay Farm. The DirectoryAuthority observers the Tor Farm based on the individual Tor Relay Node that last reported, so Tor Metrics are only shown for a single Tor Relay Node; while, in reality the Tor Relay Farm is doing x4 - x5 the reported load. Knowing this, you might reconsider the way metrics are reported in the future to accurately report loadbalanced Tor Relays. As always, thank you for all the work you do. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Loss of Guard and HS Dir flags
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!). > There's something strange going on here. Maybe. :) Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/128 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] Overloaded state indicator on relay-search
Hi, 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. Also, I was wondering why these timeouts were not being recorded in the Metrics output. I've done some digging and I believe there is a bug in the evdns_callback() function. The rep_hist_note_dns_error() is being called as follows: rep_hist_note_dns_error(type, result); but I've noticed the 'type' being set to zero whenever libevent returns a DNS error which means the correct dns_stats_t structure is never found, as zero is outside the expected range of values (DNS_IPv4_A, DNS_PTR, DNS_IPv6_). Adding the BUG assertion confirms this. Please let me know if I should raise this in the bug tracker or if you need anything else. Thanks, Arlen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] help with exit
On 10/16/21 5:56 PM, Bass Down Low via tor-relays wrote: Hi all, I am somewhat new to the project and trying to run a couple exits to help out. I noticed my relay amazinglizard F80494CE5B2441B67431FFA9CCA571D26BC4F6D8 has bee up for 4 days and not turned into an exit yet. I noticed the overload flag is present, does this prefent my relay from becoming an exit? If not, I would appreciate any help you can give. thank you very much ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays You don't allow exiting to 80 and 443, therefore you will not get the exit flag: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2595 Btw, https://metrics.torproject.org/rs.html#search/amazinglizard, remember to keep family correct. ___ 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
The bridge IPs should be private enough. Thanks for your participation! 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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays OpenPGP_0x8CB69B6BD28C3BF7.asc Description: OpenPGP public key 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
