- tor-relays - lists.torproject.org

Re: [tor-relays] Previous Guard not getting Guard flag back
by starlight.2017q4＠binnacle.cx 23 Mar '18

23 Mar '18

>While I understand that my relay lost the guard flag because of a weekend >of downtime, I would expect that it would get it back after a while of >stable again? Anyone able to shed some light on when it will get the flag >back? >https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC… Guard flag calculation is somewhat involved (due to several get-out-jail promotions/bypasses), but the essential part is weighted uptime in excess of the median uptime of guard candidates, or 98% whichever is lower. Presently the authorities have it somewhere around 96% (they do not publish the value). Your relay is at about 91% and will be back as a Guard in less than five days when it will hit 97%. The attached XLS shows it roughly, left side today and right side as-of 3/26. Uptime data came from the "1_month" section of https://onionoo.torproject.org/uptime?search=NSDFreedom Built this sheet for myself recently and simply stuffed in data for your relay. Enjoy. P.S. If anyone spots flaws in the approach, please comment.

1 5

tor-instance-create vs. /etc/tor/torrc
by Igor Mitrofanov 22 Mar '18

22 Mar '18

Hi, I use tor-instance-create to spawn a number of relay instances. However, there seems to be one extra instance running - the default one that reads /etc/tor/torrc (and not /etc/tor/instances/INSTANCE/torrc). How do I disable that default tor relay? It opens port 9050 and does who else knows what by default. I can delete /etc/tor/torrc and it seems to do the trick, however, I am not sure how permanent this change will be with automatic package updates. Thanks!

4 3

exit operators: DNS failure rate increased - please check your DNS
by nusenu 22 Mar '18

22 Mar '18

Dear Exit relay operators, first of all thanks for running exit relays! One of the crucial service that you provide in addition to forwarding TCP streams is DNS resolution for tor clients. Exits relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase again and would like to urge you to visit Arthur's "Tor Exit DNS Timeouts" page that shows you the DNS error rate for exit relays: https://arthuredelstein.net/exits/ (the page is usually updated once a day) Please consider checking your DNS if your exit consistently shows a high (>=20%) timeout rate - and make sure you run an up to date tor version. If you are an exit operator but have no (or no working) ContactInfo, please consider updating that field in your torrc so we can reach you if something is wrong with your relay. thanks for caring, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 1

Previous Guard not getting Guard flag back
by Matthew Glennon 21 Mar '18

21 Mar '18

While I understand that my relay lost the guard flag because of a weekend of downtime, I would expect that it would get it back after a while of stable again? Anyone able to shed some light on when it will get the flag back? https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC… Thanks -- Matthew Glennon matthew(a)glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane

2 3

Hidden service error in log
by Gary 20 Mar '18

20 Mar '18

Hello. I made a "hello world" hidden service and I had to following message in the logs about exceeding launch limit. I have not seen this before. I had one onion for a while and added a second one recently - not sure if that matters as it is only complaining about the first one. I am not sure what / why it is exceeding launch limit, I would be grateful if someone could explain it to me. Thanks. Mar 14 12:43:24.000 [notice] Bootstrapped 100%: Done Mar 14 12:43:32.000 [warn] Hidden service 4l53ozkhv******* exceeded launch limit with 10 intro points in the last 202 seconds. Intro circuit launches are limited to 10 per 300 seconds. Mar 14 12:43:32.000 [warn] Service configured in "/var/lib/tor/hidden_service/": Mar 14 12:43:32.000 [warn] Intro point 0 at [scrubbed]: circuit is open Mar 14 12:43:32.000 [warn] Intro point 1 at [scrubbed]: circuit is open Mar 14 12:43:32.000 [warn] Intro point 2 at [scrubbed]: circuit is doing handshakes Mar 14 12:43:32.000 [warn] Intro point 3 at [scrubbed]: circuit is open Mar 14 12:43:32.000 [warn] Service configured in "/var/lib/tor/hidden2/": Mar 14 12:43:32.000 [warn] Intro point 0 at [scrubbed]: circuit is doing handshakes Mar 14 12:43:32.000 [warn] Intro point 1 at [scrubbed]: circuit is open Mar 14 12:43:32.000 [warn] Intro point 2 at [scrubbed]: circuit is open Mar 14 12:43:32.000 [warn] Intro point 3 at [scrubbed]: circuit is open Mar 14 12:44:25.000 [notice] Performing bandwidth self-test...done.

3 3

Atlas Country Flag
by Anders Burmeister 20 Mar '18

20 Mar '18

Gentlemen How come, after update to latest tor version. the small flags at Atlas start to behave abnormal? The case is, I have 6 relays: 2 France 1 Canada 1 Polen 1 Germany 1 UK The one in Canada and the two in France shows the correct Country Flag. But Germany, Polen and UK shows the France Flag. Should I take it personally, or just be patient and drink more coffee? Best regards Anders Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 5

(no subject)
by Pat Cun 18 Mar '18

18 Mar '18

1

1 0

(no subject)
by wodencafe 18 Mar '18

18 Mar '18

hi Tor https://goo.gl/WCKrme wodencafe

1 0

stem library: huge difference between resolvers "proc" and others, eg. "netstat"
by Toralf Förster 17 Mar '18

17 Mar '18

I do wonder about the differences of "proc" versus the other 3 ("netstat, "lsof" and "ss") related to the Inbound/Outbound values at my Tor relay. As an example I copied below the output of "proc" and "netstat". Does anybody have a clue about those differences? mr-fox ~ # python ~/stem/docs/_static/example/relay_connections.py --ctrlport 9051 --resolver proc 0.3.4.0-alpha-dev uptime: 06:48:29 flags: Exit, Fast, Guard, Running, Stable, V2Dir, Valid +------------------------------+------+------+ | Type | IPv4 | IPv6 | +------------------------------+------+------+ | Inbound to our ORPort | 2107 | 6 | | Inbound to our DirPort | 15 | 0 | | Outbound to a relay | 1753 | 0 | | Outbound exit traffic | 155 | 302 | | Outbound uncategorized | 119 | 0 | +------------------------------+------+------+ | Total | 4149 | 308 | +------------------------------+------+------+ +------------------------------+------+------+ | Exit Port | IPv4 | IPv6 | +------------------------------+------+------+ | 80 (HTTP) | 111 | 61 | | 143 (IMAP) | 1 | 0 | | 443 (HTTPS) | 0 | 229 | | 465 (SMTP) | 1 | 0 | | 993 (IMAPS) | 13 | 0 | | 5222 (Jabber) | 8 | 2 | | 5223 (Jabber) | 6 | 0 | | 7777 | 1 | 0 | | 8080 (HTTP Proxy) | 4 | 4 | | 8333 (Bitcoin) | 2 | 2 | | 8888 (NewsEDGE) | 2 | 0 | | 50002 (Electrum Bitcoin SSL) | 6 | 4 | +------------------------------+------+------+ | Total | 155 | 302 | +------------------------------+------+------+ mr-fox ~ # python ~/stem/docs/_static/example/relay_connections.py --ctrlport 9051 --resolver netstat 0.3.4.0-alpha-dev uptime: 06:48:41 flags: Exit, Fast, Guard, Running, Stable, V2Dir, Valid +------------------------------+------+------+ | Type | IPv4 | IPv6 | +------------------------------+------+------+ | Inbound to our ORPort | 4883 | 6 | | Inbound to our DirPort | 35 | 0 | | Inbound to our ControlPort | 1 | 0 | | Outbound to a relay | 4174 | 0 | | Outbound exit traffic | 390 | 293 | | Outbound uncategorized | 267 | 0 | +------------------------------+------+------+ | Total | 9750 | 299 | +------------------------------+------+------+ +------------------------------+------+------+ | Exit Port | IPv4 | IPv6 | +------------------------------+------+------+ | 80 (HTTP) | 300 | 68 | | 110 (POP3) | 1 | 0 | | 143 (IMAP) | 4 | 0 | | 443 (HTTPS) | 0 | 214 | | 465 (SMTP) | 1 | 0 | | 1883 | 1 | 0 | | 3128 (SQUID) | 1 | 0 | | 5222 (Jabber) | 21 | 2 | | 5223 (Jabber) | 18 | 0 | | 6667 (IRC) | 4 | 0 | | 7777 | 2 | 0 | | 8080 (HTTP Proxy) | 14 | 3 | | 8333 (Bitcoin) | 8 | 2 | | 8888 (NewsEDGE) | 3 | 0 | | 50002 (Electrum Bitcoin SSL) | 12 | 4 | +------------------------------+------+------+ | Total | 390 | 293 | +------------------------------+------+------+ -- Toralf PGP C4EACDDE 0076E94E

2 4

hourly CPU spike at <hour>:02
by Toralf Förster 17 Mar '18

17 Mar '18

caused by both of the 2 Tor exits here at a Linux server. I do wonder what both processes do exactly 2 minutaes past each hour for about half a minute? -- Toralf PGP C4EACDDE 0076E94E

2 2