[tor-relays] Alleged Family Members / Stable flag "issues"
Hi all, For a little short of a year I'm running Relay SJC01 (328E54981C6DDD7D89B89E418724A4A7881E3192), there was some unnoticed outage of the relay which caused a couple days of downtime. This was at the end of Nov, oddly enough I don't seem to get back the "Stable" flag. In searches I found some conflicting answers, it's either 7 days of uptime, a median of seven days of the entire uptime and/or the advice to check https://consensus-health.torproject.org/consensus-health-2017-12-14-18-00.html#328E54981C6DDD7D89B89E418724A4A7881E3192 What I don't understand is the differences in the output of the concensus: - The concensus nodes that don't have IPv6 (assumed from "KnownFlags" from top of page. (longclaw, dizum, moria1 and faravahar) list my relay with Stable/Guard. - The concensus nodes that do assign the "ReachableIPv6" flag, don't have my relay listed with those flags. To test the IPv6 function, I took an VM outside of my network and ran Tor with "UseBridges" only allowing via iptables IPv6 out to my relay as entry node, and it the relay is/was functioning on IPv6. Now happy to wait an other week/month etc for the stable flag. It doesn't add value to me, but I'm more curious why the flag doesn't return. The same with the Alleged Family Member, I had an relay / exit with a reduced exit policy ($F8333E028E952840C1B93DAEE20880F75B90A68A) but that has been gone for quite some weeks (months) as it was taken down by the hoster. Now all info I can find is that when the relay doesn't announce this anymore one can expect it to be gone after some days/weeks. But in this case it's not going away. If there are actions on my side happy to take them, but I can't find the "right thing" to do here. Thanks! -- Yours Sincerely / Met Vriendelijke groet, Stijn Jonker signature.asc 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] Alleged Family Members / Stable flag "issues"
Hi Tor, On 14 Dec 2017, at 21:37, tor wrote: The same with the Alleged Family Member, I had an relay / exit with a reduced exit policy ($F8333E028E952840C1B93DAEE20880F75B90A68A) but that has been gone for quite some weeks (months) as it was taken down by the hoster. Now all info I can find is that when the relay doesn't announce this anymore one can expect it to be gone after some days/weeks. F8333E028E952840C1B93DAEE20880F75B90A68A does seem to be gone from Atlas when searching for it directly. Have you removed the reference to it from the MyFamily line of the relay that's still up? Yes this entry is gone, shortly (believe 1 day) after the node was taken down. Maybe it's due to the fact I comments the MyFamily config option out, I'll put it back, just referencing itself. Maybe that will clear things out. Again not a major issue in my view, but it kind of feels like stale data somewhere. If it's not on my side then I'm sure it will correct at some point in time. thx, Stijn -- Yours Sincerely / Met Vriendelijke groet, Stijn Jonker sjcjon...@sjc.nl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Alleged Family Members / Stable flag "issues"
Hi Teor, Thanks for responding: On 14 Dec 2017, at 22:56, teor wrote: > On 15 Dec 2017, at 06:38, Stijn Jonker wrote: For a little short of a year I'm running Relay SJC01 (328E54981C6DDD7D89B89E418724A4A7881E3192), there was some unnoticed outage of the relay which caused a couple days of downtime. This was at the end of Nov, oddly enough I don't seem to get back the "Stable" flag. In searches I found some conflicting answers, it's either 7 days of uptime, a median of seven days of the entire uptime and/or the advice to check https://consensus-health.torproject.org/consensus-health-2017-12-14-18-00.html#328E54981C6DDD7D89B89E418724A4A7881E3192 The exact figure depends on each authority and its history of your relay's stability. And how that stability compares to all other relays it has measured. What I don't understand is the differences in the output of the concensus: - The concensus nodes that don't have IPv6 (assumed from "KnownFlags" from top of page. (longclaw, dizum, moria1 and faravahar) list my relay with Stable/Guard. - The concensus nodes that do assign the "ReachableIPv6" flag, don't have my relay listed with those flags. Does your relay have a stable IPv6 connection? Was it down over IPv6 at some point in the past? The IPv6 connectivity is not less stable then the IPv4. The IPv6 is native, and used in day-2-day usage as well. Also smokeping/Nagios (ran via an other device, but same uplink) don't report any differences in connectivity (or the lack thereof). Alternately, the authorities that measure IPv6 may see the entire set of relays as being less stable. (I can't imagine how they would see them as more stable.) But if this were the case, they would be more likely to give the flag. To test the IPv6 function, I took an VM outside of my network and ran Tor with "UseBridges" only allowing via iptables IPv6 out to my relay as entry node, and it the relay is/was functioning on IPv6. How often does your IPv6 go down? On average, I would say one or two hours a month. Now happy to wait an other week/month etc for the stable flag. It doesn't add value to me, but I'm more curious why the flag doesn't return. Please wait a few more days. :-) I'll wait thanks for the response. Stijn -- Yours Sincerely / Met Vriendelijke groet, Stijn Jonker sjcjon...@sjc.nl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] botnet? abusing/attacking guard nodes
On 20 Dec 2017, at 16:39, x9p wrote: On Wed, December 20, 2017 12:10 pm, Santiago wrote: ... My relay B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 is not currently tagged as Guard, and I am seeing more than twenty IPv4s with more than 10 connections, and one with 147. Should that be considered normal for a non-guard relay? 147 is a bit high for a non-exit, non-guard, for a single IP. check https://atlas.torproject.org/ and see if this IP is part of Tor network. My relay is regularly struggling a bit nowadays, with some source IP's crossing over the 1000 connections, but quite a few at 50-100. The one with 1000 connections, and for some random IP's none of their IP's being listed as an Tor node on atlas. Seems to be a lot of IP's out of 54.36.51.0/24 that tend to open a lot of sessions. Whereby the ones checked are not on Atlas. At some point the entire conntrack table was full and OOM kills for the tor process. This only left me to put in some connection limits. Despite being advices against. I currently have: 200 connections per /24, if that's used then at least allow 24 connections per /32. I'm currently running with 6600 connections just fine; when it crosses the 15k it becomes troublesome. Now blocking some connections might be far-far from ideal, but better ~6000 connections served with bandwidth then to remove my relay from the tor network in my view. That said it would be good if the Tor program itself would have some protections, to the extend possible, with the current protocol. For instance dropping clients (source IP's) that frequently connect but are not behaving. I understand this might have it's implications when under censorship/censorship countermeasures. -- Yours Sincerely / Met Vriendelijke groet, Stijn Jonker ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent wave of abuse on Tor guards
All, Just adding 0.02c; from the hosts going above 24 connections (my FW limit), the ASN's involved seem to focus on: 5 LEASEWEB-USA-WDC-01 - Leaseweb USA, Inc., US 18 OVH, FR 25 LEASEWEB-NL-AMS-01 Netherlands, NL That's 48 from the 72 IP's exhibiting this behaviour. Whereby the leaseweb ones are consecutive IP's. Careful not to share IP's here :-) All seen from the perspective of SJC01 / 328E54981C6DDD7D89B89E418724A4A7881E3192 Stijn On 22 Dec 2017, at 16:49, Pascal Terjan wrote: I got also 17 from ovh (under ip-54-36-51.eu) and plenty of leaseweb.com (didn't count) too but no your-server.de The OVH ones were interestingly 2 (nearby) consecutive blocks of 4 and 13 IPs (and are not relays) On 22 December 2017 at 15:23, Tyler Johnson wrote: Every IP I was checking through Atlas which are part of the mentioned hosts were NOT relays, all client connections. On Dec 22, 2017 9:20 AM, "niftybunny" wrote: Thats “only” “relays” with multiple connections to your relay? Interesting to see Hetzner there … Markus On 22. Dec 2017, at 16:14, Tyler Johnson wrote: Out off 133 IPs blocked with my rather aggressive firewall ruleset: leaseweb.com - 26 your-server.de - 66 ip-54-36-51.eu - 17 That was in < 24hrs. On Dec 22, 2017 3:38 AM, "niftybunny" wrote: Short answer: https://i.imgur.com/8QLptcz.png Around 15000 - 18000 connections I can see with netstat. Even my 300 mbit exit has less and there a a lot of Leaseweb clients connecting to me ... The interesting thing is, it comes and goes in waves. From 6000 (normal) to 2 connections within an hour. Someone doesn't like me very much :( Markus On 22. Dec 2017, at 08:42, Felix wrote: Am 22-Dec-17 um 08:25 schrieb niftybunny: Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I need 2 xeons to push 30 mbit as a guard/middle … Do you want to share some information: Type i) (memory exhaustion by too many circuits) What is the memory(top) per tor and its MaxMemInQueues ? How many circuits per hour in log ? Type ii) (cpu exhaustion by too many 'half open' tor connections) Is your number of open files normal (fw in place) and moderate connection counts per remote IP ? Type iii) (One fills your server with too many long fat pipes, first ACK and RTT) If on Freebsd, is "mbuf clusters in use" (netstat -m) moderate ? Do you get "kern.ipc.nmbclusters limit reached" in messages ? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Can it be done? - IPv6 only Relay
Hi tor geniuses, Having some bandwidth to spare, and "some" IPv6 addresses but no IPv4. I decided to setup an IPv6 only relay, and for diversity on OpenBSD, but I'm having trouble getting online. Is there any feasible way to do this as IPv6 only relay? [root@tornode2 tor]# grep -v -e ^$ -e ^# /etc/tor/torrc SOCKSPort 0 # Default: Bind to localhost:9050 for local connections. Log notice syslog RunAsDaemon 1 DataDirectory /var/tor ORPort 443 Address tornode2.sjc.nl OutboundBindAddress [2001:x:x::x] Nickname <> DirPort 80 DirPortFrontPage /etc/tor/tor-exit-notice.html MyFamily <> User _tor ExitPolicy reject *:* # no exits allowed ExitPolicy reject6 *:* # no exits allowed AuthDirHasIPv6Connectivity 1 ClientUseIPv6 1 ClientPreferIPv6ORPort 1 ClientPreferIPv6DirPort 1 Thx, Stijn signature.asc 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] Can it be done? - IPv6 only Relay
Hi again, Sorry, I really should have included this warning: Dec 25 11:34:22 tornode2 Tor[86924]: Problem bootstrapping. Stuck at 80%: Connecting to the Tor network. (Can't assign requested address; MISC; count 490; recommendation warn; host <> at :) This was after I jump started it with cached-* files from an other tor instance, otherwise it was stuck at 0% Thx again On 25 Dec 2017, at 11:07, Stijn Jonker wrote: > Hi tor geniuses, > > Having some bandwidth to spare, and "some" IPv6 addresses but no IPv4. I > decided to setup an IPv6 only relay, and for diversity on OpenBSD, but I'm > having trouble getting online. > Is there any feasible way to do this as IPv6 only relay? > > [root@tornode2 tor]# grep -v -e ^$ -e ^# /etc/tor/torrc > SOCKSPort 0 # Default: Bind to localhost:9050 for local connections. > Log notice syslog > RunAsDaemon 1 > DataDirectory /var/tor > ORPort 443 > Address tornode2.sjc.nl > OutboundBindAddress [2001:x:x::x] > Nickname <> > DirPort 80 > DirPortFrontPage /etc/tor/tor-exit-notice.html > MyFamily <> > User _tor > ExitPolicy reject *:* # no exits allowed > ExitPolicy reject6 *:* # no exits allowed > AuthDirHasIPv6Connectivity 1 > ClientUseIPv6 1 > ClientPreferIPv6ORPort 1 > ClientPreferIPv6DirPort 1 > > Thx, > Stijn signature.asc 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] Can it be done? - IPv6 only Relay
Hi Nusenu/Valters, Thanks for the reply and links; what isn’t entirely clear is the following scenario. What if I provide IPv4 via NAT, and IPv6 for the relay, hiding the IPv4 address, possibly with the “NoAdvertise” on the IPv4 entries for those. Reading the trac page I’m not sure whether this would work, as there will be no IPv4 inbound possible, only IPv4 outbound and IPv6 in and outbound. Additionally would it benefit the tor service or is it then only “show”? Sorry but that’s not entirely clear from what I can find published (and googling away). Thx, Stijn On Mon, Dec 25, 2017, at 12:04, Valter Jansons wrote: > Just for completeness' sake: > Main IPv6 roadmap/feature matrix is at > https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features> > The particular ticket for IPv6-only relay support is at > https://trac.torproject.org/projects/tor/ticket/5788> -- 4096R/A83CE748 > Valters Jansons > > On Mon, Dec 25, 2017, 12:52 nusenu wrote: >> >> >> Stijn Jonker: >> > Hi tor geniuses, >> > >> > Having some bandwidth to spare, and "some" IPv6 addresses but no >> > IPv4. I decided>> > to setup an IPv6 only relay, and for diversity on >> > OpenBSD, but I'm >> > having>> > trouble getting online. >> > Is there any feasible way to do this as IPv6 only relay? >> >> Hello Stijn Jonker, >> >> unfortunately IPv6 only relays are not supported. All relays require >> an IPv4 address.>> In (a far) future IPv6 only relays might be feasible - >> once most of >> the relays>> have IPv6 and relay-to-relay IPv6 connections are implemented. >> >> >> >> -- >> https://mastodon.social/@nusenu >> twitter: @nusenu_ >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Can it be done? - IPv6 only Relay
Hi Valter, Indeed, forgot/missed the reachability check only does IPv4. To bad. Nevertheless let me see if I can still do some magic freeing up some IPv4 and see if I can bring it online nevertheless then. Stijn On Mon, Dec 25, 2017, at 14:15, Valter Jansons wrote: > Stijn, > > When you are starting up a relay, it will do self-tests on whether the > ORPort you have specified is reachable from outside network and that > is what you will have a bad time with. As IPv6 self-testing is not a > thing yet (Ref: TracTicket#24403[1]) and it will then be doing self- > tests on the IPv4 address, which will fail as the relay will not be > reachable on that. There's TracTicket#4565[2] about IPv6 relay-to- > relay communications in general as well. All in all, some groundwork > has been laid out for IPv6 in general but research and (a lot of) > development is still to take place.> > -- 4096R/A83CE748 Valters Jansons > > On Mon, Dec 25, 2017 at 2:38 PM Stijn Jonker wrote:>> __ >> Hi Nusenu/Valters, >> >> Thanks for the reply and links; what isn’t entirely clear is the >> following scenario. What if I provide IPv4 via NAT, and IPv6 for the >> relay, hiding the IPv4 address, possibly with the “NoAdvertise” on >> the IPv4 entries for those.>> >> Reading the trac page I’m not sure whether this would work, as there >> will be no IPv4 inbound possible, only IPv4 outbound and IPv6 in and >> outbound.>> >> Additionally would it benefit the tor service or is it then only >> “show”? Sorry but that’s not entirely clear from what I can find >> published (and googling away).>> >> Thx, >> Stijn >> >> On Mon, Dec 25, 2017, at 12:04, Valter Jansons wrote: >>> Just for completeness' sake: >>> Main IPv6 roadmap/feature matrix is at >>> https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features>>> >>> The particular ticket for IPv6-only relay support is at >>> https://trac.torproject.org/projects/tor/ticket/5788>>> -- 4096R/A83CE748 >>> Valters Jansons >>> >>> On Mon, Dec 25, 2017, 12:52 nusenu wrote:>>>> >>>> >>>> Stijn Jonker: >>>> > Hi tor geniuses, >>>> > >>>> > Having some bandwidth to spare, and "some" IPv6 addresses but no >>>> > IPv4. I decided>>>> > to setup an IPv6 only relay, and for diversity on >>>> > OpenBSD, but >>>> > I'm having>>>> > trouble getting online. >>>> > Is there any feasible way to do this as IPv6 only relay? >>>> >>>> Hello Stijn Jonker, >>>> >>>> unfortunately IPv6 only relays are not supported. All relays >>>> require an IPv4 address.>>>> In (a far) future IPv6 only relays might be >>>> feasible - once most >>>> of the relays>>>> have IPv6 and relay-to-relay IPv6 connections are >>>> implemented. >>>> >>>> >>>> >>>> -- >>>> https://mastodon.social/@nusenu >>>> twitter: @nusenu_ >>>> >>>> ___ >>>> tor-relays mailing list >>>> tor-relays@lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> _ >>> tor-relays mailing list >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Links: 1. https://trac.torproject.org/projects/tor/ticket/24403 2. https://trac.torproject.org/projects/tor/ticket/4565 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Q about: The IPv4 ORPort address does not match the descriptor address
Hi All, As a follow-up to the thread, "Can it be done? - IPv6 only Relay" I linked the new OpenBSD Relay via an IPv4 over IPv6 tunnel to the other relay I operate. So there is: SJC01 / 328E54981C6DDD7D89B89E418724A4A7881E3192 and now SJC02 / 366BC592BC0154C0CD1D35C0E77D8F2C7F0B843E Both share the same public IP, as it's on atlas :-) I can see no issues sharing: SJC01 ORPort is on 80.127.117.180:443 / [2001:985:e77:10::4]:443 (DirPort 80) SJC02 ORPort is on 80.127.117.180:993 / [2001:985:e77:10::6]:993 (DirPort 8080) What I can't seem to get rid of is the warning: The IPv4 ORPort address 80.127.177.180 does not match the descriptor address 80.127.117.180. If you have a static public IPv4 address, use 'Address ' and 'OutboundBindAddress '. If you are behind a NAT, use two ORPort lines: 'ORPort NoListen' and 'ORPort NoAdvertise'. I think I tried every combo of ORPort NoListen/NoAdvertise and Address/OutboundBindAddress, but I don't seem to be able to get rid of this. What I have now is: ORPort [2001:985:e77:10::6]:993 ORPort <>:993 NoAdvertise ORPort 80.127.177.180:993 NoListen Address 80.127.117.180 OutboundBindAddress <> OutboundBindAddress [2001:985:e77:10::6] Port 993 and 8080 are one-on-one pushed through to the new node with DNAT/Port forward from the 80.127.117.180. This on: [userhost ~]$ tor --version Tor version 0.3.1.9 (git-727d3f1b5e6eeda7). [userhost ~]$ uname -a OpenBSD host 6.2 GENERIC#306 amd64 The daemon reports "Self-testing indicates your ORPort is reachable from the outside. Excellent." / "Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor." so that seems to be A-OK. Any suggestions (or should I "just" ignore this as mentioned on tor-dev @ Tue Jan 24 04:20:27 UTC 2017 in subject: "[tor-dev] log: ORPort/DirPort address does not match descriptor address")? Thx, Stijn signature.asc 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] Q about: The IPv4 ORPort address does not match the descriptor address
Hi "Tor", Ehmm.. On 27 Dec 2017, at 21:07, tor wrote: > I think you just have a typo here: > >> ORPort 80.127.177.180:993 NoListen > > 177 instead of 117 for the third octet. Duh... .. Thx! S___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor 0.3.2.9 Linux - first period fine, since today lots of: Your computer is too slow to handle this many circuit creation requests!
Hi All, Is this a "known" issue, my non-exit relay has been running for over a year, and although with the recent issues (attack / network issue or the likes) with some ipfilter kunfu it managed to get through the storm pretty well. Now all of a sudden since early today my logs are flooded with: Jan 18 11:34:44 tornode Tor[65839]: Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [204844 similar message(s) suppressed in last 60 seconds] First message is at Jan 18 07:17:13, last just Jan 18 11:37:44, when adding the # of circuits up, total in ~4 hours: 18033820 being 18 Million, which feels a bit much, but don't have any figures to compare. On the current hardware this never seemed to be an issue, not even by far it was normally (according to ESXi) at ~400-500mhz, now it's using 2 vCPU's at ~4000Mhz. Now of course I can lower the bandwidth, but if these are low bandwidth circuits then lowering the bandwidth from 10Mbyte/sec (peak 12,5Mbyte/sec) to a lower value might actually not resolve it. Anybody seeing this as well and/or ideas / advice etc? Stijn___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Attack or issue? 4 / 11 M of traffic
Hi All, Since around midnight CET, my relay who was happily running almost the same amount of traffic in and outbound, has dropped to 4 Meg in, 11 Meg out according to SNMP on the host. (Cap: 10M/peak 12.5M). Lots of messages like: - Channel padding timeout scheduled 304317ms in the past. - Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [45685 similar message(s) suppressed in last 60 seconds] Any suggestions what to check / verify for this? 328E54981C6DDD7D89B89E418724A4A7881E3192 Thx, Stijn signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.
Hi All, I initially went to the nyx website to find the right forum to ask questions. I understood this is the one :-), if not apologies. So I'm running two relays, one is running on CentOS7, the other Debian Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing the CPU, Exit policy etc info. It's not tor version specific, as I recently upgraded the tor software on the nodes regularly. So on the CentOS node I see this on the top at the right; cpu: 61.3% tor, 5.0% nyx mem: 371 MB (12.4%) pid: 1279 uptime: 02:59:09 fingerprint: 328E54981C6DDD7D89B89E418724A4A7881E3192 exit policy: reject *:* On the Debian node it's simply not printing any of these three lines. I can't find in the (debug) logging whether an utility or library is missing. It's nothing major, but annoying. Especially with the new alpha releases it's nice to keep an eye out on mem/cpu. Does anyone have an idea what the trick is to get it to work on debian? -- CentOS info: [user@tornode ~]$ tor --version Tor version 0.3.3.1-alpha (git-de8bc9eed6eaadfc). [user@tornode ~]$ nyx --version nyx version 2.0.4 (released November 5, 2017) [user@tornode ~]$ uname -a Linux tornode.sjc.nl 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux -- Debian info: [maint@tornode2 ~]$ tor --version Tor version 0.3.3.1-alpha-dev (git-9e48338a12fd1fef+0f23e7e96). [user@tornode2 ~]$ nyx --version nyx version 2.0.4 (released November 5, 2017) [user@tornode2 ~]$ uname -a Linux tornode2 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux [user@tornode2 ~]$ lsb_release -c Codename: stretch Thx, Stijn___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.
Hi Damian, On Sat, Feb 3, 2018 at 2:10 PM, Stijn Jonker wrote: Hi All, So I'm running two relays, one is running on CentOS7, the other Debian Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing the CPU, Exit policy etc info. It's not tor version specific, as I recently upgraded the tor software on the nodes regularly. On 3 Feb 2018, at 23:58, Damian Johnson wrote: Hi Stijn, my first thought is that this might be tor's DisableDebuggerAttachment feature. It causes proc contents to only be readable by root. Usually this breaks Nyx's connection resolution but it can prevent resource usage lookups too. Does setting 'DisableDebuggerAttachment 0' in your torrc cause the data to appear? For both nodes I have DisableDebuggerAttachment set to 0 If not then the next step is to take a peek at the debug logs. If you send me the logs on both platforms with any data you feel is sensitive redacted I'd be happy to take a peek. I only need the first five seconds or so of logs (just need to see the first resource resolution attempt). There is a lot to remove in those logs :-), but one thing catched my eye whilst comparing both side-2-side (I only looked at the debian one so far). The debian one was running nyx via python3, whereby the centos one ran it with python2. I did an pip3 uninstall nyx and then a pip2 install nyx on the debian server. Then I had the output on the top right: cpu: 88.7% tor, 54.8% nyx mem: 866 MB (21.9%) pid: 1344 uptime: 19:02:04 fingerprint: 366BC592BC0154C0CD1D35C0E77D8F2C7F0B843E exit policy: reject *:* So it seems to be something python2/python3 related. I'm not sure why I used python3 to be honest. P.S. If you want the logs, do you mind if I send them directly? Then I don't have to remove all the other tor node details, which is quite a lot that flies by (so this doesn't end up in the public archives - even-though it's public info anyway). Thanks! Stijn Cheers! -Damian ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] nyx question on info on top right side, present on CentOS, missing on Debian.
Hi Stain, On 4 Feb 2018, at 14:56, Stian Fauskanger wrote: Hi Stijn, So I'm running two relays, one is running on CentOS7, the other Debian Stretch. On both I have nyx (2.0.4) installed. The "Debian" one is missing the CPU, Exit policy etc info. It's not tor version specific, as I recently upgraded the tor software on the nodes regularly. So on the CentOS node I see this on the top at the right; cpu: 61.3% tor, 5.0% nyx mem: 371 MB (12.4%) pid: 1279 uptime: 02:59:09 fingerprint: 328E54981C6DDD7D89B89E418724A4A7881E3192 exit policy: reject *:* On the Debian node it's simply not printing any of these three lines. I can't find in the (debug) logging whether an utility or library is missing. It's nothing major, but annoying. Especially with the new alpha releases it's nice to keep an eye out on mem/cpu. I have a similar problem with nyx on FreeBSD 11.1. The CPU, mem, pid, uptime, fingerprint and exit policy is only visible when using a terminal width of 141-153 characters. You could try this. I think I found the non-printing at all, python2 vs python3. But when I have a smaller terminal (actually most of the time I run then side by side in a 55 char width terminal, the lines are printed in one column (for me at least - now on both nodes :-)): nyx - tornode.sjc.nl (Linux 3.10.0-6...) Tor 0.3.3.1-alpha (recommended) sjc01 - <>:443, Dir Port: 80, Control Port (cookie): 9051 cpu: 73.7% tor, 1.1% nyx mem: 691 MB (23.1%) pid: 1279 uptime: 19:09:43 fingerprint: 328E54981C6DDD7D89B89E418724A4A7881E3192 flags: Fast, Guard, Running, Stable, V2Dir, Valid Stian Fauskanger Thx, Stijn ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] - Feedback expected? - Experimental DoS mitigation is in tor master
Hi all, Not sure where to hook into the discussion, apologies of offending anyone spanning of a new thread from this first message. On 31 Jan 2018, at 10:16, Roger Dingledine wrote: > Hi folks, > > Thanks for your patience with the relay overload issues. > > We've merged https://bugs.torproject.org/24902 into tor git master. We'll > be putting out an 0.3.3.2-alpha release in not too long for wider testing, > and eventually backporting it all the way back to 0.2.9, but if you're > the sort who enjoys running code from git, now is a great time to try it > and let us know of problems and/or successes. One relay has been running for 3 days, with all FW rate limiting removed, the other ~2 days. Is any feedback expected/appreciated? I can share the heartbeat logging (the now three lines - Heartbeat / Circuit handshake stats / DoS) or anything else? [I assume save to share without the bandwidth on the Heartbeat line, but please confirm]. From a "how are things running?" well the "DoS attacks" come and go, and for now it looks good. Nothing out of the ordinary. CPU/Mem usage seems comparable whilst not under attack, traffic volumes seems a bit lower. The only visible thing is being marked on "Atlas" as an version with possible issues :-) Thx, Stijn signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] 1 circuit using 1.5Gig or ram? [0.3.3.2-alpha]
Hi all, So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes without any connection limits on the iptables firewall seems to be a lot more robust against the recent increase in clients (or possible [D]DoS). But tonight for a short period of time one of the relays was running a bit "hot" so to say. Only to be greated by this log entry: Feb 12 18:54:55 tornode2 Tor[6362]: We're low on memory (cell queues total alloc: 1602579792 buffer total alloc: 1388544, tor compress total alloc: 1586784 rendezvous cache total alloc: 489909). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.) Feb 12 18:54:56 tornode2 Tor[6362]: Removed 1599323088 bytes by killing 1 circuits; 39546 circuits remain alive. Also killed 0 non-linked directory connections. Feb 12 19:04:10 tornode2 Tor[6362]: Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes. So 1 Circuit being able to claim 1,5 gig or ram, now this seems a big much. Whilst the DoS protection seems to do something (see below). Now this could be a new attack or just an error etc. However wouldn't some sort of fair memory balance between circuits be an other mitigation factor to consider? Not saying it should be as strict as "circuit memory"/"# of circuits" but 99.x% of memory for one circuit feels wrong for a relay. Feb 12 13:58:34 tornode2 Tor[6362]: DoS mitigation since startup: 910770 circuits rejected, 10 marked addresses. 25972 connections closed. 324 single hop clients refused. Feb 12 19:58:34 tornode2 Tor[6362]: DoS mitigation since startup: 1222320 circuits rejected, 12 marked addresses. 33359 connections closed. 402 single hop clients refused. Thx, Stijn___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 1 circuit using 1.5Gig or ram? [0.3.3.2-alpha]
Hi Tor & Others, On 12 Feb 2018, at 20:29, tor wrote: I see this occasionally. It's not specific to 0.3.3.x. I reported it back in October 2017: Thx, I more or less added the version in the subject to clearly indicate it was on an alpha release https://lists.torproject.org/pipermail/tor-relays/2017-October/013328.html Roger replied here: https://lists.torproject.org/pipermail/tor-relays/2017-October/013334.html Ah thanks, not sure why my google kung-fu missed this one. MaxMemInQueues is set to 1.5 GB by default, which is why the problematic circuit uses that much RAM before its killed. You can lower MaxMemInQueues in torrc, however that will obviously have other impacts on your relay. If you have plenty of RAM, I'd maybe just leave things alone for now since Tor is already killing the circuit. My tornodes have 4Gig or ram, so I also put the MaxMemInQueues at 1,5G whilst the (D)DoS attacks were more troublesome (wasn't aware it was the default). I agree in theory some mitigation against this would be nice, but I'm not smart enough to offer anything specific. It seems Roger and other devs are already thinking about the issue. Not a coder myself (except some scripting) For those looking for the paper as well, the original URL gives a 403, I believe this is a copy (alterations or omitted slides can't check of course) http://www.robgjansen.com/talks/sniper-dcaps-20131011.pdf Thx, Stijn___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 1 circuit using 1.5Gig or ram? [0.3.3.2-alpha]
Hi David, On 12 Feb 2018, at 20:44, David Goulet wrote: > On 12 Feb (20:09:35), Stijn Jonker wrote: >> Hi all, >> >> So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes >> without any connection limits on the iptables firewall seems to be a lot >> more robust against the recent increase in clients (or possible [D]DoS). But >> tonight for a short period of time one of the relays was running a bit "hot" >> so to say. >> >> Only to be greated by this log entry: >> Feb 12 18:54:55 tornode2 Tor[6362]: We're low on memory (cell queues total >> alloc: 1602579792 buffer total alloc: 1388544, tor compress total alloc: >> 1586784 rendezvous cache total alloc: 489909). Killing circuits >> withover-long queues. (This behavior is controlled by MaxMemInQueues.) >> Feb 12 18:54:56 tornode2 Tor[6362]: Removed 1599323088 bytes by killing 1 >> circuits; 39546 circuits remain alive. Also killed 0 non-linked directory >> connections. > > Wow... 1599323088 bytes is insane. This should _not_ happen for only 1 > circuit. We actually have checks in place to avoid this but it seems they > either totally failed or we have a edge case. Yeah it felt a "bit" much. A couple megs I wouldn't have shared :-) > Can you tell me what scheduler were you using (look for "Scheduler" in the > notice log). The schedular always seems to be KIST (never played with it/tried to change it) Feb 11 19:58:24 tornode2 Tor[6362]: Scheduler type KIST has been enabled. > Any warnings in the logs that you could share or everything was normal? Besides that ESXi host gave an alarm about CPU usage, nothing odd in the logs around that time I could find. The general syslog logging worked both locally on the host and remote as the hourly cron jobs surround this entry. > Finally, if you can share the OS you are running this relay and if Linux, the > kernel version. Debian Stretch, Linux tornode2 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux not sure it matters, but ESXi based VM, running with 2 vCPU's based on i5-5300U, 4 Gig of memory No problems, happy to squash bugs. I guess one of the "musts" when running Alpha code, although this might not be alpha related (I can't judge). Thx, Stijn signature.asc 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] less than 3 bw auths available: self-measurement (with 10k cap in effect)
On 2 Mar 2018, at 12:08, Vasilis wrote: > Hi, > > Roger Dingledine: >> On Tue, Feb 27, 2018 at 06:47:00PM +, nusenu wrote: > >>> if your relays behave strangely in terms of bandwidth seen, than this >>> might be due to the fact that there are less than 3 bw auth votes available. >>> >>> If you run a fast relay it is capped to 10k cw. >>> >>> This affects currently the 857 fastest relays. >> >> Yep! We had 4 running, but 2 of them had problems, and we need 3 >> for the authorities to want to use the values from them. > > Perhaps it makes sense to do a call and add some more bandwidth authority > relays > during the upcoming meeting in Rome similar to the Montreal meeting. > Would the following documents still be valid (They themselves state they might be outdated)? https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthority https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements Also what bandwidth should an bwauth have available itself? I can see if I can support by running one, although it will be EU based. Stijn signature.asc 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] less than 3 bw auths available: self-measurement (with 10k cap in effect)
Hi Teor & Others, Thanks for your response, On 2 Mar 2018, at 23:26, teor wrote: > > On 3 Mar 2018, at 02:15, Stijn Jonker wrote: >> >> On 2 Mar 2018, at 12:08, Vasilis wrote: >> >> Hi, >> >> Roger Dingledine: >> >> On Tue, Feb 27, 2018 at 06:47:00PM +, nusenu wrote: >> >> if your relays behave strangely in terms of bandwidth seen, than this >> might be due to the fact that there are less than 3 bw auth votes available. >> >> If you run a fast relay it is capped to 10k cw. >> >> This affects currently the 857 fastest relays. >> >> Yep! We had 4 running, but 2 of them had problems, and we need 3 >> for the authorities to want to use the values from them. >> >> Perhaps it makes sense to do a call and add some more bandwidth authority >> relays >> during the upcoming meeting in Rome similar to the Montreal meeting. >> Would the following documents still be valid (They themselves state they >> might be outdated)? >> https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthority >> https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements >> >> Also what bandwidth should an bwauth have available itself? >> >> I can see if I can support by running one, although it will be EU based. >> > > You need a directory authority to vote on your bandwidth authority's output. Do you know what is the best way to get these vote(s), i.e. who to approach; as these kind of things are still a mystery with the Tor project for me. From a personal believe happy to assist, have reasonable spare CPU/Mem and Bandwidth available. So that should't be an huge issue. I know a thing or two about running systems so to say.. > Bandwidth authorities measure relay capacity. Then they send their results to > a > directory authority, and the directory authority puts the results in its > vote. The > directory authority votes change the consensus weights of relays. > > If your bandwidth authority isn't used for voting or testing, it's just > wasting > bandwidth. > > If you want to test and contribute code to a new bandwidth authority > implementation, I'd recommend: > > https://github.com/TheTorProject/bwscanner Thanks I found the TorFlow repo; that feels a bit hacked, but if either do the job and the above Q can be answered then happy to (try and) set it up. > But you'll need to change the default bandwidth server config, due to the > tor project DDoS. I assume that can be shared in a more private setting then. Stijn signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Shutdown relay 366BC592BC0154C0CD1D35C0E77D8F2C7F0B843E, upcoming shutdown 328E54981C6DDD7D89B89E418724A4A7881E3192
Dear all, This is to announce that with immediate effect I have shutdown relay sjc02/366BC592BC0154C0CD1D35C0E77D8F2C7F0B843E and will do so in about a year and half with sjc01/328E54981C6DDD7D89B89E418724A4A7881E3192 as it's a fallback directory. Thanks for all the support on the mailing list, especially with a stupid typo and the joint efforts in fighting the relay (D)DoS. The reasons why, well it's mostly based on personal assumptions, views, values and believes in terms of community/volunteer/project matters whereby quite possibly my views differ from the vast majority as such I don't believe it's appropriate to state those on a relay list. Thanks, Stijn P.S. I'll unsubscribe after this email, in case you believe a follow-up is warranted then feel free to reach out outside of the list. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
