Re: [tor-relays] Guard flag got removed after only 48 hours of downtime.
Yeah you wouldn't want to instantly throw a relay the Guard flag back after any kind of down time, because the whole point of a Guard is primarily stability. If a Guard drops off line for even 10 minutes, there's no way to know why. Network event? Power Outage? Any number of other problems? So when it shows back up, the metrics want to makes sure it's going to stay up before giving it Guard back :-D Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Sebastian Hahn" To: tor-relays@lists.torproject.org Sent: 7/28/2020 11:18:14 PM Subject: Re: [tor-relays] Guard flag got removed after only 48 hours of downtime. Hi William, On 29. Jul 2020, at 00:45, Matt Traudt wrote: The Guard flag conditions are https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2640 Given you're Fast and Stable, and have a good advertised bandwidth and weight, then I suspect you simply no longer have a Weighted Fractional Uptime that is at least the median for "familiar" relays. Thus just give it time. This has nothing to do with volunteering to be a fallback directory mirror. Thanks for running a relay, and for doing so at an unpopular provider. On 7/28/20 9:29 AM, William Kane wrote: Please discard the previous (empty) email, it was an error on my end. Today, I noticed that my guard flag has been taken away: https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF Does this have to do with the recent two, major downtime's of the relay? While I wasn't monitoring the server, the kernel decided (or rather oom-killer did) to reap the tor process for consuming too much memory (keep in mind, this is a virtual machine with only 1GB of RAM which running another daemon consuming about ~92MB's of RAM). I promptly restarted the relay, but the same thing happened again yesterday. So today, I manually set a lower MaxMemInQueues value instead of letting Tor calculate one for me - 640MB's instead of 732MB's. Still, I am confused as for why the guard flag has been taken away - I recently opted in to be a fallback directory mirror, does this have anything to do with it? The relay was stable and online for almost a year, so only 48 hours of downtime shouldn't affect the variables qualifying a relay to become and stay a guard that much? If this is because of the directory mirror thing, then please take my relay out of that pool - I want to stay a guard for a number of reasons - mainly because my host is only hosting about 10 tor relays unlike all the other big hosters that are commonly used - network variety is very important or so I've been taught, especially when it comes to guard relays. If this is a mistake on Tor Project's end, I please ask for it to be resolved - however, if it's the Directory Authorities disqualifying my relay, then there's nothing to be done except to wait. Greetings, William Kane according to gabelmoo's vote, it requires: flag-thresholds stable-uptime=1202114 stable-mtbf=3679804 fast-speed=102000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=1840 guard-bw-exc-exits=1440 enough-mtbf=1 ignoring-advertised-bws=1 gabelmoo assigns your relay the following values: R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF +MTBF 4632038 0.93987 S=2020-07-27 21:47:42 +WFU 4632038 4728633 As you can see, you barely do not make the WFU (required: 98%, you have 97.95%). Note that more recent downtimes are given more weight (that's what the W stands for in WFU). Very soon your flag should be back. Cheers Sebastian ___ 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] Authority Nodes
LOL this requirement: - Should be run by somebody that Tor (i.e. Roger) knows. One thing that I think would help Tor a lot and have seen some discussions on, would be a better 'trustworthy' way to measure bandwidth. I know it's measured a couple of different ways now, with 'observed' bandwidth and some testing/probing from the directory authorities, but as outlined in your e-mail adding more directory authorities is a tedious process at best, so is there a way that something could be set up where Tor maintainers could put a flag manually on a relay to indicate that it can and should, initiate bandwidth tests and report them back to the actual authorities? Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 http://ecansol.com On Sat, Jun 20, 2020 at 5:59 AM Roger Dingledine wrote: > On Fri, Jun 19, 2020 at 07:10:43AM -0300, Vitor Milagres wrote: > > I see the Authority Nodes are located only in North America and Europe. > > I would like to contribute to the TOR network as much as possible. I am > > currently running a node and I would like to make it an Authority Node as > > well. > > I am from Brazil and I believe it would possibly be a good idea to have a > > new Authority Node in South America. > > What are the requirements? What should I do to become one of them? > > FYI, the node I am running is 79DFB0E1D79D1306AF03A4B094C55A576989ABD1 > > Thanks for your interest in running a directory authority! Long ago we > wrote up a set of goals for new directory authorities: > https://gitweb.torproject.org/torspec.git/tree/attic/authority-policy.txt > > It is definitely an informal policy at this point, but it still gets > across some of the requirements. > > If you're able to run an exit relay at your location, that's definitely > more useful than another directory authority at this point. > > Also, because we haven't automated some steps, each new directory > authority that we add means additional coordination complexity, especially > when we identify misbehaving relays and need to bump them out of the > network quickly. > > Here are two big changes since that document: > > (1) The directory authorities periodically find themselves needing to > scale to quite large bandwidths -- sustaining 200mbit at a minimum, > and being able to burst to 400mbit or 500mbit, is pretty much needed at > this point: > https://bugs.torproject.org/33018 > > (2) Tor ships with hundreds of hard-coded relays called Fallback > Directories, which distribute the load for bootstrapping into the Tor > network, and which also provide alternate access points if the main > directory authorities are blocked. > https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors > So while the directory authorities are still a trust bottleneck, > they are less of a performance bottleneck than they used to be. > > In summary: if you want to run a directory authority, your next step > is to join the Tor community, get to know us and get us to know you, > come to one of the dev meetings (once the world is able to travel > again), and see where things go from there. > > Thanks, > --Roger > > ___ > 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] Consensus Weight low when compared to Advertised Bandwidth
Consensus weight is no lo ger based on advertised bandwidth to prevent abuse. It is based on measured and observed actual throughput. -- Matt Westfall President & CIO ECAN Solutions, Inc. 804.592.1672 On December 16, 2019 1:30:48 PM EST, Neel Chauhan wrote: >Hi, > >After having my Primcast.com dedicated server suspended, I signed up >for >a dedicated server from Psychz Networks in their Dallas location to run > >a FreeBSD-powered Tor exit relay. > >https://metrics.torproject.org/rs.html#details/9B6672E247BC4656915DF03A470D4B5BC2E7601F > >While Psychz is a bit more expensive than Primcast/ServerRoom (and that > >is with an special offer), I get a slightly faster server and far >better >customer support. > >One problem is that the consensus weight value is rather low in >proportion to the advertised bandwidth value, when they should be >approximately similar. > >In fact, my server's CPU usage never goes beyond 1%. > >Is this normal now that sbws is being deployed? Or is it bad peering on > >my relay? > >-Neel > >=== > >https://www.neelc.org/ >___ >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] Consensus Weight low when compared to Advertised Bandwidth
Also you didn't migrate your fingerprint. So it's a new server and will take weeks if not months for the consensus weight to creep up. -- Matt Westfall President & CIO ECAN Solutions, Inc. 804.592.1672 On December 16, 2019 1:30:48 PM EST, Neel Chauhan wrote: >Hi, > >After having my Primcast.com dedicated server suspended, I signed up >for >a dedicated server from Psychz Networks in their Dallas location to run > >a FreeBSD-powered Tor exit relay. > >https://metrics.torproject.org/rs.html#details/9B6672E247BC4656915DF03A470D4B5BC2E7601F > >While Psychz is a bit more expensive than Primcast/ServerRoom (and that > >is with an special offer), I get a slightly faster server and far >better >customer support. > >One problem is that the consensus weight value is rather low in >proportion to the advertised bandwidth value, when they should be >approximately similar. > >In fact, my server's CPU usage never goes beyond 1%. > >Is this normal now that sbws is being deployed? Or is it bad peering on > >my relay? > >-Neel > >=== > >https://www.neelc.org/ >___ >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] MyFamily line commented out but stays valid?
If memory serves, if you're running multiple nodes on the same IP or in the same /24 tor protocol automatically families any nodes running in the same /24 Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Michael Gerstacker" To: tor-relays@lists.torproject.org Sent: 11/4/2019 2:26:03 AM Subject: Re: [tor-relays] MyFamily line commented out but stays valid? Am Di., 22. Okt. 2019 um 19:04 Uhr schrieb : On 22.10.2019 18:53, Michael Gerstacker wrote: > when i comment out the MyFamily line with an # in the torrc on one > relay it > seems to be still handled like before. > > Hitting x in nyx or waiting a few days or rebooting does not make any > change. Nyx or arm must be called as root to save the config. Look at the torrc file with nano or vim. I always edit the torrc with nano and use nyx only to reload the torrc so this cant be the reason.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Migrating to CentOS8
I just setup a C8 / 0.4 yesterday on a linode nanode, seems to be running fine so far: https://metrics.torproject.org/rs.html#details/4E559E30279092315BF907DABDF00720473F8320 Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Totor be" To: tor-relays@lists.torproject.org Sent: 11/3/2019 6:20:51 AM Subject: [tor-relays] Migrating to CentOS8 Hi folks I'm considering migrating my relays from CentOS 7 to CentOS 8 and upgrading tor from 0.3.5.8 to 0.4.1.6 One small VM relay at home is running the C8/0.4 setup and seems to be ok According to bodhi, this is supposed to be stable https://bodhi.fedoraproject.org/updates/?packages=tor Before migrating the others, I prefer to cross-check: is there anyone aware of issues with C8 and tor 0.4.x?? Thanks! <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations
This looks promising then, especially as I intend to expand the tor nodes I'm donating to the network. Just added a middle in Japan yesterday :) I'll definitely check it out, thanks for the effort put into this!! Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: theonion...@gmx.com To: tor-relays@lists.torproject.org Sent: 10/31/2019 4:33:10 PM Subject: Re: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations Hello Matt, thank you for this question. For a share of the information displayed you are right. This is due to the fact that the metrics page and The Onion Box both display data from Onionoo. The relevant difference yet is that the Box attaches to the node to monitor it, whereas the metrics view is based on data that the node releases to the Tor network. As there's no demand for the Box to ensure anonymity (the dashboard is - usually - operated by s/o trustful), it does display as well enhanced and more detailled data that metrics shall not distribute. Thus the Box shows - as some examples - the configuration data of the node (as the node understood it), a live view of the up-/downloaded bandwidth (resolution 1/s vs 1/24h @ metrics), the messages that the node emits - and provides a mean to switch message levels with just one click. Some of those data - perhaps even all of it - may be found somewhere ... and the Box does what a dashboad does: It displays information from different sources in context for easier access - to support analysis and understanding. The ControlCenter creates an even more focused survey and allows (family) operators to verify the healthyness of a number of nodes (of his / her family) on a single page - displaying for each node e.g. live bandwith data and the status flags, as well as giving access to the detail dashboard (if necessary in case of trouble). I don't think this is a feature elsewhere available in the Tor universe. I yet know that these words just express my personal opinion. If you still have concerns I'd be happy to discuss with you - perhaps off list - what you would demand to get additonal value from an Onion Box. Greetings, Ralph Gesendet: Donnerstag, 31. Oktober 2019 um 01:16 Uhr Von: "ECAN - Matt Westfall" An: tor-relays@lists.torproject.org, "Tor Relay Mailinglist" Betreff: Re: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations As far as I can tell, this just gives you a graphical representation of the data available from metrics.torproject.. which already has graphs... I'm confused. Can you elaborate as to why someone should look into running this? Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: theonion...@gmx.com To: "Tor Relay Mailinglist" Sent: 10/30/2019 5:39:10 PM Subject: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations Good evening to the list! It's been a while since you've heard news about The Onion Box <http://www.theonionbox.com>. This was due to the fact that I spent some time to implement the ControlCenter, as ability to monitor several (better: as many as you like) Tor nodes in parallel. This picture <https://github.com/ralphwetzel/theonionbox/blob/devel/docs/images/cc.png> gives you an impression of a ControlCenter in action. The latest version <https://github.com/ralphwetzel/theonionbox/releases/tag/v19.2b3> is still labeled 'beta', yet seems stable enough to be released for broader testing. Documentation <https://github.com/ralphwetzel/theonionbox/blob/devel/README.md> is not finalized so far, but I'm convinced it is supportive enough to lead you over the low hurdles to setup your box. To upgrade your installation via pip <https://pypi.org/project/theonionbox/19.2b3/>, please use 'pip install theonionbox==19.2b3 --upgrade' ... as it would otherwise still pull the latest stable release (v4.3.1). Please note that the support for Python 2 was dropped, so you have to use Python 3.6 or higher to operate your Onion Box. Any feedback ist highly appreciated. Enjoy! Greetings, Ralph ___ tor-relays mailing list tor-relays@lists.torproject.orghttps://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] "large number of connections to other relays" - What should I do?
I noticed this yesterday when setting up a new node. It's because Tor establishes a bunch of internal circuits for testing and stability when you first start it up so it can measure it and such. Mine went away after about 24 hours. Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Akarin" To: "tor-relays@lists.torproject.org" Sent: 11/2/2019 5:35:01 AM Subject: [tor-relays] "large number of connections to other relays" - What should I do? Hi I'm running a new non-exit relay on my server which has a shared address, and I often see the following message in my log file: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Do I have to worry about that? If the answer is yes, what should I do?___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Fingerprint Change?!?
I guess it was file system corruption, because: https://puu.sh/EyXCk/6e7a7b36a7.png it's on the physical file system Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "teor" To: tor-relays@lists.torproject.org Sent: 10/21/2019 9:04:33 PM Subject: Re: [tor-relays] Fingerprint Change?!? Hi, On 21 Oct 2019, at 12:36, ECAN - Matt Westfall wrote: For some reason, and somehow my fingerprint for tor changed about a month ago :( It is now : C9FD236FDE28003315BD8C96EE94BC58D85FBACF It used to be: B1B10104EB72A1FBBF6687B05F1915D87D00DBDE Anyone have any idea why this would have happened? The fingerprint depends on the relay keys. If you accidentally deleted the keys, or there was some kind of filesystem corruption, then tor generates new keys. Check that your keys are stored in permanent storage? T ___ 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] The Onion Box v19.2: Dashboard to monitor Tor node operations
As far as I can tell, this just gives you a graphical representation of the data available from metrics.torproject.. which already has graphs... I'm confused. Can you elaborate as to why someone should look into running this? Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: theonion...@gmx.com To: "Tor Relay Mailinglist" Sent: 10/30/2019 5:39:10 PM Subject: [tor-relays] The Onion Box v19.2: Dashboard to monitor Tor node operations Good evening to the list! It's been a while since you've heard news about The Onion Box <http://www.theonionbox.com>. This was due to the fact that I spent some time to implement the ControlCenter, as ability to monitor several (better: as many as you like) Tor nodes in parallel. This picture <https://github.com/ralphwetzel/theonionbox/blob/devel/docs/images/cc.png> gives you an impression of a ControlCenter in action. The latest version <https://github.com/ralphwetzel/theonionbox/releases/tag/v19.2b3> is still labeled 'beta', yet seems stable enough to be released for broader testing. Documentation <https://github.com/ralphwetzel/theonionbox/blob/devel/README.md> is not finalized so far, but I'm convinced it is supportive enough to lead you over the low hurdles to setup your box. To upgrade your installation via pip <https://pypi.org/project/theonionbox/19.2b3/>, please use 'pip install theonionbox==19.2b3 --upgrade' ... as it would otherwise still pull the latest stable release (v4.3.1). Please note that the support for Python 2 was dropped, so you have to use Python 3.6 or higher to operate your Onion Box. Any feedback ist highly appreciated. Enjoy! Greetings, Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New relay in USA: bridge or middle relay?
hah, mine is -=severely=- under utilized.. NO CPU Load: https://puu.sh/EyX6N/81a5d5c76e.png 4 Mbps of throughput 2 Mbps each way or only ~ 20Mbps ea way: https://puu.sh/EyX7F/b7885ce635.png Plenty of bandwidth: https://puu.sh/EyX9O/65334af451.png Even to Germany: https://puu.sh/EyXbI/33cb46ac55.png Even to Brazil: https://www.speedtest.net/result/8719378576 Even to London: https://puu.sh/EyXk4/f86e74e856.png I realize that "false advertising of bandwidth to abuse the network protocols" has impacted the "consensus weight" assigned to various nodes. But there -definitely- needs to be a more intelligent system developed for determining this. I just proved that I have 2 GIGABITS of bandwidth HUNDREDS to other countries, but there is 20 MegaBits flowing through my relay, lol. Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "teor" To: tor-relays@lists.torproject.org Sent: 10/22/2019 4:53:25 AM Subject: Re: [tor-relays] New relay in USA: bridge or middle relay? Hi, On 8 Oct 2019, at 22:07, Isaac Grover, Aileron I.T. wrote: Good morning from Wisconsin, After reading about how middle relays in the USA go largely underutilized, and having quietly run my own middle relay for several years, would it be more beneficial to the network to launch several new bridges instead of more middle relays? Good question. Very few tor relays are actually under-utilised. Many operators expect 100% utilisation, but low-latency protocols work best around 10% utilisation. We're currently at 30%. So feel free to deploy a middle, and if it's fast and stable enough, it might become a guard. Some bridges are kept in reserve. Others are handed out using less popular methods. So feel free to deploy multiple bridges on the same IP address or subnet. T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Fingerprint Change?!?
For some reason, and somehow my fingerprint for tor changed about a month ago :( It is now : C9FD236FDE28003315BD8C96EE94BC58D85FBACF It used to be: B1B10104EB72A1FBBF6687B05F1915D87D00DBDE Anyone have any idea why this would have happened? Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Neel Chauhan" To: tor-relays@lists.torproject.org Sent: 10/19/2019 7:47:28 PM Subject: Re: [tor-relays] Windows Relay Setup Tor 0.2.4.23 is EOLed and is blacklisted from the network. Vidalia is also EOL and unmaintained. Also see: https://blog.torproject.org/removing-end-life-relays-network If you want a Windows relay, you'll have to configure manually whether you like it or not. It's hard (Tor is Unix-native), and performance sucks when compared to Linux/BSD/macOS, but on the positive Windows is still better for relay diversity than Linux. If there is Linux malware hurting the Tor network, we shouldn't just hope for BSD variants to keep us alive. Closed source or not, we should also consider Windows as an alternative relay OS (if you have a license or are willing to buy one). And I'm saying this as someone who runs FreeBSD relays and a FreeBSD desktop myself. You can also use a VM, and it may be easier, but if I were you, just use the expert bundle and try to configure Tor as a NT service. You won't have to worry about a hypervisor and will help relay diversity along the way. -Neel === https://www.neelc.org/ On 2019-10-17 15:20, William Pate wrote: I finally got around to playing with this some more. Thank you for your message, Bruce. I searched for Vidalia and found an old bundle that appears to work perfectly on my Windows 10 machine. Steps I took: 1. Download Vidalia Bundle 0.2.4.23 from http://vidalia-bundle.en.lo4d.com/ 2. Extract 3. Install 4. Start 5. The Vidalia Control Panel will pop-up 6. In settings, I changed the Tor executable from the one included with the Vidalia Bundle to the current version of Tor elsewhere on my system. Like I said, it *appears* to be working. Can't find it in relay search yet, but I only set it up moments ago. Nickname is inadequate Contact is willp...@disroot.org William Pate willp...@pm.me 512-947-3311 inadequate.net ‐‐‐ Original Message ‐‐‐ On Sunday, July 14, 2019 1:44 AM, Barton Bruce wrote: William, On 7/11/2019 6:58 PM, William Pate wrote: > I'm interested in hosting a Windows-based relay, if anyone can point me to a good tutorial. I've tried the most common ones. > > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays There used to be a VIDALIA (sp?) kit that could simply be downloaded and run on a windows machine. I then worked for an ISP/CLEC and had lots of bandwidth so ran Vidaalia on a 64 bit Windows 7 Ultimate machine on my desk at work. I never did hear why something had changed at the tor project so that stopped working, but do remember a rude snippy condescending reply from someone on the mailing list so I lost interest. I did get the head Tor guy from the Central Square Cambridge office of TOR to come speak at a local networking group's monthly meeting we held at a MicroSlush faclity in Burlington, MA and it was well received by a packed audience. I think he now has left TOR and works for some ISP. This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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] FYI - DNS
I also do -not- get an answer @ that DNS but other domains resolve https://puu.sh/Ep4Ws/150c13aef7.png Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Geoff Down" To: tor-relays@lists.torproject.org Sent: 10/4/2019 6:28:28 PM Subject: Re: [tor-relays] FYI - DNS On Fri, Oct 4, 2019, at 11:51 AM, Paul Templeton wrote: Just an FYI on a problem I found with two DNS of 1and1 ionos. The affected DNS are 212.227.123.16 and 212.227.123.17 which both are not responding to *.torproject.org domain or sub domains. I found this out as my system reverted back to the default DNS after a system crash. I'm now using bind on the local system and all is fine. Just thought to let all know just in case they are using these DNS. Paul Works for me: dig @212.227.123.16 torproject.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57004 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;torproject.org.IN A ;; ANSWER SECTION: torproject.org. 150 IN A 95.216.163.36 torproject.org. 150 IN A 116.202.120.165 dig @212.227.123.17 www.torproject.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51378 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.torproject.org.IN A ;; ANSWER SECTION: www.torproject.org. 150 IN A 95.216.163.36 www.torproject.org. 150 IN A 116.202.120.165 ___ 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] Short Research Survey
TBH both of those things should be self evident to anyone who has run a tor node, which is a request to actually take the survey to begin with. It's why tor exists, why people use it, and kind of the point. It would kind of be like if I was invited to participate in a stock car race I have to have a stock car. I can't take my tricycle there. ;-) -- Matt Westfall President & CIO ECAN Solutions, Inc. 804.592.1672 On September 10, 2019 3:43:58 AM EDT, teor wrote: > >Hi, > >> On 10 Sep 2019, at 14:35, Anon-research >wrote: >> >> Dear Tor relay operators, >> >> We are a team of researchers at MIT, and we would like to ask Tor >relay operators to participate in a short and anonymous survey (no >personal information or IP address collected). > >If you want to make sure that people's IP addresses won't be collected, >you should recommend that they complete the survey using Tor Browser. >Otherwise, any host for any resources on qualtrics could collect IP >addresses :-) > >> This study is focused on the importance of providing anonymity by >volunteers in various contexts, and will take no more than 5-10 minutes >to finish. > >Please consider this recommendation for future studies, to provide >anonymity to your survey volunteers. > >> You can learn more and take the survey at this link: >https://mit.co1.qualtrics.com/jfe/form/SV_6W3YXSCnqMVGPs1 > >Best of luck with your survey! > >T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ORPort
Is your node behind a routee/firewall? You most likely need to forward ports in your router. -- Matt Westfall President & CIO ECAN Solutions, Inc. 804.592.1672 On September 10, 2019 9:46:50 PM EDT, Anonforpeace wrote: >Hello: > >Hope someone can help me. I'm trying to configure a bridge and I've >followed all the instructions and I've chosen several ports and none of >them are reachable. I've used the test site that Tor lists on its >site. "Your server has not managed to confirm that your its ORPort is >reachable." Each port I list on the test site says unreachable. What >am I missing? The instructions are pretty straightforward. > >Thanks ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay ipv6
That's why I personally just disable all firewalls and just configure acls in vulnerable services themselves. Don't let mysql listen on anything but local host, server secured lol. -- Matt Westfall President & CIO ECAN Solutions, Inc. 804.592.1672 On August 22, 2019 11:46:44 AM EDT, Roman Mamedov wrote: >On Thu, 22 Aug 2019 13:07:21 + >"Matt Westfall" wrote: > >> So perhaps your ISP is wonking with tor traffic as suggested. > >We happened to meet in a Telegram group chat and after some more >discussion >the cause turned out to be firewall rules on the relay machine itself. > >-- >With respect, >Roman ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay ipv6
I can traceroute to your ipv6 address: traceroute to 2a03:e2c0:bc7::2 (2a03:e2c0:bc7::2), 30 hops max, 80 byte packets 1 2001:559:800c:1900::5a01 (2001:559:800c:1900::5a01) 0.356 ms 0.345 ms 0.449 ms 2 2001:558:180:1c::1 (2001:558:180:1c::1) 0.317 ms 0.435 ms 0.429 ms 3 2001:558:180:36::1 (2001:558:180:36::1) 7.756 ms 7.763 ms 7.864 ms 4 be-21508-cr02.ashburn.va.ibone.comcast.net (2001:558:0:f6cd::1) 10.873 ms * * 5 * * * 6 * * * 7 * * * 8 lo-0-v6.ear4.frankfurt1.level3.net (2001:1900:2::3:12b) 96.479 ms 96.505 ms 96.654 ms 9 2001:1900:5:2:2::5be2 (2001:1900:5:2:2::5be2) 108.774 ms 108.757 ms 108.757 ms 10 rt.mr.msk.ru.retn.net (2a02:2d8::57f5:e005) 141.933 ms 142.148 ms 141.996 ms 11 gw-mediaserviceplus.retn.net (2a02:2d8:0:82a:232a::1) 136.907 ms 136.871 ms 136.670 ms 12 2a04:5200:: (2a04:5200::) 142.424 ms 141.550 ms 141.963 ms 13 2a03:e2c0:bc7::2 (2a03:e2c0:bc7::2) 140.933 ms 141.737 ms 141.245 ms So perhaps your ISP is wonking with tor traffic as suggested. Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "teor" To: tor-relays@lists.torproject.org Sent: 8/22/2019 7:23:03 AM Subject: Re: [tor-relays] tor relay ipv6 Hi, On 22 Aug 2019, at 20:00, Станислав wrote: 22.08.2019, 06:57, "teor" : On 21 Aug 2019, at 23:38, armik...@gmail.com wrote: hi.in relay stopped working ipv6.address is correct all pings, including tor to the servers, but relay does not work.before that it worked perfectly 2 months. Please tell us your relay's fingerprint. CE5ED345398CC02D573347C2F238F80B18E680EE. Your relay's IPv6 address is not reachable from the directory authorities: https://metrics.torproject.org/rs.html#details/CE5ED345398CC02D573347C2F238F80B18E680EE All 6 directory authorities on IPv6 can't reach your relay on IPv6: https://consensus-health.torproject.org/consensus-health-2019-08-22-10-00.html#CE5ED345398CC02D573347C2F238F80B18E680EE But your relay is still reachable over IPv4 from the 3 directory authorities that don't have IPv6. Please copy and paste the notice-level logs that tor creates on startup, from launch to the end of the ORPort and DirPort reachability checks. And your relay is reachable over IPv6 on its ORPort and DirPort from at least one relay in the tor network. It looks like your torrc matches your local network config. Please copy and paste your torrc, particularly the Address, ORPort, DirPort, and OutboundBindAddress options. Your torrc looks correct. It can be hard to set up IPv6 for a relay, we're working on a grant to make it easier. Tor doesn't do IPv6 reachability checks yet, that's part of the grant. The only issue I can see is that all 6 directory authorities on IPv6 can't reach your relay on IPv6. Has your provider stopped routing your IPv6 address to your relay? Does your provider censor Tor over IPv6? It looks like the problem is somewhere between your relay machine and the IPv6 internet. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay ipv6
Here's all the info you need to setup IPv6 in Debian: root@ateam:~# ifconfig eno1: flags=4163 mtu 1500 inet 50.238.252.6 netmask 255.255.255.252 broadcast 50.238.252.7 inet6 2001:559:800c:1900::5a02 prefixlen 126 scopeid 0x0 root@ateam:/etc/network# pwd /etc/network root@ateam:/etc/network# cat interfaces iface eno1 inet6 static address 2001:559:800c:1900::5a02 netmask 126 gateway 2001:559:800c:1900::5a01 dns-nameserver 2620:0:ccc::2 2620:0:ccd::2 Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "teor" To: tor-relays@lists.torproject.org Sent: 8/22/2019 6:08:14 AM Subject: Re: [tor-relays] tor relay ipv6 Hi Paul, On 22 Aug 2019, at 14:26, Paul Templeton wrote: It can be hard to set up IPv6 for a relay, we're working on a grant to make it easier. It could be helpful to do a request/survey to relay operators to find out their experiences. That is those who have ipv6 configured what was the process and if there were any problems in the process. For those who haven't yet configured ipv6 what is the barriers preventing them from using ipv6. Yes, I'd love to know what problems relay operators have with setting up IPv6. I have some idea from helping people out, but hard data is more useful. We tried to add a survey/advocacy component to the grant, but there wasn't enough time in the grant budget. Would you like to run a survey or start a mailing list thread? For me it was a problem at the ISPs end then it wasn't clear how to get network config to use ipv6. I got the shits with it in the end and just used iface eth0 inet6 dhcp. It works... LOL Yeah it took me a while to learn how to set up IPv6 on Linux. Most VPS providers don't do it automatically. T ___ 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] tor relay ipv6
IPv6 at the OS Side is not difficult whatsoever. My node is running IPv6, I have 2Gbps Comcast Fiber. It's literally no different than configuring IPv4 other than its hexidecimal and a lot more digits :-D Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Paul Templeton" To: tor-relays@lists.torproject.org Sent: 8/22/2019 12:26:09 AM Subject: Re: [tor-relays] tor relay ipv6 It can be hard to set up IPv6 for a relay, we're working on a grant to make it easier. It could be helpful to do a request/survey to relay operators to find out their experiences. That is those who have ipv6 configured what was the process and if there were any problems in the process. For those who haven't yet configured ipv6 what is the barriers preventing them from using ipv6. For me it was a problem at the ISPs end then it wasn't clear how to get network config to use ipv6. I got the shits with it in the end and just used iface eth0 inet6 dhcp. It works... LOL Paul ___ 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] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Thank goodness something is being done to hopefully resolve some of the issues with unutilized bandwidth that people keep talking about constantly. I get having to change things due to abuse and misconfigurations with the tor network using observed bandwidth and some bandwidth testing to confirm/verify available bandwidth versus just using whatever 'ol configuration value is set. But it's definitely kind of slowed nodes down in general :( Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Roger Dingledine" To: tor-relays@lists.torproject.org Sent: 7/26/2019 10:35:29 AM Subject: Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths On Fri, Jul 26, 2019 at 10:18:24AM -0400, Rob Jansen wrote: I am planning on performing an experiment on the Tor network to try to gauge the accuracy of the advertised bandwidths that relays report in their server descriptors. Briefly, the experiment involves running a speed test on every relay for a short time (about 20 seconds). Thanks Rob! For context, I asked Rob to do this experiment, because we know that the current bandwidth authority design is mis-measuring relays, but we don't know how wrong things are. Giving every relay a short burst of load should give us some insight into how much traffic that relay can handle, which will in turn tell us how much room for improvement there is in our bandwidth estimation. And as a bonus, for this one time, fast relays should actually be consistently seen as fast, and the Tor network should be better balanced and the user experience should be better. If we like how it works, our follow-up task will be to change things so we get this result all the time. :) Woo, --Roger ___ 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] Unutilized bandwidth
I kind of have the same problem, I have a gigabit relay setup too, https://metrics.torproject.org/rs.html#details/B1B10104EB72A1FBBF6687B05F1915D87D00DBDE The consensus weight varies wildly and never seems to get very high. I'm even running on 443 and 80 the replies I got before were basically is what it is and I mean we're still helping the network by running a node, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Alec Larsen" To: tor-relays@lists.torproject.org Sent: 7/11/2019 10:23:21 PM Subject: [tor-relays] Unutilized bandwidth Hello, I've only recently joined this list, so I apologise in advance if this is not the appropriate place for my question. For the past month, I have been operating an exit node ( 89094DFA4158C7A1583EC3A332CDCBC74A28CC0E ) from UnitedIX in Chicago, IL, US. The server has a dedicated gigabit port, and I had hoped to be able to relay around 200 TB of traffic per month, but for some reason my advertised bandwidth has been hovering at just 12 MiB/s since the first few days. The server itself is an older Supermicro PfSense server with a Xeon E3-1270v3 at 3.5ghz and 32gb of RAM. It is currently running the latest stable release of FreeBSD (12.0p7) and Tor (0.4.0.5). As far as I can tell, the machine is mostly idle: * The Tor process is the most active, and I've yet to see it go above 5% CPU. * Memory usage is under 1.5gb. * Running `speedtest-cli` (even to different servers using the `--server` option) consistently gives 600mbps+ in both directions to most destinations. * There's nothing interesting in `dmesg` or the debug logs. Does anyone have suggestions for what the bottleneck here might be? I'm happy to share more details about my configuration if that would be helpful. Thank you in advance for any help that you are willing to provide! I think Tor provides a lot of value, and I would like to provide as much bandwidth as I can to the network. -- Alec___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver
Just set your exit relay DNS to 8.8.8.8 and 1.1.1.1 I mean dns traffic isn't bulk traffic, let google and CloudFlare do the "work" Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Tim Niemeyer" To: tor-relays@lists.torproject.org Sent: 6/29/2019 2:59:34 AM Subject: Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver Hi nusenu After reading your Mail, I realized that not the DNS records for the exit IPs are failing. Instead this list shows problems to resolve dns on the exit. I looked at our exit and all looks fine. Resolver works very fast and nothing imporint within the logfile. Only some dudes use 0.100.2.2 as remote address, but let's be fair, that can't work. ;) There are 4 exits on one machine with one dns server. Only 3 of them are shown in the list: https://metrics.torproject.org/rs.html#search/as:AS205100 Maybe it is a load problem, because this machine has 100% cpu load? :( A dedicated machine for dns may be good, but currently we have only this one machine. Another way could be to recude exit capacity, but I don't know if it's a good idea to throttle it? Btw, in the mean time we got more upstream transit and now we are looking to get better / second hardware. But money is a limiting factor. :( Kind regards Tim Am Freitag, den 28.06.2019, 20:16 + schrieb nusenu: 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. Exit relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase significantly due to some major exit operators apparently having DNS issues and we 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 relay consistently shows a non zero 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. kind regards 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
Re: [tor-relays] Setting Tor Relay to Hibernate After 100Mbits
Mbits is a measure of data speed, not amount. You have to specify the accounting in MBytes GBytes etc. MB GB You need to find out what your amount of transfer limit is, and cap accordingly. If Google is saying that you can use 100 Mbps of outbound bandwidth on average, then you just need the relay bandwidth & burst rates. It will prevent it from using more than 100 Mbps so you won't go over. Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Keifer Bly" To: tor-relays@lists.torproject.org Sent: 6/3/2019 1:20:29 PM Subject: [tor-relays] Setting Tor Relay to Hibernate After 100Mbits Hi all, so as of Google Clouds pricing plans on outgoing traffic, I am attempting to set my relay to hibernate after sending 100 mbits of data per month. Does this torrc configuration look like it would do that? SOCKSPort 0 ORPort 65534 ExitPolicy reject *:* ContactInfo keiferDoTblyAtgmaildOtcom Nickname torworld RelayBandwidthRate 100 MBits RelayBandwidthBurst 100 MBits AccountingMax 100 MBits AccountingStart month 1 00:00 AccountingRule out Thanks all. --Keifer___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Onionoo and ASN Number/AS Name
I had problems with the Static IPs Comcast gave me and GeoIP pulling up Minesotta everywhere, because that's last address they were "registered" at. So I contacted all of the GeoIP Providers and had them update their databases. I don't know how that would work on -adding- in a whole ASN though, you'll probably just have to wait for it to filter through. Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "teor" To: tor-relays@lists.torproject.org Sent: 6/2/2019 1:54:34 AM Subject: Re: [tor-relays] Onionoo and ASN Number/AS Name Hi, On 2 Jun 2019, at 15:14, Conrad Rockenhaus wrote: Onionoo returns “unknown” for my ASN for some reason (should return 63080) and returns “unknown” for AS Name (Should be GreyPony Consultants - as named in ARIN). I’m trying to find out where things might be potentially breaking here before I start connecting to the route servers at DE-CIX next week. Has anyone seen this type of issue before? Onionoo uses MaxMind's AS database, which is slow to update: https://trac.torproject.org/projects/tor/ticket/26585 If you use RIPE, you can see that the AS is present in IANA and WHOIS, but not in MaxMind: https://stat.ripe.net/63080 T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Low
Hey toer, I actually removed the Bandwidth Rates per another suggestion. Just sucks I can donate more to the TOR Network, but because other people abused the advertised bandwidth settings now it is what it is. https://puu.sh/DAw2V/aeb55530e8.png Also I guess the fact that most of the traffic across tor is http/https It's not ever going to "observe" a whole lot because it's quick small packets of data. I moved it to another IP and put it on 443 / 80 so maybe that will help cause firewalls and such. It's also directly on a public wan IP now, so firewall/router complications. Config in Nyx: https://puu.sh/DAwXD/39269fba87.png Chutney Results - https://puu.sh/DAwYD/131f6f1959.png Ran a 30 MB Test 10 was fast and 100 kept crashing 2nd Run: https://puu.sh/DAx0v/4c73a8b661.png So looks like my hardware can only handle about 100Mbps Full Duplex, but that's still way more than 9 :-D Guess we'll see what happens. I didn't see if anyone answered if I need a separate IP or if I can create another tor instance on different ports but on the same IP, to increase the load I'm handling. Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "teor" To: tor-relays@lists.torproject.org Sent: 6/2/2019 1:45:35 AM Subject: Re: [tor-relays] Relay Consensus Low Hi, On 1 Jun 2019, at 14:57, Matt Westfall wrote: Hello thanks for the comments, I might do that, remove the limits, because it's self limiting by the 1 Gbps network port, so it can't use more than that anyway. Following the instructions here: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow#TorNetworkLimits It looks like your relay is limited by its own observed bandwidth. (The observed bandwidth that your relay has seen itself using.) So increasing the RelayBandwidthRate would be a good idea. If your relay's observed bandwidth gets above 9 megabytes a second, your relay will be limited by the bandwidth authorities' measurements. (The median measurement for your relay is 8910 scaled kilobytes per second.) https://consensus-health.torproject.org/consensus-health-2019-06-02-04-00.html#B1B10104EB72A1FBBF6687B05F1915D87D00DBDE There might not be much you can do about this: Comcast has slow peering with a large number of internet networks. And it looks like 4/6 of tor's current bandwidth authorities are on those networks. This isn't something Tor can fix: we can only measure the bandwidth that Comcast is giving you. If Comcast has slow peering to US East and Europe, then clients using your relay will be slow. I tried to run chutney tests to see what hardware supports but haven't quite figured out what the command line I should be using is. Any help with that would be appreciated. You're right, the README is more confusing than it needs to be. Try: ./chutney/tools/test-network.sh --data $[10*1024*1024] If a 10 MB transfer is too fast, try 100 MB. I opened this ticket for us to fix our documentation: https://trac.torproject.org/projects/tor/ticket/30720 T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Low
Hello thanks for the comments, I might do that, remove the limits, because it's self limiting by the 1 Gbps network port, so it can't use more than that anyway. I'm using an Opnsense routing platform, and I've had more than 4,000 simultaneous connections just running torrents, lol. Igor, it doesn't appear to be a CPU bottleneck: https://puu.sh/DA4GR/2ef1b58e2e.png Am I able to run another tor instance just on different ports on the same IP? According to file descriptor limit I shouldn't be hitting a socket/file descriptor limit either. https://puu.sh/DA4Sh/6e27417c74.png I tried to run chutney tests to see what hardware supports but haven't quite figured out what the command line I should be using is. Any help with that would be appreciated. Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "teor" To: tor-relays@lists.torproject.org Sent: 5/30/2019 7:05:20 PM Subject: Re: [tor-relays] Relay Consensus Low Hi, On 25 May 2019, at 01:13, Matt Westfall wrote: My tor node: https://metrics.torproject.org/rs.html#details/B1B10104EB72A1FBBF6687B05F1915D87D00DBDE Doesn't ever go up above 8800 or so. One thing I notice in Nyx is that my connections never go above about 2000 in and out connections. That's unusual, because there are about 7,000 relays in the network. How many simultaneous connections does your router support? (Lots of them claim to support unlimited connections, but only support a few hundred or a few thousand.) I have advertised bandwidth of just shy of a gigabit in my config. I understand now that the "advertised bandwidth" is calculated based on observed traffic through the node, which while more reliable and avoids abuse, seems to be counter productive to a degree. Ultimately what do I need to do to get more traffic through my node? Cause I have a 2Gbps fiber sitting here basically doing nothing so I was giving 1Gbps to tor :) You could remove all the bandwidth limits, and put them back in when tor is using more than you want it to. (Tor tries to keep some extra bandwidth to deal with traffic spikes, so a 1 Gbps limit will get you around 300 kbps sustained traffic.) Here's a more detailed explanation, and some other things to try: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay Consensus Low
My tor node: https://metrics.torproject.org/rs.html#details/B1B10104EB72A1FBBF6687B05F1915D87D00DBDE Doesn't ever go up above 8800 or so. One thing I notice in Nyx is that my connections never go above about 2000 in and out connections. I have advertised bandwidth of just shy of a gigabit in my config. I understand now that the "advertised bandwidth" is calculated based on observed traffic through the node, which while more reliable and avoids abuse, seems to be counter productive to a degree. Ultimately what do I need to do to get more traffic through my node? Cause I have a 2Gbps fiber sitting here basically doing nothing so I was giving 1Gbps to tor :) Config -- RunAsDaemon 1 ControlPort 9051 ORPort 9001 ORPORT [2001:559:c290::fffb]:9001 RelayBandwidthRate 45 MB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 50 MB # But allow bursts up to 200KB/s (1600Kbps) DirPort 9030 # ExitPolicy reject *:* # no exits allowed ExitPolicy reject6 *:* Any suggestions appreciated. Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
