Re: [tor-relays] obfs4 bridge port question
Hi, > On 10 May 2020, at 12:07, Roger Dingledine wrote: > > On Sat, May 09, 2020 at 01:15:46PM -0700, Eddie wrote: >>> Bridge obfs4 : cert= iat-mode=0 >>> I have all the parts mentioned in the text except for . >>> >> It's the port from this line: ServerTransportListenAddr obfs4 >> 0.0.0.0: where the odfs4 is listening. > > Right. Or if you didn't set a ServerTransportListenAddr line in your > torrc file, then you can get it either from the log line: > > [notice] Registered server transport 'obfs4' at '[::]:46396' > > or from a corresponding line the 'state' file in your DataDirectory. Or you should be able to find the complete bridge line in: DataDir/pt_state/obfs4_bridgeline.txt https://github.com/Yawning/obfs4#tips-and-tricks T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IPV6
Hi, > On 5 May 2020, at 21:21, Dr Gerard Bulger wrote: > > Is there any work going on which would allow Tor to work with IPV6 alone? > i.e. no IPV4 OR ports etc. To protect user privacy, we need more dual-stack relays, before we can have IPv6-only relays. At the moment, we're working on improvements to IPv6 support on dual-stack relays, including IPv6 relay-to-relay connections, IPv6 ORPort reachability self-tests, and IPv6 address auto-detection. (These features are also useful for future IPv6-only relays.) You can read more details in the list archives, search for "Sponsor 55" or "IPv6". Here's one recent email: https://lists.torproject.org/pipermail/tor-relays/2020-March/018250.html Once we have more dual-stack relays, we could work on: * bridges with inbound IPv6 ORPorts, and outbound IPv4 connectivity * IPv6-only bridges * IPv6-only exits We'll probably start on IPv6-only exits first, because exits are scarce. Here are some of the issues we need to fix to make that happen: https://lists.torproject.org/pipermail/tor-dev/2020-May/014262.html T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (Без темы)
Hi, > On 4 May 2020, at 20:51, Станислав wrote: > > hi, strange but the relay constantly spontaneously goes offline after 3, 4 > hours again online in the logs no errors other than this (Failing because we > have 4063 connections already. Please read doc / TUNING for guidance. [over > 1601 similar message (s) suppressed in last 21600 seconds) > CE5ED345398CC02D573347C2F238F80B18E680EE Here is a link to doc/TUNING: https://github.com/torproject/tor/blob/master/doc/TUNING It says: "Most operating systems limit an amount of TCP sockets that can be used simultaneously. It is possible for a busy Tor relay to run into these limits, thus being unable to fully utilize the bandwidth resources it has at its disposal. Following system-specific tips might be helpful…" Let us know how you go with the system-specific instructions! T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
Hi, > On 2 May 2020, at 00:07, Станислав wrote: > > 01.05.2020, 14:20, "teor" : > Hi, > > > On 1 May 2020, at 20:57, Станислав wrote: > > what could it mean > > May 01 13:47:02.000 [warn] parse error: Malformed object: missing object end > line > May 01 13:47:02.000 [warn] Unparseable microdescriptor found in download or > generated string > > Where is it happening? > Client or relay? > > Can you share a few more log lines? > > If it's a relay, maybe your connection just got cut off. > Looks like a relay, and relays use unencrypted DIrPorts for directory downloads. So maybe: * the connection got cut off * the remote relay is sending corrupted data * the data was modified in transit There's nothing you need to do. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
Hi, > On 1 May 2020, at 20:57, Станислав wrote: > > what could it mean > > May 01 13:47:02.000 [warn] parse error: Malformed object: missing object end > line > May 01 13:47:02.000 [warn] Unparseable microdescriptor found in download or > generated string Where is it happening? Client or relay? Can you share a few more log lines? If it's a relay, maybe your connection just got cut off. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Multiple obsf4 Bridge Relays on macOS
Hi, > On 15 Apr 2020, at 01:45, Wilton Gorske wrote: > > Secondly, and mainly, I am working on setting up ten obsf4 bridge relays > on macOS and keep running into port issues, so I'm hoping to get some > general advice and guidance about how to set this up in the absence of > updated macOS tutorials online. Thanks for running Tor bridges! > These bridge relays are going to run on one macOS server. Knowing that > they can each have their own dedicated IP address, could someone advise > how to best set up these multiple obsf4 bridge instances so each can be > run (tor -f /usr/local/etc/tor/torrc.1, torrc.2, torrc.3, etc...) under > one non-root user It's slightly safer to run each instance under its own user. Then the keys for each instance aren't available to the other instances. You might find Debian's tor-instance-create script useful: https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create In particular, you can have a defaults torrc for each instance, and then just change the addresses and ports in each instance's torrc. > with only two public ports open on the data center > network (80 and 443)? I'm getting stuck at the port reachability phase, > and even more so when trying to run multiple instances with > forwarding/binding warnings. > > The Application Level Firewall allows certain granted programs > (tor/tor-gencert/tor-print-ed-signing-cert/tor-resolve/torify/obfs4proxy) > the ability to open or accept a network socket. By editing the macOS > network system settings to route port 80 to 9005, and noting ORPort 80 > NoListen ORPort 0.0.0.0:9005 NoAdvertise in the torrc, that works > correctly (including routing 443 for obfs4proxy). Running a second > instance is where it seems to break down. Is there a way to have > multiple tor instances sharing a port? No, tor doesn't support port multiplexing across multiple tor processes, Instead, tor automatically multiplexes multiple clients over the same port, without any special configuration on the server. > My guess is the main issue is that at the system routing level, I need a > way to note each IP and port so it goes to the right tor instance. > Currently, the forwarding is set up like: > rdr pass on en1 inet proto tcp from any to any port 80 -> 127.0.0.1 port > 9005 > I'm guessing I need some way to designate IP XX.XXX.XX.120 -> port 9005 > (torrc.1), XX.XXX.XX.121 -> port 9006 (torrc.2), XX.XXX.XX.122 -> port > 9007 (torrc.3), etc. Is that correct? Yes, that sounds sensible. > A copy of my notes and configurations so far can be found here: > http://5jp7xtmox6jyoqd5.onion/p/ISjeXEW-vt8H1s89bwSW > > Please feel free to make suggestions or edits directly in that etherpad. > I'm sure there are multiple ways to do this, but I definitely want to > make sure I am using the most secure method as opposed to the easiest or > quickest... Thanks for any help in advance. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Low observed bandwith
Hi, > On 12 Apr 2020, at 10:10, Mario Costa wrote: > > I’m running a guard relay from my home connection on a Raspberry Pi 4. My > internet connection is 1000/100 Mbps, and I thought I’d allocate half of the > upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, > because I thought that Tor would upload 5 MB/s and download 5 MB/s. You have an asymmetric connections and Tor is a relay network. So your relay's speed will be limited by the slowest of your upload and download. Tor also assumes your connection is full duplex. (That is, there are separate limits of 10 MB/s up and 10 MB/s down.) You should set rate to the highest sustained bandwidth you're happy for Tor to use. Tor could use that much bandwidth for seconds or hours. That bandwidth should be lower than your connection bandwidth. (The minimum of your upload and download.) > However, the maximum observed bandwidth was always about 6 MB/s. I’d like to > know what could cause this low observed bandwidth. I don’t think it’s the > Raspberry Pi, because CPU usage is always low and it has a Gigabit connection > to the router. Where are you seeing this observed bandwidth? Tor reports its observed bandwidth over the busiest 10 second period each day. 60% of the rate is actually a pretty high load, because Tor is a low-latency network. (Once utilisation gets over around 10%, latency starts increasing.) If your connection is a high latency connection, Tor may send bandwidth to lower-latency connections. You can read a similar thread here: https://lists.torproject.org/pipermail/tor-relays/2020-April/018348.html > The router itself easily reaches Gigabit speeds, so 10 MB/s should be a > breeze. Could it be the number of connections? nyx indicates that the > connections are always about 4000. If this is the case, how can I know if the > connections bottleneck is the router or the Raspberry Pi? 4000 seems pretty normal. There are only around 6000 relays. Check your tor, kernel, and router logs for TCP warnings? > Additionally, I’d like to ask for a rule of thumb for setting the > RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using > the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of > time, but as I already explained I’m never seeing such speeds. Setting your burst higher than your connection speed can cause latency or packet drops. Tor will allocate less bandwidth to slow or unreliable relays. You won't see the burst in Tor's observed bandwidth. The burst is over 1-2 seconds. The rate is averaged over a few seconds. Observed is over 10 seconds. Tor will compensate for a burst by having a few slow seconds afterwards. Set the burst to the highest speed you ever want the relay to use over 1-2 seconds. The burst should be equal to or lower than your connection speed. (In your case, the lowest of your upload and download speed.) > For reference my relay’s fingerprint is > F942EE73F1B8E39125F617FA85E80E4C9E540A2E. If you want Tor to use more bandwidth, try setting rate and burst to 10 Mbps. That way, you won't be causing congestion or packet drops. You may have to wait for a few weeks or months for your bandwidth to stabilise. https://blog.torproject.org/lifecycle-new-relay T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Advertised Bandwidth vs. RelayBandwidthRate
Hi, > On 8 Apr 2020, at 16:04, petra...@protonmail.ch wrote: > > So, could it be that there is just a wording issue on tor-metrics - to me > "observed" and "advertised" bandwidth are two different things but they seem > to be the same on tor-metrics. I think I do understand the observed bw, > however, still struggle to understand the advertised bw. The advertised bandwidth is the bandwidth the relay is capable of sustaining: https://metrics.torproject.org/glossary.html#advertised-bandwidth In practice, it's the minimum of the rate, burst, and observed. You can find all their definitions in the metrics glossary. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Doubt related to Bridge relay
Hi, > On 8 Apr 2020, at 04:05, Imre Jonk wrote: > >> On Mon, 2020-04-06 at 11:07 -0500, Ismael Castro wrote: >> 1. Can I use tor browser from the same computer the bridge relay node >> is set up? Navigation will remain anonymous (at least similar than >> when using only tor browser)? > > You certainly can, the Tor Browser software will still be picking > three-hop circuits through regular (non-bridge) relays. Your traffic > therefore won't loop around and back through your bridge or something. > > If you were to run a regular relay on your computer, then you should > consider telling Tor Browser to avoid building circuits through your > own relay. You can use the ExcludeNodes option for this, and maybe > StrictNodes as well if you want to be extra safe. You can set these > options in Tor Browser's torrc file. Tor automatically detects its own IP address, and avoids nearby relays. So you shouldn't need to modify Tor Browser's config. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit stops after one year, then again after few days
Hi, > On 7 Apr 2020, at 21:34, ylms wrote: > > As written above, I run an Exit (for many years, with the current setup > since 04.2019) but on 30. March 2020 it stopped, I was unable to > determine any reason. Have you checked tor's logs? They are usually in /var/log/tor/log If you have logrotate configured, they might have already been deleted, because 30 March is more than 1 week ago. > So I installed updates and since there were some Kernel updates I also > rebooted the machine. The Exit was back up and ran again till ~36h ago. > Same situation again, I have no idea why it stopped. > > I now activated "Log notice syslog", I think this was in the standard > torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, > but there is not entries in journalctl. Only Start/Stop/Reload events > are shown in the journal for unit tor.service since 100 day ago. Have you tried reading /var/log/sys log directly? > Can someone help me to troubleshoot this problem, could the fingerprint > be blacklisted? In this case would the Exit come back up running for a > few days as described above? Most of the time, blacklisting just makes Tor log a message in its logs. And the directory authorities stop publishing the relay in the consensus. (We haven't made any changes to required protocols recently. If we do, very old Tor versions may shut down.) Here's what we need to know to be more helpful: * your relay fingerprint * your Tor version * tor's logs when it shuts down T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Advertised Bandwidth vs. RelayBandwidthRate
Hi, > On 7 Apr 2020, at 19:56, petra...@protonmail.ch wrote: > > > Hello all - I see a constant mismatch of my relay regarding the Advertised > Bandwidth vs. the defined and available RelayBandwidthRate. > > Tor metrics usually only shows around 1.3 MiB/s as Advertised Bandwidth > (Bandwidth rate: 3 MiB/s, Bandwidth burst: 6 MiB/s). > > The torrc config defines: > RelayBandwidthRate 24 Mbit > RelayBandwidthBurst 48 Mbit > > So everything looks fine, except the Advertised Bandwidth seems to be too > low. Fingerprint is 605EE4375EE4C38215C8949F5808863749FD4F4A and there is > plenty of bandwidth available (1 Gbps link). The connection is up-and-running > perfectly fine without any issues or interruptions for at least a month. > > Any idea, why the Advertised Bandwidth is so low? On Relay Search, the Advertised Bandwidth is made up of 3 different bandwidths. For your relay, they are: Bandwidth rate: 3 MiB/s Bandwidth burst: 6 MiB/s Observed bandwidth: 1.3 MiB/s You can see these details by clicking on the Advertised Bandwidths figure on: https://metrics.torproject.org/rs.html#details/605EE4375EE4C38215C8949F5808863749FD4F4A The observed bandwidth is the maximum bandwidth peak your relay has seen. It's updated each day. Tor is a low latency network, so it's normal for relays to be loaded at 10-50% of their capacity. (Congestion increases latency.) If you'd like your relay to get more traffic, please increase your RelayBandwidthRate and RelayBandwidthBurst. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Low bandwidth
Hi, I'm cc'ing the network health team, so they are aware of this issue. >>> On 30 Mar 2020, at 23:00, ha3ks ha...@protonmail.com wrote: >>> my relay dropped nearly all it’s bandwidth about a month ago, checking over >>> it I can see 3 of the dir auths have given it a low consensus weighting, >>> would that cause low bandwidth numbers? >>> I checked my ufw in Ubuntu and it’s allowing 443 and 80. >> >> Date: Tue, 31 Mar 2020 09:44:41 +1000 >> From: teor t...@riseup.net >> >> I have seen similar reports from a few other relay operators. >> >> What is your relay fingerprint? >> >> Have you followed the troubleshooting instructions here: >> https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow > > On 31 Mar 2020, at 20:46, ha3ks wrote: > > The fingerprint is - 6E1DA4C0B0C05FB721B42329C47A20DA22908AEB > > I have followed some of this yes, though its a little over my head I have opened a ticket in sbws to follow up this issue: sbws measures some relays 100x lower than Torflow https://trac.torproject.org/projects/tor/ticket/33775 It could be related to these other issues: sbws does not detect changes in descriptor bandwidth values https://trac.torproject.org/projects/tor/ticket/30733 sbws bandwidth scans should require a minimum exit bandwidth https://trac.torproject.org/projects/tor/ticket/33009 T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
Hi, Just letting you know that I can't really help here, for a few reasons. Here's some general feedback: I don't think we can support using Tor Browser to auto-update a relay. It seems really complicated. As we've spoken about previously, you might be better using a package manager, like Chocolatey: https://chocolatey.org/search?q=Tor (If you need help using Chocolatey, please find a Chocolatey-specific help forum. I don't think anyone on this list has experience.) I can't see your full logs in the screenshots. Please paste them in your email, or use a pastebin like https://paste.debian.net I'm also struggling to keep up with your emails, because you keep sending duplicate emails. That's a bit confusing. T >> On 31 Mar 2020, at 19:10, Keifer Bly wrote: > > Hey, so here is something I have noticed. I ran tor.exe via CMD (Windows > version of terminal). I wrote this to the torrc: > > SOCKSPort 0# no local SOCKS proxy > > ORPort 80# public bridge must have an open ORPort > > ExtORPort auto # configure ExtORPort for obfs4proxy > > ExitPolicy reject *:* # no exits allowed > > BridgeRelay 1 # relay won't show up in the public consensus > > PublishServerDescriptor 1 # publish to the bridge authority > > > # use obfs4proxy to provide obfs4 on port 9003, 443 > > ServerTransportPlugin obfs4 exec > C:\Users\keife\Desktop\TotBrowser\Browser\TorBrowser\Tor\PluggableTransports\obfs4proxy.exe > > ServerTransportListenAddr obfs4 127.0.0.1:8080 > > ContactInfo keifer@gmail.com > > Then did tor.exe -f torrc.txt (including the file directories and all) and it > worked, tor launched and red the configuration file, but when using the built > in torrc file, this in turn caused tor browser to crash on start, see the > screenshot: > > However, when I created my own torrc.txt file then started from there, it > worked, and tor browser also did not crash on start: > > Though it did get stuck on loading (probably due to the tor process already > being in use in all). This is problem attic is what I am trying to do is have > tor browser start, automatically installing updates (thus automatically > updating tor and obfs4 as a result) then start the bridge). I guess I would > want to have a torrc that could not be overwritten anyway, but having tor > browser and tor running via terminal seemed to cause issues. Is there a way > to configure tor browser to automatically install updates on start? If so, I > could write a script to start tor browser, close it after a few minutes then > start the relay when windows loads possibly. > > Thank you. > > > --Keifer > > From: teor > Sent: Monday, March 30, 2020 2:24 AM > To: tor-relays@lists.torproject.org > Subject: Re: [tor-relays] Possible to run a tor bridge/relay via tor browser? > > Hi, > > > On 30 Mar 2020, at 18:11, Keifer Bly wrote: > > The file directoy is named “totbrowser” where tor browser is installed. Thank > you. > > Sent from Mail for Windows 10 > > From: Keifer Bly > Sent: Monday, March 30, 2020 1:10 AM > To: tor-relays@lists.torproject.org > Subject: RE: Re: [tor-relays] Possible to run a tor bridge/relay via tor > browser? > > So, I edited the tor install directory so there are no spaces in it, then > tried no quotes, single quotes, and double quotes, and it still crashers on > start. I wonder why: > > … > > # use obfs4proxy to provide obfs4 on port 9003, 443 > > ServerTransportPlugin obfs4 exec > 'C:\Users\keife\Desktop\TotBrowser\Browser\TorBrowser\Tor\PluggableTransports\obfs4proxy.exe' > > … > > This is a directory path: > > ServerTransportPlugin obfs4 exec C:\Users\keife\Desktop\Tor Browser test > relay\Browser\TorBrowser\Tor\PluggableTransports > > You need to: > * give tor the path to the obfs4 executable file > * quote the path, because it contains spaces > > It's important that you follow these instructions precisely: > * give tor the path to the obfs4 executable file > * quote the path with double quote characters "like this" > * do not delete spaces, the path without spaces is a different path > > If that doesn't work: > * double each backslash character like this: \\ > > If that doesn't work: > * run tor in a terminal, and send us your logs > > We seem to be reaching the limits of your experience. > > Perhaps there's some other way you can learn about file > paths on Windows and Linux? And processes? And > software updates? > > I'm not sure we're the best people to learn system > administration from. Perhaps a beginners sysadmin >
Re: [tor-relays] Low bandwidth
Hi, > On 30 Mar 2020, at 23:00, ha3ks wrote: > > my relay dropped nearly all it’s bandwidth about a month ago, checking over > it I can see 3 of the dir auths have given it a low consensus weighting, > would that cause low bandwidth numbers? > > I checked my ufw in Ubuntu and it’s allowing 443 and 80. I have seen similar reports from a few other relay operators. What is your relay fingerprint? Have you followed the troubleshooting instructions here: 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
Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
Hi, > On 30 Mar 2020, at 18:11, Keifer Bly wrote: > > The file directoy is named “totbrowser” where tor browser is installed. Thank > you. > > Sent from Mail for Windows 10 > > From: Keifer Bly > Sent: Monday, March 30, 2020 1:10 AM > To: tor-relays@lists.torproject.org > Subject: RE: Re: [tor-relays] Possible to run a tor bridge/relay via tor > browser? > > So, I edited the tor install directory so there are no spaces in it, then > tried no quotes, single quotes, and double quotes, and it still crashers on > start. I wonder why: > > … > > # use obfs4proxy to provide obfs4 on port 9003, 443 > > ServerTransportPlugin obfs4 exec > 'C:\Users\keife\Desktop\TotBrowser\Browser\TorBrowser\Tor\PluggableTransports\obfs4proxy.exe' > > … > > This is a directory path: > > ServerTransportPlugin obfs4 exec C:\Users\keife\Desktop\Tor Browser test > relay\Browser\TorBrowser\Tor\PluggableTransports > > You need to: > * give tor the path to the obfs4 executable file > * quote the path, because it contains spaces It's important that you follow these instructions precisely: * give tor the path to the obfs4 executable file * quote the path with double quote characters "like this" * do not delete spaces, the path without spaces is a different path If that doesn't work: * double each backslash character like this: \\ If that doesn't work: * run tor in a terminal, and send us your logs We seem to be reaching the limits of your experience. Perhaps there's some other way you can learn about file paths on Windows and Linux? And processes? And software updates? I'm not sure we're the best people to learn system administration from. Perhaps a beginners sysadmin mailing list, chat, or course could help? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
Hi, >> On 30 Mar 2020, at 16:03, Keifer Bly wrote: > How would I specify the path to the binary? Thanks. This is a directory path: > ServerTransportPlugin obfs4 exec C:\Users\keife\Desktop\Tor Browser test > relay\Browser\TorBrowser\Tor\PluggableTransports You need to: * give tor the path to the obfs4 executable file * quote the path, because it contains spaces T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Moving my obfs4 bridge from tor expert bundle to Debian, and have some questions. Thanks.
Hi, >> On 30 Mar 2020, at 15:45, Keifer Bly wrote: > Mar 29 17:00:47.000 [notice] You are running a new relay. Thanks for helping > the Tor network! If you wish to know what will happen in the upcoming weeks > regarding its usage, have a look at > https://blog.torproject.org/blog/lifecycle-of-a$Mar 29 17:00:47.000 [notice] > It looks like I need to generate and sign a new medium-term signing key, > because I don't have one. To do that, I need to load (or create) the > permanent master identity key. If the master identity key was not$Mar 29 > 17:00:47.000 [notice] Your Tor server's identity key fingerprint is 'torland > 7DBC1875771B54F4FE40EB376460EF557EE9E884' > Mar 29 17:00:47.000 [notice] Your Tor bridge's hashed identity key > fingerprint is 'torland 780F4E3ADBC574A63CE8155C0911E0A06BA3331D' Wherever you put the keys, it wasn't where Tor was expecting them. These logs show that your bridge couldn't find any keys. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Moving my obfs4 bridge from tor expert bundle to Debian, and have some questions. Thanks.
Hi, > On 30 Mar 2020, at 13:45, Keifer Bly wrote: > So I am switching the OBFS4 bridge I was running via Tor Expert Bundle on > Windows 10 over to running it via Debian app for Windows 10. > > This app is on the Windows store at > https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?activetab=pivot:overviewtab > > Essentially, it is an app that lets you run Linux packages on Windows. I made > the switch so that I could keep tor and obfs4 up to date using unattended > upgrades. > > However, for some odd reason, despite the fact I backed up the tor identity > keys and pasted them into the keys directory when I moved over, the bridge is > still generating new keys on startup. I copied the key files from my expert > bundle bridge to > > /var/lib/tor/keys directory in the Linu terminal, I copied all of the files. > It’s a bridge so no big deal I guess, but wonder why that is happening. > Please show us the tor logs. > https://metrics.torproject.org/rs.html#details/780F4E3ADBC574A63CE8155C0911E0A06BA3331D > > And, I tested to see of unattended upgrades was working correctly after > configuring it with these instructions: > > https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpdates > > > > And got this the attached photo as a result, does this mean it is keeping tor > and obfs4 up to date? > > tor update test.PNG > Please use a pastebin for logs, or paste the text in your email. https://paste.debian.net is good. Looks like updates aren't working, do you see the line that says: Sanity check failed T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BadExit
Hi Georg, > On 27 Mar 2020, at 22:40, Georg Koppen wrote: > >> (If the DNS for the site they are testing has both IPv4 and IPv6, then >> the outcome will depend on their tor version and config. 0.4.3 and >> later will prefer IPv6 by default.) > > Not sure what Arthur is running but I am just using what Debian ships on > the box I run the tests, which is currently 0.3.5.8. I guess it might be > worth thinking about switching away from that. Maybe tracking and using > the version Tor Browser ships is smarter? I think any supported Tor version is ok. But yes, using the same version as Tor Browser users could be helpful. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
Hi, > On 28 Mar 2020, at 05:14, Keifer Bly wrote: > > ServerTransportPlugin obfs4 exec C:\Users\keife\Desktop\Tor Browser test > relay\Browser\TorBrowser\Tor\PluggableTransports You might need to quote the spaces in this path. And specify the path to the binary, not the directory. Try running tor in a terminal, so you can see the logs. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Problem with ubuntu 18.04 x386
Hi, > On 30 Mar 2020, at 12:46, Nuno Rego wrote: > > I had a similar problem on a server and solved it by disabling IPV6. Yes, a lot of people struggle to configure IPv6. Or their providers don't route IPv6 correctly. We're working on some changes to tor, to help diagnose IPv6 connection issues. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Problem with ubuntu 18.04 x386
Hi, > On 30 Mar 2020, at 12:45, Francisco wrote: > > Hi, sorry for that, I'm sending more information now: > > Tor version: > Tor 0.4.2.7 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib > 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. > > The log when I try to restart the service (sudo systemctl restart > tor@default) : > Job for tor@default.service failed because the control process exited with > error code. > See "systemctl status tor@default.service" and "journalctl -xe" for details. Thanks for these extra systemd logs. But we need to see the detailed tor logs. Try /var/log/tor/log, or similar? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BadExit
> On 27 Mar 2020, at 20:42, teor wrote: > >>> On 26. Mar 2020, at 15:06, ger...@bulger.co.uk wrote: >>> >>> "btw, you need to have at least port 80 and 443 … port 80 is missing …" >>> >>> It there. But to a /8 area IPV4, all IPv6 >>> > The Exit flag only request one IPv4 /8 : > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2628 Correction: The Exit flag only *requires* one IPv4 /8. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BadExit
Hi, > On 27 Mar 2020, at 02:00, niftybunny > wrote: > > My bad. Never seen this before. I there a good reason for the accept > 133.0.0.0/8:80 ? > >> On 26. Mar 2020, at 15:06, ger...@bulger.co.uk wrote: >> >> "btw, you need to have at least port 80 and 443 … port 80 is missing …" >> >> It there. But to a /8 area IPV4, all IPv6 >> >> I have not changed my exit policy for years. Port 80 is there, just limited >> to a /8 network and all IPv6 addresses port 80 allowed. >> 443 all there IPv4 and IPv6 >> >> Testing seems to be exiting OK, but badexit tag still there. The Exit flag only request one IPv4 /8 : https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2628 But if the network health team is testing a different IPv4 /8, then your relay might appear down. (If the DNS for the site they are testing has both IPv4 and IPv6, then the outcome will depend on their tor version and config. 0.4.3 and later will prefer IPv6 by default.) T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New relay
Thanks! Looks like a small bandwidth rate, did you really mean 300 kilobytes per second? T -- teor -- > On 26 Mar 2020, at 04:59, William Pate wrote: > > > Set up another relay (this time on Raspberry Pi 4): > https://metrics.torproject.org/rs.html#details/BD187CF1B44A84EC7DD1BC2AC9C4F7DE23D16619 > > William Pate > willp...@pm.me > 512-947-3311 > inadequate.net > > > ___ > 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] Possible to run a tor bridge/relay via tor browser?
Hi, > On 25 Mar 2020, at 06:35, Keifer Bly wrote: > > So I am currently running an OBFS4 bridge here: > > https://metrics.torproject.org/rs.html#details/386E99371B8CD938248940B754F16AAC54B5712B > > It is being done via the TOR expert bundle on Windows 10. I am wondering, > would it be possible to run the bridge via the tor that comes with the tor > browser? This way, everything (tor, obfs4, etc). could be automatically > updated for the bridge just when updating tor browser. Probably. Why don't you try it, and let us know how you go? T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] When will my relay gain the stable flag again?
Hi, > On 19 Mar 2020, at 02:51, nottryingtobel...@protonmail.com wrote: > > My relay (903CA67D0DEB74CFBB01432840A26CB8C6C18FDF) is ~2 years old. > Recently, I had a series of network issues that took my relay offline for > unexpectedly long times. When it has gone offline before and lost the stable > flag, it usually took only a couple days to pick it back up again. It is > approaching 8 days since I finally got things resolved with a new router, but > still no stable flag. I also used to have the guard flag, but I know I can't > get back to guard status without the stable flag. Your relay has the stable flag in the latest consensus. It would be great if we could show relay operators the progress towards each flag. I've opened a ticket, but it turns out it's a bit complicated: https://trac.torproject.org/projects/tor/ticket/33649 T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving Relay IPv6 - RIPE Grant
Hi, Sorry I missed these emails. I was on leave around Christmas, and then I was focused on the Relay IPv6 grant when I got back. > On 22 Dec 2019, at 06:28, ILikeTor wrote: > > I was wondering how you will implement IPv6-only relays. IPv6-only relays are out of scope for this sponsor. We can't add IPv6-only relays, until we have more dual-stack relays. (Or until researchers tell us how to get good user anonymity in non-clique networks.) So this sponsor is focused on adding more dual-stack relays. > What limits > will you set on how many relays can be per /(something)? Will you allow > only two relays per /64, for example? Do you have any plans for that > already? We have a draft proposal: * AuthDirMaxServersPerIPv6Site counts relays in a /64 * We will analyse the current number of relays in each /64 on the tor network, to choose a default value * We expect the default to be between 4 and 50 https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1125 This is an optional change, so we might not do it as part of this sponsored work. (The sponsored work goes for the next 6 months.) > On 22 Dec 2019, at 07:26, NOC wrote: > > On 21.12.2019 21:28, ILikeTor wrote: >> [..] >> only two relays per /64, for example? Do you have any plans for that >> already?[..] > That is already a bad practice for IPv4 and is impossible to do for IPv6. > There are server providers which give you a single IPv6 address (/128) and > there are some which give you /48. And because some give Additional IP space > like candy this limit is dead with IPv6. And I would be very happy to have > this restriction to be removed for IPv4 too because it makes no sense till > there is proper multi threading, it sucks to waste IP space just because of > this nonsense. I would like better multithreading in Tor. We have designs, but we need more funding (or volunteers) to do projects like this. One of the tricky parts of multithreading is making all of tor's code more independent. That's hard work! I would also like to have a better way to resist sybil attacks than using IP addresses. We need help from researchers to come up with better designs. You can ask the new network health team if you'd like to know more about on resisting bad relays on the network: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkHealthTeam We also might need a design where new relays go in a separate document, until they have been checked for bandwidth (and any other automatic checks we can do). T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] obfs4 in Tor Expert Bundle (was Re: Stable flag not appearing on my bridge.)
Hi, > On 4 Mar 2020, at 04:21, Keifer Bly wrote: > > Thx. I was wondering if obfs4 could be included in the same file directory to > download tor expert bundle from? Sorry, I didn't see your question until now. Please start a new thread for new questions! The Tor Browser team packages the Tor Expert Bundle. They should be able to answer your question. I've cc'd them on this email. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Migrating to a new data center
Hi Marco, > On 18 Mar 2020, at 11:09, li...@for-privacy.net wrote: > > Funny pictures, nice stuff. > Where can you get the eff.org and Tor stickers that are under the USB ports? Please contact "tshirt at torproject dot org" to get stickers sent to you. If you include your relay fingerprints, and tshirt size, they might send you a tshirt as well. (Most long-term relay operators can get a tshirt, as a thank you for running a relay.) I'm not sure about EFF, you'll have to ask them. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Consensus Weight Dropping/Authority Issues?
Hi John, > On 7 Jan 2020, at 22:57, John Ricketts wrote: > > I have been watching the consensus weight and bandwidth of all of my 50 exit > nodes drop consistently over the past few months. I have not made any > hardware changes in my data center and actual customers have not complained > about any performance issues. > > Operating systems and Tor version are up to date. I'm dedicating a > significant portion of bandwidth to these nodes - 10gbit/sec. > > Am I having issues with the bandwidth authorities? > > I'm growing frustrated with my performance to resources ratio, I should be > doing far better than this. Did you ever find an answer here? What have you analysed? Have you tried any config changes? Can you tell us which directory authorities are measuring your relays lower than they were before? The most likely scenarios are: * Routing changes between your relays and the bandwidth authorities * The Torflow to sbws transition * Did you upgrade your tor version? Most of the network upgraded to tor 0.4.1 and 0.4.2 recently: https://metrics.torproject.org/versions.html?start=2019-09-01=2020-03-16 Did the consensus weight drop first, or did the observed bandwidth drop first? You've probably read this wiki page before, but just in case: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow#FindingOutwhatisLimitingaRelay T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay
Hi, >> Post the entire file without shortening or removing any line. If it complains >> about parse error, there must be something wrong in it, but you don't notice >> or don't think it is wrong. People on the mailing list can check if it's ok, >> but again only if you post the entire file (copy-paste or attach). > > С уважением, > Станислав > > There could be a few things wrong here. Try setting ServerDNSResolvConfFile to /dev/null, or a world-readable empty file, and see if your problem goes away. If it does, here are some common issues to check: What are the permissions on /etc.resolv.conf ? Can the tor user read the file? Is the file a symlink? (macOS does this, not sure if some Linux distros do as well) Are there any hidden characters in the file? Does it use Unix newlines? Tor uses libevent's evdns_base_resolv_conf_parse() to parse the file. https://libevent.org/doc/dns_8h.html#a7e3a053e25ae7c045944a5db0947babb How old is your version of libevent? T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] website support
Hi, There are a few different tools that are publicly available. Here are the ones that most relay operators use: > On 12 Mar 2020, at 18:17, potlatch wrote: > > I have a few exit relays on the Tor network but generally I'm flying blind. > Why isn't there an index of tor relays that can be accessed? Relay search is a general tool that lists relays and bridges: https://metrics.torproject.org/rs.html Consensus health is a diagnostic tool that lists detailed relay vote info: https://consensus-health.torproject.org/#relayinfo > Why isn't the tor access via it's website able to deliver me to the software > pages? I'm not sure what you mean here, can you tell us what you've tried? I just accessed the tor download page over tor, with 2 clicks from the www page: https://www.torproject.org/download/tor/ > Why is the graphic display of tor connections over 5-years old? I thought > tor was expert in data delivery and security. There are a bunch of connection statistics that update every day: https://metrics.torproject.org/connbidirect.html https://metrics.torproject.org/torperf.html Maybe you're talking about these charts? Country Cartogram, Oxford Institute, 2012-2013 https://metrics.torproject.org/oxford-anonymous-internet.html Data Flow, Uncharted, 2007-2016 https://metrics.torproject.org/uncharted-data-flow.html I'm not sure if we have the tools to update them ourselves. Have you tried contacting the authors? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Stable flag not appearing on my bridge.
Hi, > On 26 Feb 2020, at 10:16, Keifer Bly wrote: > > So my bridge at > https://metrics.torproject.org/rs.html#details/386E99371B8CD938248940B754F16AAC54B5712B > > Is not getting the stable flag despite being running for several weeks with > only minor interruption in between. Is the stable flag no longer used for > bridges? Thank you. Tor clients do not use the Stable flag to select bridges. In fact, Tor clients don't have access to the bridge networkstatus, so they can't possibly use any of the bridge flags you see on Relay Search. I've opened this ticket, so we can make that clearer on relay search: https://trac.torproject.org/projects/tor/ticket/33493 T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why MyFamily?
Hi, I've gone a few emails back up the thread, because the risk analysis is missing some really important factors. And just some reminders: Some users depend on the tor network for their safety. Relay operators take some risks, but we do our best to reduce those risks. MyFamily is about user and operator safety. We pay more attention to arguments based on safety. >> On 22 Feb 2020, at 23:02, Michael Gerstacker >> wrote: >>> > So for what reason do i set the MyFamily option beside making a Hidden >>> > Service Guard discovery attack more easy? >>> >>> - risk reduction for tor users >>> MyFamily declarations allow the tor client software to automatically detect >>> relay families when creating circuits to >>> avoid using multiple relays from the same operator in a single circuit. >> >> This should not matter if the operator is not malicious and like i already >> said an malicious operator will not use the same contact info or relay name. >> >> - reducing the risk for tor users that might become victims if some operator >> gets compromized (with all its relays) > > This is a reason i can understand. > Not sure how much that would really help in practice but i can understand it. In practice, relay operators become targets for compromise when they don't set MyFamily. Because those relays can be used to attack a Tor users. If relay operators correctly set MyFamily, then an attacker needs to compromise multiple operators to see a single user's traffic. In this case, it doesn't matter if the operator is malicious. >> - transparency >> Every relay operator should declare their relay group to allow everybody to >> measure their network fraction (Sybil detection). > > Should... > But i understand this one too. > But as long as my family is still a small one with only one exit compared to > others i am not a Sybil attack risk and even if i would would i get any > special treatment then? It doesn't matter how small your relays are. Some clients will choose your relays as guards. You're putting those users in danger. >> - risk reduction for relay operators >> MyFamily also provides risk reduction for operators since they are less >> valuable as an attack target >> if they can not technically be used for e2e correlation attacks > > I think this is similar to your first point but i think that should be the > operators choice if he want to take steps against this case. There's also a network effect here. If almost all operators set MyFamily, then the Tor Network becomes a less valuable target for attacks. So attackers use other methods, like attacking Tor Browser, or offline attacks. But if a lot of operators don't set MyFamily, then attackers develop tools and techniques to attack the network. Then they can repeat these attacks easily whenever they get a new target. I guess you could call that a market effect. So if you're not going to set MyFamily for yourself, do it for Tor users, and do it for Luther relay operators. We prioritise the safety of users and relay operators here. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why MyFamily?
Hi Michael, > On 22 Feb 2020, at 11:30, Roman Mamedov wrote: > >>> I already knew that not all of my relays have a correct MyFamily setup >>> because as long as i am not sure if they will stay i usually dont >>> include them in MyFamily because it is a pain to edit every torrc >> >> Yes, manually managing MyFamily is a pain with that many relays. >> It is best to automate it so you don't have to worry about it >> no matter how long your relays might run. > > What helps greatly is that the MyFamily string on each relay doesn't have to > list all OTHER relays, it can list just ALL relays, including that one, i.e. > simply be the same on all relays. This should vastly simplify any automation > that you might think of. Also, it's totally ok to list old relay keys in MyFamily, even if those relays aren't running any more. Tor clients ignore down relays, so you can clear out old fingerprints whenever you have time. Tor also supports "%include (path)" lines in torrcs, which include the contents of the file at that path. So you can put all your relay fingerprints in a file, scp it to your relays, and then issue a HUP (to reload the config). (If you have logrotate installed, it should issue a HUP every day to rotate tor's logs. So maybe you can skip that step.) It's a bit of a pain, I know. I've done it with about 20 relays before. We'd like to have a better system, maybe with a single shared key for each family. But that's a long-term plan. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New relay on dynamic IP address
Hi, > On 21 Feb 2020, at 20:21, Mario Costa wrote: > > Just reporting back after some time. Today I noticed that my relay running > at home with a dynamic IP got a guard flag again. So it’s totally possible > for a relay to become a guard even after the authorities notice that it has a > dynamic IP address.It must be noted though that the IP address didn’t change > since it lost the guard flag the first time. > > It looks like I had it wrong when I concluded that after the first IP change > the relay wouldn’t became a guard anymore. > > For reference, the relay fingerprint is > F942EE73F1B8E39125F617FA85E80E4C9E540A2E. The guard flag depends on uptime and bandwidth. (IP address changes create downtime and reset bandwidth.) I really wouldn't worry about it too much. Clients have multiple guards, they'll switch to another one if yours goes down. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 100% CPU load on Windows Server 2019
> On 21 Feb 2020, at 20:21, Michael Gerstacker > wrote: > >> > On 18 Feb 2020, at 06:10, Michael Gerstacker >> > wrote: >> > >> > Once the consensus diffs are processed the load drops to normal. >> > After some time without anything noticeable for me in the debug logs the >> > CPU suddenly jumps to 100% again and stays there till another consensus >> > diffs are arriving. >> > >> > Its not as worse as it was the first two days where i had 100% CPU load >> > half of the time but i still have this about 10-15 times a day for a few >> > seconds or minutes each. >> > For the next few minutes after the CPU dropped to normal the throughput is >> > close to zero so this cant be good for clients. >> > >> > It would be nice to have a fix in 0.4.4 stable or earlier so that i can >> > decide if i want to buy a Windows license key or rather shut it down. >> >> Does setting "DirCache 0" in your torrc resolve the issue? > > Yes it look like thats working. > I lost the Guard flag (like expected) but in the last 24 hours i had no > problems anymore. Ok, thanks, I've opened a ticket to implement this workaround, if we can't solve the underlying issue in the 0.4.4 release. >> There's a suggested patch on the ticket: >> https://trac.torproject.org/projects/tor/ticket/24857#comment:39 >> >> But we've had trouble getting people to help with Windows development >> and testing. >> >> Can you compile tor from source for Windows? > > i've never done that before. If there is a step-by-step guide it might be > interesting to learn. Alex has put together a guide for cross-compiling for Windows on Linux: https://github.com/ahf/tor-win32 >> Or if we get a fix merged into tor, can you install the Windows >> "Tor Expert Bundle" ? > > This should be no problem. > > I think i will keep the Windows setup at least for some time so if i can help > that way feel free to send me or point me to anything Windows related what > needs some testing in real world. Great, I've made a note on the ticket. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 100% CPU load on Windows Server 2019
Hi, > On 18 Feb 2020, at 06:10, Michael Gerstacker > wrote: > > Once the consensus diffs are processed the load drops to normal. > After some time without anything noticeable for me in the debug logs the CPU > suddenly jumps to 100% again and stays there till another consensus diffs are > arriving. > > Its not as worse as it was the first two days where i had 100% CPU load half > of the time but i still have this about 10-15 times a day for a few seconds > or minutes each. > For the next few minutes after the CPU dropped to normal the throughput is > close to zero so this cant be good for clients. > > It would be nice to have a fix in 0.4.4 stable or earlier so that i can > decide if i want to buy a Windows license key or rather shut it down. Does setting "DirCache 0" in your torrc resolve the issue? There's a suggested patch on the ticket: https://trac.torproject.org/projects/tor/ticket/24857#comment:39 But we've had trouble getting people to help with Windows development and testing. Can you compile tor from source for Windows? Or if we get a fix merged into tor, can you install the Windows "Tor Expert Bundle" ? It's built along with the Tor Browser alphas, so it might take a little while for each new version. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Would you place your secrets or in worst case make your life
Hi, A quick reminder to everyone on this list: this list is moderated. Please keep your replies helpful and on topic. > On 13 Feb 2020, at 22:05, zwiebeln wrote: > > depended on a network that is 21 percent controlled by a single person > that you don't know? > > https://nusenu.github.io/OrNetStats/allexitfamilies > > I think we should start an open debate on that fact, best ending up with > giving some recommendations. I am sure that question is relevant to > torproject.org as well. We've had similar questions a few times on this list. The most common answer is: "Let's encourage people to run more relays." Perhaps you could run more relays? Or ask for help improving your consensus weight? The operator of those relays is on this list, asks questions, and responds to emails. They've been helpful in the past. So please ask questions in a way that assumes good faith: https://en.wikipedia.org/wiki/Good_faith You'll be more likely to get a helpful answer. It's also important to keep network risks in perspective: * 99% of relays run Linux, and a significant number of those are Debian (or Ubuntu, or other derivatives) https://metrics.torproject.org/platforms.html * there is 1 bridge authority (100%), 6 bandwidth authorities (17%), and 9 directory authorities (11%) * the consensus algorithm tries to limit the risks of one directory authority influencing large parts of the tor network, and manual bridge distribution limits the impact of the bridge authority * the largest ASes have: * 23% of guards and 22% of middles (Hetzner) * 16% of guards and 12% of middles (OVH) * 10% if guards (Online) * 20% of exits (J P McQ) https://metrics.torproject.org/rs.html#aggregate/as So it's not really helpful to single out a particular operator or network. As far as I recall, the most widespread security issue that's happened to the network was the Debian OpenSSL bug: https://www.debian.org/security/key-rollover/ There are all kinds of risks that happen when a large part of the network has a similar setup: * relay operator compromise * AS operator compromise * platform compromise * observation of traffic via common network infrastructure * network availability * poor performance * poor bandwidth weights Tor relay consensus weights are determined by the bandwidth authorities, so we might also be seeing: * a bug in the bandwidth authority software (sbws or Torflow), or * a majority of bandwidth authorities configured in a way that concentrates bandwidth in particular areas. I've opened a ticket in sbws to track this issue: https://trac.torproject.org/projects/tor/ticket/33350 (Torflow is unmaintained, and we're planning to completely replace it with sbws in 2020 or 2021.) I'll also ask our new Network Health team to consider the risk of large operators and large ASes. Hopefully they can recommend some changes to the bandwidth authorities (or sbws maintainers). But ultimately, if we doubled tor's exit bandwidth, this issue would go away. That's the best solution to this problem. Again, please keep your replies helpful and on topic. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Fingerprint is marked rejected
Hi, > On 17 Feb 2020, at 00:54, LeoR wrote: > > I am waiting for the reponse from the people on the bad-relays list. I > provided FINGERPRINT and IP address of my relays. > > Specifically, I am managing the following: > > IPFingerprint > 3.225.115.238905EB77A63857E6EFCF04D734A547B0995D85C3B (previously > E7E2A76191500600982E8A0664DBDDE982F65265) > > It now has ContactInfo but it is still offline. Could a relay be banned for > omitting ContactInfo only? It looks like you missed my second question: > Here's a few things you can check right away: > * Did you set ContactInfo ? > * Did you set MyFamily ? Try setting MyFamily and ContactInfo on all your relays, and then writing another email to bad-relays. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Please help us find a working alternative to using MaxMind's GeoLite2 databases
Hi, > On 13 Feb 2020, at 03:14, niftybunny > wrote: > > Checking my relays its hard to tell what is correct. As a German IXC I do own > the IPs but the servers are in the Netherlands. If you prefer the ownership > of the IPs Maxmind is correct with Germany, if you prefer where the actual > servers are the new one is correct. Pick your poison :) At least the new one > has my new AS, so I am a happy bunny after all. There are often at least 2 correct answers for GeoIP, sometimes more: * the physical location of the server, * the business address of the data centre operator, * the business address of the owner or reseller of the server. Some servers and businesses have layers of owner/operator/reseller/ corporate subsidiaries, so it can get very complicated. I once operated relays that were obviously in Australia (because of the traceroute and latency), but were geolocated to the US, because their reseller was in the US. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is This Leap in Bridge Clients Normal
Hi, > On 11 Feb 2020, at 08:37, Eddie wrote: > > Hi, > > For about 6 weeks now, I've been running a couple of obfs4 bridges, one on > port 80, the other port 443. Up to yesterday, the port 80 one had seen zero > traffic, when this started to be reported: > > Feb 09 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 0 > unique clients. > Feb 09 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 533 > unique clients. > Feb 10 01:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 63 > unique clients. > Feb 10 07:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 212 > unique clients. > Feb 10 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 93 > unique clients. > Feb 10 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 61 > unique clients. > > Is this kind of sudden usage normal. Yes, we've seen it before. Either someone is changing IP address quite frequently, or an app is picking bridges, and sending them out to its users. > For the port 443 bridge, I have seen very little traffic at all, which > surprises me as I thought that obfs4 bridges on port 443 were highly sought > after. Each bridge is allocated to a separate distribution method. Some distribution methods are less popular than others. There is also a "reserve" distribution method. If someone harvests and blocks all the bridges using a distribution method, we can fix the issue, and then replace them with the "reserve" bridges. If you're not seeing the traffic you expect, you could run a few more bridges, on another IP or port? > A relay search for "OhNoAnother" will pull up the details. Thanks for running bridges! T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Fingerprint is marked rejected
Hi,
> On 10 Feb 2020, at 21:33, LeoR wrote:
>
> I am running a few Tor relays for more than 100 days.
> Since last Friday, I am getting the following message on each relay:
>
> [warn] http status 400 ("Fingerprint is marked rejected -- if you think this
> is a mistake please set a valid email address in ContactInfo and send an
> email to bad-rel...@lists.torproject.org mentioning your fingerprint(s)?")
> response from dirserver '171.25.193.9:443'. Please correct.
>
> The message above is also reported for other dirservers and prevents my relay
> for being online (they are all offline currently).
>
> I am just running Tor 0.4.2.6; no other activity is performed on any of my
> relays. I have already contacted the bad-relays list for the first relay
> offline;
What did bad-relays say in their response?
A lot of people on the bad-relays list work during the week, and are
offline on the weekends. (And lots of those people have multiple roles.)
So you might have to wait another day or two for an answer.
> afterwards, I realized that all my few relays are off-line after more than
> 100 days of normal activity.
>
> Do you have similar experience?
bad-relays can give you a specific explanation, because they manage
relay rejections.
We can try to give you some general help on this list.
Here's a few things you can check right away:
* Did you set ContactInfo ?
* Did you set MyFamily ?
For more details, see section 5 in:
https://community.torproject.org/relay/setup/post-install/
If you'd like more help, please let us know your relay fingerprints.
T
--
teor
--
signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Consensus Weight Dropping/Authority Issues?
Hi John, >> On 2 Feb 2020, at 14:15, John Ricketts wrote: >> >> I have been watching the consensus weight and bandwidth of all of my 50 exit >> nodes drop consistently over the past few months. I have not made any >> hardware changes in my data center and actual >> customers have not complained about any performance issues. >> >> Operating systems and Tor version are up to date. I'm dedicating a >> significant portion of bandwidth to these nodes - 10gbit/sec. >> >> Am I having issues with the bandwidth authorities? >> >> I'm growing frustrated with my performance to resources ratio, I should be >> doing far better than this. >> >> Please throw ideas at me - open to any ideas. > > On Feb 1, 2020, at 20:05, "starlight.201...@binnacle.cx" > wrote: > > The rating shift experienced by your relays and many others is likely a > consequence of the gradual phase-in of the SBWS scanner implementation in > place of TorFlow. I for one find SWBS unimpressive. There are known bugs in both bandwidth authority implementations, sbws and torflow. Here's a list of the critical sbws bugs: https://trac.torproject.org/projects/tor/query?status=!closed=~sbws-majority-blocker We're working on getting some funding to fix these bugs in sbws. (Torflow is very old and hard to install, most of its dependencies are unsupported. So we aren't tracking torflow bugs in detail any more.) I don't think we've added any sbws instances for a few months. And I haven't seen any specific evidence that sbws (or torflow) is responsible for these issues. If you give us a timeframe, we might be able to help more. It's also possible that there are more exits in the Tor network, or that the routing between the bandwidth authorities and your network has become slower. There are some other common explanations for slow relays, listed on this wiki page: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow You might find some of the tips on that page helpful. Also, if you can find some authorities that are giving your relays low measurements, we might be able to find out why. You can see a copy of all the bandwidth authority measurements here: https://consensus-health.torproject.org/consensus-health.html T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor version 0.4.0.x reaches end-of-life on 2020-02-02
Hi, > On 2 Feb 2020, at 23:55, nusenu wrote: > > Signed PGP part > Toralf Förster:> I do wonder if recent Tor clients do already prefer to not > choose EOL relays? > > Version information (or the recommended version list) is not part of the path > selection algorithm > of tor clients. But we do use the recommended version list to select fallback directory mirrors. So when we next rebuild the fallback list (later in 2020), all relays on 0.2.9 and 0.4.0 will be removed. Clients may use relay protocol versions to choose paths, when we add new features that they want to use. But that's a long way away. All supported Tor versions (and 0.4.0) support the most recent tor Relay protocols. So clients don't have any reason to choose between relays based on versions right now. In Tor 0.4.4, we'll introduce a new Relay protocol for IPv6 extends, to support relay IPv6 reachability checks. Clients will ignore it, until they start doing IPv6 extends. (We think we need more IPv6 relays, before clients can safely use IPv6 extends. In the meantime, clients just do IPv4 extends, and every relay has IPv4.) T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay's Bandwidth
Hi, > On 28 Jan 2020, at 16:05, Tor Developer wrote: > > Hi, > I am the operator of a Tor relay and I have been running it for the past > couple of years. > Over the past few weeks, the consensus weight of my relay has dropped > significantly and I can't figure out why. > I am running the latest Tor version on an updated Linux distro. I also > recently upgraded my bandwidth, but it didn't seem to have any affect on the > consensus weight. > What could be causing these drops and inconsistencies? It's normal for consensus weight to vary a bit, as network conditions change. If you send us your relay fingerprint, we might be able to help a bit more? T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bwauths don't like one of my relays?
Hi, Thanks for reporting this issue, and sorry it's taken us a while to get back to you. Many of us have been on leave over the holidays, and we're still catching up. > On 4 Jan 2020, at 10:18, trusting.mcnu...@protonmail.com wrote: > > An update on my relay 'kima' ($54A35E582F9E178542ECCFA48DBE14F401729969) -- > > Eventually I did get assigned more weight; the relay is currently at 4600. > > Along the way I think I discovered one potential problem with the bwauth > bootstrapping process, at least for sbws. (I'm not sure about torflow.) Torflow's partitions have a similar issue, but it's actually worse: a relay can get stuck in a low-bandwidth partition forever. > When sbws is constructing a two-hop measurement circuit to run a test, it > tries to pick an exit that has at least twice the consensus weight of the > current relay-under-test: > https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216 > > So this means that in this case, sbws would have picked any exit that was not > a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at > least, well, 2. That's not a lot. > > As it turns out, something like 10% of exits have under a 600Kbyte/sec > advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap > scenario to get paired with an exit that will give poor test results. > > Perhaps bwauth path selection should also choose a testing pair from > exits/relays with a certain absolute minimum of weight or advertised > bandwidth? I've opened a ticket for this issue: https://trac.torproject.org/projects/tor/ticket/33009 We'll try to resolve it before we deploy any more sbws instances. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
Hi, > On 20 Jan 2020, at 17:43, Georg Koppen wrote: > > nusenu: >> Georg Koppen: >>> Yes, that's what I figured. So, it seems to me not all your proposed >>> keys are equally important (e.g. your require the email one). Which of >>> those (or maybe even which cluster of those) are/is important enough in >>> your opinion to could be considered on topic for a potential tor >>> proposal? (If we would go that route) >> email (if a fully automated verification process is included) > > Okay, that sounds like a promising start. > >>>> The only negative point of removing the ContactInfo field >>>> altogether is loosing information that people put into it. >>> Well, it does not necessarily mean losing information as the field would >>> not just go away but be replaced by other, more narrowed down ones. >> which seems to imply a configuration change and not all operators will >> change their configuration > > That might be true but we'd have some clear process ahead to phase the > old field out and transition to the newer ones, and transparent ways to > enforce the new model after some time. > > I feel that's a big plus to an optional spec that kind of exists in > parallel to the status quo and might play somehow a role in determining > whether a relay might get bumped out of the network or not etc. If we want to recommend that operators provide an email address to stay in the consensus, we should make it easy for operators to provide an email. If we have a preferred format, we should automatically provide the email in that format. Here's a rough sketch of a spec that could work: * add a ContactEmail field to the torrc and descriptors. The field must be encoded as UTF-8. (See proposal 285 [0].) * do some minimal validation on the email field, that makes sure it looks like an email address. (Or don't, so operators can obfuscate their addresses from spammers.) And then there's a few different transition options, some of which overlap: 0. Do nothing. 1. Combine ContactEmail and ContactInfo in the descriptor's ContactInfo field, in the format that the ContactInfo spec recommends. If the email is already a substring of ContactInfo: 1.1. Do nothing. 1.2. Make sure the ContactInfo email is in the format that the ContactInfo spec recommends. 1.3. Remove the email (and the ContactInfo spec email field name) from the ContactInfo field in the descriptor, and just put it in the ContactEmail field. We could wait a few releases to make this breaking change. 2. Warn if the ContactEmail field isn't set on a relay. 3. Reject the configuration if the ContactEmail field isn't set on a relay, after a few releases. 4. Rename ContactInfo to OtherContactInfo, but allow ContactInfo as an alias for a few releases. 5. Deprecate the ContactInfo field in descriptors, and replace it with the email and other contact info fields, after distributing them in parallel for a few releases. Here's my opinion: I'd prefer no validation, combining the fields, and ensuring the email is in the ContactInfo spec format. I think we should give a config warning if the email is missing. Eventually, we should probably stop duplicating email in the ContactInfo and ContactEmail fields. (Although compression helps mitigate the impact of this kind of duplication.) I don't think we should rename ContactInfo. It is one way to force operators to eventually modify their torrc. But if we want to force a config change, let's just require that ContactEmail is set. I don't think renaming or deprecating ContactInfo in the descriptor is useful. (Renaming a field breaks a bunch of tools for no good reason. And people clearly like having an unstructured or extensible field.) But that's all just my opinion. I've run relays, and made changes to tor, but I don't work with this data every day. (Occasionally, I use it as part of selecting fallback directory mirrors.) Any proposed Tor changes should be guided by people who deal with this data all the time: the network health, bad relays, and metrics teams. (And the network team, to help with the design and implementation in Tor.) T [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Fallback Relay address Changed :-(
Hi, > On 14 Jan 2020, at 18:56, j...@wth.in wrote: > > Hi Guys, > > I moved my two relays to a new location and was not able to keep them on the > same IP address. Which is quite unfortunate, since on of the was a fallback > relay. > > https://metrics.torproject.org/rs.html#details/50586E25BE067FD1F739998550EDDCB1A14CA5B2 > https://metrics.torproject.org/rs.html#details/40C773D9F2B16143CDB2ADB661DDC6BB12EF3E2C > > I am not planing to move again within the next decade. So feel free to add > the new address to the fallback list. > > Old address 212.51.134.123 new address 212.51.149.23. Thanks for letting us know. We rebuild the list every 6-12 months, when enough fallbacks fail. I've added those updates to our ticket here: https://trac.torproject.org/projects/tor/ticket/30972#comment:7 T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving Relay IPv6 - RIPE Grant
Hi, > On 18 Dec 2019, at 02:17, NOC wrote: > > On 16.12.2019 20:37, Ralph Seichter wrote: >> * NOC: >> >>> I see a great benefit here, you could default to IPv6 for everything >>> and enable IPv4 only as fallback [...] >> Preferring IPv6 over IPv4 is not even remotely the same as your original >> call to "lets drop all IPv4 only relays from consensus 2020 finally", as >> you wrote in message <08fee42f-f45d-a8c4-d4e6-c83c05b4f...@afo-tm.org>. > > Read the full sentence, dropping all IPv4 only relays is unavoidable because > they can't reach relays behind CG-NAT, preferring IPv6 over IPv4 is only a > handy side effect of this. There hasn't been any new information in this thread for some time, and it appears to be escalating, so I've asked the moderators to consider closing it. I've already shared some details of the grant here: > On 13 Dec 2019, at 17:26, teor wrote: > > The RIPE grant covers IPv6 address autodetection and self-testing. > If the feature is reliable enough, we may turn on IPv6 on dual-stack relays > by default. (When autodetection and self-testing both pass.) > > We don't have any plans to disable IPv4 on relays. We'll get back to you next year when we have a timeline, and some more specific information. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving Relay IPv6 - RIPE Grant
Hi, > On 13 Dec 2019, at 08:45, Logforme wrote: > >> On 2019-12-12 17:49:22, "NOC" wrote: >> than lets drop all IPv4 only relays from consensus 2020 finally. >> > I would be sad to no longer be able to contribute to the Tor network. > My ISP, Telenor Sweden, does not provide IPv6 and have no (public) roadmap > for supporting IPv6. > I can't switch ISP since they provide the fiber connection for the apartment > building. We won't be disabling IPv4 on relays any time soon. The RIPE grant covers IPv6 address autodetection and self-testing. If the feature is reliable enough, we may turn on IPv6 on dual-stack relays by default. (When autodetection and self-testing both pass.) We don't have any plans to disable IPv4 on relays. We'd need most relays to be dual-stack first. (Or we'd need research about privacy in non-clique networks.) And we'd need to write code that allows relays to turn off IPv4. When that's all deployed, we would have to make an engineering decision about the capacity of current IPv4-only relays, and the potential capacity of IPv6-only relays. One possible transition strategy is to allow IPv6-only bridges and exits. But to do that, we need more dual-stack guards and middles. That's why we are improving support for dual-stack relays with this funding. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Improving Relay IPv6 - RIPE Grant
Dear relay operators, I just wanted to let you know that RIPE has announced funding for The Tor Project to improve IPv6 support on relays. (RIPE is the European internet infrastructure organisation.) https://www.ripe.net/support/cpf/funding-recipients-2019 We'll have more details early in 2020, when we've worked out an implementation plan and a start time. Thanks for your patience with our current IPv6 support. And thanks to all those volunteer coders who have worked hard to get us this far. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor crashed: Could not apply consensus diff because an ed command was missing a line number.
Hi, > On 8 Dec 2019, at 22:40, Winter Paulson > wrote: > > this morning the tor process crashed, couldn't find anything searching > the internet. Any hints what this might have been: > > Tor[96521]: Could not apply consensus diff because an ed command was > missing a line number. > Tor[96521]: consdiff_gen_diff: Refusing to generate consensus diff > because the generated ed diff could not be tested to successfully > generate the target consensus. > Tor[96521]: tor_assertion_failed_: Bug: src/lib/memarea/memarea.c:147: > memarea_chunk_free_unchecked: Assertion sent_val == 0x90806622u failed; > aborting. (on Tor 0.4.1.6 ) > Tor[96521]: Bug: Assertion sent_val == 0x90806622u failed in > memarea_chunk_free_unchecked at src/lib/memarea/memarea.c:147: . (Stack > trace not available) (on Tor 0.4.1.6 ) > > server is running on openbsd. I'm not sure what happened either, but I opened this ticket for this crash: https://trac.torproject.org/projects/tor/ticket/32718 T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] unbound: error: recvfrom 123 failed: Host is down
Hi, > On 8 Dec 2019, at 22:37, Winter Paulson > wrote: > > I'm running an exit relay > 200 Mbit/s with local unbound on openbsd. I > receive a lot of the following syslog messages from unbound: > > unbound: [15040:1] error: recvfrom 226 failed: Host is down Maybe the remote DNS server can't handle the load? Or the network between you is dropping DNS packets? Or there's some firewall between you and the remote DNS that sees your DNS as problematic? Have you tried running a full resolver? T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New operator
Hi, > On 25 Nov 2019, at 00:02, David Strappazon > wrote: > > I don't know..despite the fact that everthing looks fine to me, i lost the > fast and stable flag, sometime tor relay search says the bridge is down and > in 11 days nobody connected to my bridge (ecepted me). That's normal, some bridges are kept in the reserve pool. And others are assigned to pools that aren't used as much. If you want more traffic, start another bridge on another port/IP? T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Stable and fast flags
Hi, > On 27 Nov 2019, at 09:21, David Strappazon > wrote: > > Hi, > > How long is it supposed to take to get the stable and fast flags? > > My bridge is up since 13 days. At the beginning I had both flags then I lost > them because of a reboot I think. Since, they never came back. Bridge clients don't use the Stable and Fast flags. So it's not worth worrying about them. Maybe we could adjust Relay Search to make that clearer? T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Accounting limits seem to cause permanent hibernation
Hi, > On 2 Dec 2019, at 21:00, Manuel Wiesinger wrote: > > Since I experience this 'permanent hibernation' since at least last August, I > wonder if it's expected behavior, e.g., caused by the small limit of 128 GB > per day, or if it's a bug (possibly related to this one: > https://lists.torproject.org/pipermail/tor-relays/2019-October/017862.html ?). It seems to be related to this bug, try 0.4.1.7 or 0.4.2-stable, when they come out? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] /24?
Hi, > On 26 Nov 2019, at 05:20, nusenu wrote: > > teor: >> Tor clients automatically exclude relays in the same IPv4 /24 > > huh, in what version was this changed to /24? > The tor man page still has the former value in tor version 0.4.1.6 > > https://trac.torproject.org/projects/tor/ticket/24393 > https://trac.torproject.org/projects/tor/ticket/15518 Sorry, this was my mistake, I copied from the original reply, and only checked the IPv6 value. Tor clients automatically exclude relays in the same IPv4 */16* and IPv6 /32 when choosing paths. (IPv6 support was added in 0.4.0.) https://github.com/torproject/tor/blob/master/src/feature/nodelist/nodelist.c#L1957 T ___ 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?
Hi, > On 9 Nov 2019, at 01:53, ECAN - Matt Westfall wrote: > > 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 Tor clients automatically exclude relays in the same IPv4 /24 and IPv6 /32 when choosing paths. (IPv6 support was added in 0.4.0.) The subnet check is implemented separately to MyFamily, but the end result is the same. > -- 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. Can you send us a link to your relay on Relay Search, and a copy of your torrc? It's hard to debug without detailed information. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] switching ISP and Fallback listing
Hi, > On 22 Nov 2019, at 08:28, René Ladan wrote: > > I might switch my ISP soon-ish from XS4ALL to Freedom Internet so my > relay [1] will get a new AS number and IPv4/IPv6 address, how does this > impact being listed as a fallback candidate? I'm currently not selected > as a fallback. (And yes, I know about fallback needing to be long-term > reliable, but this event was caused by the big corporate powers :( ) > > [1] > https://metrics.torproject.org/rs.html#details/4E8CE6F5651E7342C1E7E5ED031E82078134FB0D I've added a note to update your addresses when we do the next rebuild: https://trac.torproject.org/projects/tor/ticket/30972#comment:5 T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Issues reaching gigabit relay speeds
Hi, > On 1 Nov 2019, at 02:44, Mitar wrote: > > On Thu, Oct 31, 2019 at 6:21 AM Matt Traudt wrote: >> - In an ideal world you won't get more load than your fair share. >> Consider a hypothetically large Tor network with loads of high-capacity >> relays. Every relay may be capable of 1 Gbps but only see 10 Mbps, yet >> there is absolutely no problem. > > Thank you. Yes, I understand that if there is more capacity then the > load will be not fully saturate the available capacity. So it might be > simply that there are so much relays but not enough exits. > > Then my question is different: how could I test and assure that my > nodes are able to utilize full gigabit if such demand would be > required? So that I can assure that they are ready and available? And > that there is not some other bottleneck somewhere on nodes themselves? Most tor instances are limited to 200-400 Mbps, because tor is only partly multithreaded. So you may need to run 3-4 instances to max out a gigabit. You can run chutney in bandwidth testing mode, to get an idea of the CPU and RAM limits on your relay: https://gitweb.torproject.org/chutney.git/tree/README#n98 You might need to adjust CHUTNEY_DATA_BYTES depending on the speed of your machine. The speed may also be limited by chutney's ability to send traffic. If you want to test network speed, you can configure a tor client with: EntryNodes And then download a few very large files at the same time. T signature.asc Description: Message signed with OpenPGP ___ 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?
Hi, > On 31 Oct 2019, at 10:04, ECAN - Matt Westfall wrote: > > 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 > > ... > > 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. The speed tests you ran are not Tor traffic. It's not even clear if they are TCP or TLS. Tor users run Tor clients, just like the bandwidth authorities do. Here are 5 speed tests with actual Tor clients to your relay: https://consensus-health.torproject.org/consensus-health-2019-10-30-23-00.html#C9FD236FDE28003315BD8C96EE94BC58D85FBACF Comcast is well-known for bad peering, and slowing down particular protocols. Search the list archives for details. Here are some steps you can take to try to improve the speed of your relay: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow Let us know how you go! T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Source code signature verification
Hi, > On 30 Oct 2019, at 00:53, tor_mana...@autistici.org wrote: > > I am looking for the procedure and the tor developer key to verify tor source > code package. > I found the one about tor-browser but not this. All the signing keys are listed here: https://2019.www.torproject.org/docs/signing-keys.html.en T___ 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?
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 -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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
Re: [tor-relays] Using unattended upgrades with tor expert bundle
Hi, > On 18 Oct 2019, at 04:39, Keifer Bly wrote: > > So I have been running an OBFS4 bridge via the Tor Expert Bundle for a year > now, and it is going quite well. However, from what I have researched, using > unattended upgrades to keep tor up to date is configured in the torrc file. I > am wondering, can this be configured in tor expert bundle? unattended-upgrades is a Debian and Ubuntu package. It is not configured in the torrc file: tor does not control its own upgrades. The Tor Expert Bundle only runs on Windows. You'll have to do your own upgrades, or use a Windows package manager. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Problem with authorities?
Hi, > On 14 Oct 2019, at 22:23, tscha...@posteo.de wrote: > > On 2019-10-14 11:48, teor wrote: > >>> what's about the autorities maatu., tor26, bastet, gabel., and farav.? >> >> They either: >> - check IPv6 reachability, or >> - have a high stable MTBF (mean time before failure): >> https://consensus-health.torproject.org/#flagthresholds > > Thank you for the reply. What does the 'stable MTBF' mean? Time in > seconds (18 .. 48 days) before my relay get the stable flag back? It's a measure of the stability of your relay. A MTBF is an average time before your relay is next expected to fail, based on its past failures. For more details, see: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1800 > Downtime was from 2019-09-24 10:00 - 2019-09-26 06:00. > >> Keep your relay up, and its IPv6 address reachable, and you should be fine. > > The ReachableIPv6 flag is set and usage is ~5500 connections. If your IPv6 address becomes unreachable, that counts as a failure. I don't have exact data, but it does seem that the IPv6 authorities think your relay has a lower stability. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Questions about Fallbacks
Hi, > On 8 Oct 2019, at 17:03, Michael Gerstacker > wrote: > > when i setted up my relays i choosed 443 as the ORPort. > My thought behind it was that 443 is most likely not blocked and less likely > observed because the ISP could expect to anyway only see encrypted data so a > Tor connection will more likely slip through it. > > I let the DirPort on 9030 because i read that clients anyway only use the > ORPort and i thought if a authority will connect to me it makes no difference > because none of my ports is blocked. > > Now some of my relays are Fallbacks. > > Would it be a benefit for the network if i change the DirPort to 80 or is the > DirPort still not used by clients? The DirPort is not used by clients. > Is it necessary to opt-out the relay as a fallback if it was shut down by the > provider and already is long gone from metrics? It won't make much difference. Relay search deletes missing relays after a week or so. We rebuild the fallback list and delete missing relays every 6-12 months. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Some newbie questions
Hi, > On 3 Oct 2019, at 11:41, skarz wrote: > > Also, after I make changes to the torrc file, is pressing ‘x’ in Nyx an > acceptable way to enable the changes or is there a preferred method? Yes, it sends a reload signal: https://gitweb.torproject.org/nyx.git/tree/nyx/__init__.py#n230 You can also reload tor's config using systemd or "kill -HUP". > Last, if I’m running a bridge at home do I need to configure iptables / > fail2ban or is my firewall sufficient? And specifically which ports need to > be forwarded to my bridge? Just the ORPort or others as well? If you are running obfs4, you also need to forward its port. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Added new relays to my family.
Hi, > On 3 Oct 2019, at 08:00, Jochen wrote: > > just letting everyone know that I've added, in total, 6 new relays to my > family: > > https://metrics.torproject.org/rs.html#search/family:94C268630BEDCB64E7F8881881A23D053F243C18 > > During the next few weeks expect around ~1,6Gbit/s total exit capacity. Thanks for adding more relays! > On another note: Is there any update on multithreading for tor relays? I > recall sending in a trace to, I think, teor. Yes, that was me. > I know that it's probably not a feature with high priority, just asking if > the trace I sent in was useful and if you need anything else ;-) I don't think we have any optimisation or multithreading work planned for the next few months. But it will be useful when we do some in future. Thanks! T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] possible interference between sbws and a libressl relay
> On 24 Sep 2019, at 03:27, Felix wrote: > >> Am 2019-09-23 um 1:59 AM schrieb teor: >> >> We need some more information to diagnose the issue, and answer these >> questions: >> >> * Is this issue reproducible? > > In my Freebsd monoculture, yes. 20 guard relays shared the same history: > > Tor versions Tor 0.4.0.5, 0.4.1.2-alpha, 0.4.1.3-alpha, all on LibreSSL > 2.9.2. Running guard since >1 month before they all lost guard flags > between 2019-08-15 10pm and 2019-08-16 1am. How do you know it's LibreSSL, and not simply restarting the relays? >> * Are all tor clients affected? > > They became middle relays so I expect no client will connect (besides > onion services?). But they were pushing a lot of data as middles. Here's what I meant: Are all Tor instances having trouble connecting to your relays, or just some of them? You've answered the question below. >> * If only some tor clients are affected, why are they affected? > > No idea, sorry. > >> * Are all bandwidth authorities affected, or just the ones running sbws? > > Short: Torflow is ok, sbws not That's not quite accurate. > Consensus for a relay with Libressl 292 > maatu. (!running, fast, !guard, bw ok) The authority on maatuska appears to be affected. > moria1 (running, fast, guard, bw ok) > farav. (running, fast, guard, bw ok) > longc. (running, !fast, !guard, no bw) > bastet (running, !fast, !guard, no bw) The bandwidth authority clients on longclaw and bastet are affected. > All relays w/o 292 received quickly running and fast from all bw auths, > later guard. Ok, so it does have something to do with LibreSSL. But we don't know why some other Tor instances are having trouble connecting: because it's not only sbws clients which are failing, it's authorities as well. >> * Are these issues actually instances of know sbws bugs? > > I don't think so. It doesn't seem so either. This seems like a LibreSSL / Tor bug, not an sbws bug. > For further testing I keep the relays like this: > > All the relays are on the same dedicated server > > now working ok: > 79D9E66BB2FDBF25E846B635D8248FE1194CFD26 Tor 0.4.1.6, OpenSSL 1.1.1d > ACBBB426CE1D0641A590BF1FC1CF05416FC0FF6F Tor 0.4.1.5, OpenSSL 1.0.2s > 9F5068310818ED7C70B0BC4087AB55CB12CB4377 Tor 0.4.1.6, LibreSSL 3.0.0 > 8FA37B93397015B2BC5A525C908485260BE9F422 Tor 0.4.1.5, OpenSSL 1.0.2t > > suffering: > ED7F2BE5D2AC7FCF821A909E2486FFFB95D65272 Tor 0.4.1.3-alpha, LibreSSL 2.9.2 > > > > I hope that helps. Please tell me how I can support. Maybe there is a bug in LibreSSL 2.9.2 ? Or a bug between that version and other SSL libraries? Can you reproduce this issue using Tor Browser connecting to your relays? If so, what do you see in your Tor logs? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] possible interference between sbws and a libressl relay
Hi, > On 22 Sep 2019, at 16:40, Felix wrote: > > > Am 2019-09-21 um 4:11 PM schrieb Toralf Förster: >> On 9/16/19 9:19 PM, Felix wrote: >>> >>> The sbws bandwidth authorities now can measure the bandwidth of the relay. >>> >>> Can somebody confirm my observation or has prove (please no speculations). >>> >> >> I upgraded LibreSSL from 2.9.2 to 3.0.0 here at a stable Gentoo Linux >> and got immediately from all IPv6 capable BW authorties the >> "ReachableIPv6" flag back at both affected relays. > > I have different ssl library setups on the same server (Freebsd): > > sbws measurement is working now for Openssl102s/t, Openssl111d and > Libressl 300. > > sbws measurement is _not_ working now for Libressl 292. sbws is just a normal tor client, with a custom controller. We need some more information to diagnose the issue, and answer these questions: * Is this issue reproducible? * Are all tor clients affected? * If only some tor clients are affected, why are they affected? * Are all bandwidth authorities affected, or just the ones running sbws? * Are these issues actually instances of know sbws bugs? > On 26 Aug 2019, at 11:14, teor wrote: > > There are 3 high-priority bugs that make sbws leave some useful relays out > of its bandwidth file: > https://trac.torproject.org/projects/tor/query?status=!closed=~sbws-majority-blocker T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] FW: Lots of spam on new tor exit node.
Hi, > On 10 Sep 2019, at 04:36, Kenneth Freeman wrote: > > Signed PGP part > > > On 09/08/2019 06:28 PM, teor wrote: > >> Here's our advice for exit relays: >> * don't run them at home, if you're at risk from the police assuming the exit >> traffic is your traffic > > Excellent & standard advice, but I wonder what legally constitutes a > home or one's property. Can you (technically) set up a non-profit in > another room on campus? Say you have a farm with several buildings, > etc. Curious as whether this has been tested! We give this advice because most people don't want police coming to a location they or their family/housemates you may be in danger from a police raid, or where the police may seize all the devices in the house. Some people don't realise that police do things like this. It's not about the legal definition of a "home", which may vary between jurisdictions. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] FW: Lots of spam on new tor exit node.
Hi, > On 7 Sep 2019, at 21:06, > wrote: > > I have recently setup a new tor exit node but since about an hour of setting > it up it has been almost maxed out with spam. > https://metrics.torproject.org/rs.html#details/4AFECB973C2268D5074D8DEDAF0BDB604C89ED50 > > How can I combat it? > > I turned the node off for about an hour from about 6.30am GMT but the user > reconnected. From the looks of it they are connecting through the tor > network. DNS logs are looking like it is targeting illicit Russian drug > forums almost all with .biz domains. That's totally normal. People use anonymity for all sorts of reasons. And it's hard to tell the difference between spam and anonymous sites with weird names. Here's our advice for exit relays: * don't run them at home, if you're at risk from the police assuming the exit traffic is your traffic * don't monitor the sites that are accessed via the exit, because that is illegal in some places, and changes your legal risk in others T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What could cause a huge clock skew (9 days) across Tor restarts - anyone else experienced something like this?
Hi, > On 7 Sep 2019, at 20:25, s7r wrote: > > So, Tor had the time Sep 06 21:03:46.000 before restart. > > After restart, it thought it had Aug 28 07:40:07.000 and then Aug 28 > 07:40:08.000 and then it healed and reported Sep 06 21:04:50.000. > > This is kind of odd. What could be the reason for this? The server is > just a Debian machine that runs Tor and nothing else. Sounds like a bug in Tor's wallclock or log modules. Or a problem with your OS time APIs. What version/commit of Tor were you running before and after the upgrade? What time did your OS show when this issue happened? Can you please post all the logs from Tor's shutdown, startup with the wrong time, and correct time, and then a few more entries? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Hi, On 6 Sep 2019, at 20:14, Roman Mamedov wrote: >> Where does the security weakpoint risk come from? Does >> apt-transport-tor/onion service repository availability help in your >> mind here? > > As with adding any third-party repository, it means trusting the repository > provider to install and run any root-privilege code on the machine. In case > the repository server (or actually the release process, including signing) is > compromised, on the next update it can serve malicious or backdoored versions > of the software. So naturally from the security standpoint it is beneficial to > add (and trust) as few repositories as possible, just to reduce the "attack > surface". So one thing Tor could do here is run easily and securely without root? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Hi all, > On 6 Sep 2019, at 12:20, Mike Perry wrote: > > Roman Mamedov: >> >> On Thu, 05 Sep 2019 02:11:00 + >> Mike Perry wrote: >> >>> 1. "I didn't know that Debian's backports repo has latest-stable Tor!" >> >> I only looked to backports when I get a warning on the metrics website that >> my >> versions are not recommended. Aside from that, I thought that running LTS on >> relays is actually beneficial, to prevent any newly introduced bugs in the >> current latest versions from having an impact on the network infrastructure. > > We are moving towards relying on CI for finding functional bugs, and > code review and static analysis for security issues. > > I don't believe that current LTS periods of time will necessarily > provide better results for either of these classes of risk than > investing in better CI and in other forms of diversity than just release > version. > > However, I could see a middle ground where we shorten LTS timescales for > the relay side, but don't eliminate them, as we work towards where we > want to be with CI and security issue risk reduction (or other forms of > diversity). We also have long-term support so that popular software distributions can have a supported version of Tor. (Debian, Ubuntu, and ideally some non-Linux distributions, if they become popular in future.) So it's not just risk that determines our current LTS timeframes. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor exit relay in Finland still being attacked
Hi, > On 5 Sep 2019, at 03:54, potlatch wrote: > > I had TorExitFin [0] down for a few days hoping the non-Tor Iranian intruders > would wander off. I restarted it today and before NYX could come up there > were 257 Iranian IPs present (nicely automated!). The IP addresses range > over all of the IP addresses allotted to Iran so their usage must come from a > high authority to get that kind of access. NYX communications page showed > that none of these had hashed fingerprints. At the same time 3 IPs came up > from other countries with fingerprints. Should I leave this shut down for > the security of the network? > -potlatch > [0] 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 It's not an attack. It looks like a bad interaction between tor and Iran's censorship. Or genuine usage of tor by an app or a whole bunch of users. See this ticket for more details: https://trac.torproject.org/projects/tor/ticket/30636 You should do whatever you need to do to keep your relay running. If you can, accept the traffic, rate-limit the traffic, or drop the traffic (without replying at all). We're working on a fix on the tor side. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Hi, On 5 Sep 2019, at 13:01, Mike Perry wrote: >> 8. I am maintaining research or other patches against tor, and rebases >> are difficult > > Again, common? I'm going to guess not common (or self-supporting), but > this does feel like something we could measure by checking for git > versions that don't make sense to us in the full descriptor archives. That could be hard: some distros add their own patches using git. >>> How can we fix that for you, or at least, how can we make it easier to >>> run the very latest stable series Tor on your relay? >> >> The answers are probably something like: >> 6. Provide better relay operator support, and direct me to those support >> channels in the log messages, when my relay fails to launch > > Show Quoted Content >>> How can we fix that for you, or at least, how can we make it easier to >>> run the very latest stable series Tor on your relay? >> >> The answers are probably something like: >> 6. Provide better relay operator support, and direct me to those support >> channels in the log messages, when my relay fails to launch > > > +1 100%. I think this will go light years towards getting rid of non-LTS > Tors and LTS tor's alike, regardless of reason. Then we can ask the > remainder. > >> 7. Support old features for longer> 8. Stop refactoring so much code > > Nah. I'm not interested in these, even if populism demands them. Some > shit needs to go away because it is not safe to keep around, and some > stuff needs to be better organized to make it easier to improve. I agree. But you asked for answers, so I gave them. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
Hi Mike, Here's some other reasons that might affect a few operators: > On 5 Sep 2019, at 12:11, Mike Perry wrote: > > Unfortunately, we still have something like 2500 relays on either Tor > 0.2.9-LTS or Tor 0.3.5-LTS. > > What are the reasons for this? My guess is the top 5 most common > responses are: > > 1. "I didn't know that Debian's backports repo has latest-stable Tor!" > 2. "I didn't see the Tor Project repos mentioned in Tor's Relay docs!" > 3. "I'm running a distribution that Tor Project doesn't have repos for." > 4. "I rolled my own custom Tor from git and forgot about it." > 5. "My relay machine was not getting any updates at all. Oops." > > Does anyone have a reason that they think many other relay operators > also share? 6. When I tried to update, it didn't work with my old config 7. I need features that only exist in older Tors - I can think of Tor2web, there may be others 8. I am maintaining research or other patches against tor, and rebases are difficult > How can we fix that for you, or at least, how can we make it easier to > run the very latest stable series Tor on your relay? The answers are probably something like: 6. Provide better relay operator support, and direct me to those support channels in the log messages, when my relay fails to launch 7. Support old features for longer 8. Stop refactoring so much code T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Fast flag - wrong speed in dir-spec.txt?
Hi, > On 30 Aug 2019, at 17:21, Michael Gerstacker > wrote: > > Hi Torproject, > > as far as i can see my relay currently can advertise 560 KiB/s. That are > 573,44 KB/s. > 43C7BC2E17FB26B204EC0BD9AA784E4736979087 > > Following your dir-specs it should get the "Fast" flag if it can provide more > than 100KB/s. > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2595 The default value for AuthDirFastGuarantee is still 100 KB. I don't know if a majority of authority operators have set it higher. The other way a relay gets Fast is if it is in the fastest 7/8ths of the routers. > At my other relay i already saw it providing 562 KiB/s and it got the "Fast" > flag. > A9DB853547A6459AB5190E62BF2F7B8F068FEB0A > > It seems the limit is above 560 KiB/s? > If i remember it right then i already read somewhere that the requirements > are now higher than 100 KB/s so i guess your documentation is wrong? > Am i missing something why my relay with 560 KiB/s dont get the "Fast" flag? 6/9 authorities use measured bandwidth, rather than reported bandwidth. So your relay won't get Fast unless it is measured by the bandwidth authorities, faster than 100 KB. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] SSH scanning on TOR Exit - Nerfing Rules
Hi, > On 30 Aug 2019, at 09:26, AMuse wrote: > > I have SSH open as an exit port on a TOR exit that my friends and I are > maintaining - and of course it's the #1 offender by far in automated abuse > notifications we get from our ISP, from peoples' fail2ban servers sending > abuse emails. This all seems like a huge waste of time, but that's a separate > issue. > > I'm wondering if nerfing outbound SSH to rate limit will be effective at > getting the SSH scanning bots to stop using my exit in their circuit, while > leaving SSH open for actual humans who need to SSH while using TOR. I ran some large exits from 2016-2018, and I thought about this issue a lot. Usually while dealing with automated abuse mails. Ideally, we want a DoS mode that: * allows the first connection from a circuit at full speed * with each extra rapid connection, gradually slows connections from the same circuit There's a bunch of fine tuning we could do by port, traffic volume, and how busy other circuits are. But that needs to be implemented in Tor, because only Tor can see circuits. > I've implemented, as a test, rate limiting outbound on the SSH port. What do > you think the impact of this will be? No impact? Probably. > Losing exit status because connections on SSH die? Unlikely. I think Exitmap only measures HTTP(S). > Something else entirely? Maybe scanners will move to another exit. Maybe some SSH connections will be blocked, you should set your exit in a client's torrc and try it out: ExitNodes (fingerprint) StrictNodes 1 T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 3 questions
Hi, > On 29 Aug 2019, at 00:07, niftybunny > wrote: > > 2. Whats up with Torflow, still linked from Tor Atlas. As far as I can see it > was last updated over 3,5 years ago? It is still running on 4/6 bandwidth authorities. After we fix some critical bugs in sbws, we will replace torflow with sbws. Maybe metrics could also link to sbws from Relay Search? > 3. So what happened to the new measurement? I can see a big spike > https://metrics.torproject.org/bandwidth.html and now its back to normal? > Same with a lot of my relays, traffic doubled/tripled and now its the same or > worse. It didn't have any permanent impact. I'm not too surprised. We probably need to change the bandwidth authorities, or tor, to have a permanent impact. sbws will be easier to change than torflow. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why is my Tor bridge relay not getting any traffic?
Hi, > On 28 Aug 2019, at 23:44, t...@hikari.me wrote: > > Quoting teor : >> >> >>> On 28 Aug 2019, at 14:21, Hikari wrote: >>> >>> So, it's just that few people receive my bridge from BridgeDB. So it's a >>> guard relay, right? What am I lacking to receive a guard flag? >> >> Guards and Bridges are different. >> >> Bridges are secret entry nodes for a few Tor clients. >> >> Guards are public entry nodes for any Tor client. >> But they are easier to block, because they are public. >> >>> And what about being a middle relay? Shouldn't it be used more frequently >>> in this mode? >> >> Middle relays are public middle nodes for any Tor client. >> >> Bridges can't be used as middles, because bridge addresses are secret. > > Now I get it. > > Is it worthy running a public middle relay at home? Or is it possible sites > will block my IP and I should stick with a bridge as it is now? You should stick with a bridge. > I suppose a guard relay isn't advised, right? There is no setting that lets operators make their relays middles or guards. Instead, all non-exits have some chance of being a middle or a guard. For new or slow relays, the chance of being a guard might be zero. >>> I have obfs3 and obfs4 enabled, but I've never tested them. And never got >>> any error message either. >> >> You can test them with Tor Browser, but it takes a bit of cut and paste work. >> Look up the obfs4 instructions for the location of the bridge line file. > > Does Tor Browser for Windows come with obfs4? How to enable it? Yes. Enter an obfs4 bridge line in the bridge settings. See the bridges part of the Tor Browser manual: https://tb-manual.torproject.org/bridges/ > I could also try running Tails on a VM if it has obfs4. Tails has Tor Browser with obfs4. >> If you'd like to get more bridge traffic, start another few bridges on >> different >> ports on the same IP, or different IPs. > > Do you know any tutorial teaching how to run multiple Tor instances? I did it > with Transmission and had some trouble but did it. I don't know what Transmission is. > I suppose I'll need to duplicate /etc/tor and /var/log/tor and have 2 > systemctl files pointing to the correct torrc. > > And also point nyx to the correct instance. I just run it without parameters. ansible-relayor is good, but I don't know if it supports bridges. See the Tor Relay Guide: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#ConfigurationManagement >>> Another question. I currently have Address setting on torrc pointing to a >>> domain handled by no-ip. I have 2 ISPs in load balancing, and before this >>> setting I was having very frequent log messages saying my IP had changed, >>> because each time Tor made its test it was using a different route. Isn't >>> it possible to use Tor in load balancing? >> >> There are different kinds of load balancing. >> >> Tor relays and bridges can only advertise a single IPv4 address. >> Tor relays can also advertise an IPv6 address. >> We're working on dual-stack advertised addresses for bridges. >> >> So Tor works well when your AS announces your relay's IP address on multiple >> upstream routers. > > What's an AS? A network on the internet. > I'm still working on getting IPv6 working. My Cisco RV340's WebUI doesn't > have settings for enabling ULA and neither for delegating global prefix. I > just bought a new router and will try to put OpenWRT on it, and hope to be > able to setup everything then. > > In early monitorings I'm noticing that one of my ISPs, the one I'm able to > use global prefix, hasn't changed mine for over a week. But my server's IP is > changing a few times every day inside the same prefix. > > When (and if) I get everything working, I hope to have 1 no-ip domain for > each ISP IPv4 address, and get 1 fixed IPv6 ULA and an equivalent global IP > for each ISP global prefix and keep it fixed as long as ISPs don't change > their prefix. > > It's gonna take a few months to set it all. > > Regarding Tor, maybe I'll need to run 1 instance for each ISP's IPv4+IPv6 > combination. IPv4 will be easy, IDK how to make it know which IPv6 to use, if > I'm unable to get no-ip working for IPv6. Set the IPv6 address as an ORPort in the relay config. But bridges can only advertise one obfs4 address right now. So I wouldn't worry too much about IPv6 yet. >> If you have different IP addresses for each upstream, you can: >> * Run a separate Tor instance for each address, or >> * Set (inbound) Address to one upstream, and OutboundBindAd
Re: [tor-relays] Why is my Tor bridge relay not getting any traffic?
Hi, > On 28 Aug 2019, at 14:21, Hikari wrote: > > So, it's just that few people receive my bridge from BridgeDB. So it's a > guard relay, right? What am I lacking to receive a guard flag? Guards and Bridges are different. Bridges are secret entry nodes for a few Tor clients. Guards are public entry nodes for any Tor client. But they are easier to block, because they are public. > And what about being a middle relay? Shouldn't it be used more frequently in > this mode? Middle relays are public middle nodes for any Tor client. Bridges can't be used as middles, because bridge addresses are secret. > I have obfs3 and obfs4 enabled, but I've never tested them. And never got any > error message either. You can test them with Tor Browser, but it takes a bit of cut and paste work. Look up the obfs4 instructions for the location of the bridge line file. If you'd like to get more bridge traffic, start another few bridges on different ports on the same IP, or different IPs. > Another question. I currently have Address setting on torrc pointing to a > domain handled by no-ip. I have 2 ISPs in load balancing, and before this > setting I was having very frequent log messages saying my IP had changed, > because each time Tor made its test it was using a different route. Isn't it > possible to use Tor in load balancing? There are different kinds of load balancing. Tor relays and bridges can only advertise a single IPv4 address. Tor relays can also advertise an IPv6 address. We're working on dual-stack advertised addresses for bridges. So Tor works well when your AS announces your relay's IP address on multiple upstream routers. If you have different IP addresses for each upstream, you can: * Run a separate Tor instance for each address, or * Set (inbound) Address to one upstream, and OutboundBindAddress to another. > I'm buying a Ubiquiti EdgeRouter X to put OpenWRT. If everything works, in > the near future I'll have IPv6 and load balancing working, but no-ip seems to > not support IPv6. How should I setup my relay to use both ISPs and IPv4 + > IPv6 with dynamic addresses? Address supports DNS for IPv4 addresses. IPv6 is only supported for ORPort (relays) and ServerTransportListenAddr (bridges). Tor doesn't have support for dynamic IPv6 yet. Can your provider allocate static IPv6? It should have a pool of millions of IPv6 addresses, so static should be easy. We're trying to make IPv6 support better, but I don't know when we will get funding to fix these particular issues. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] attack on my Finland exit/backup directory [9B31F1F1C1554F9FFB3455911F82E818EF7C7883]
Hi, > On 28 Aug 2019, at 14:34, potlatch wrote: > > I still haven't been able to rid myself of the Iranian servers revealed on > the NYX connections page.I don't know their purpose but they slow the > relay by about 85%. I have dropped them in the iptable input chain, > restarted the VPS, but they show up after a day or two in spite. Maybe you could: * rate-limit new connections from that address block, or * limit the total number of connections from that address block. I have used similar firewall settings to deal with client DDoS on guard relays. Search the list archives for detailed instructions. > Today there were 121 of them with a large range of IPs. There have been as > many as 1400 in a single day. None have identifiable hashed fingerprints. > I've enclosed a couple attachments of my input table (partial) and the NYX > connection page (also partial). Please don't publicly post user IP addresses. Publishing user IP addresses can put users in danger, particularly in repressive countries, and for users who are targeted by their state authorities. Future posts from your email address will require moderator approval. > Can anyone enlighten me regarding this situation? I will probably dump the > exit relay if I can't fix this intrusion. Thanks people!! Thanks for running a relay. I realise that this extra traffic is annoying. But your relay is helping other Tor users, and other relays, by soaking up this extra traffic. We are working on a solution to this issue, but it might take some time. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving throughput on weak CPU?
Hi all, Jochen sent this reply to the list, with a 4 MB attachment, which is a bit big. I don't think it contains anything sensitive, but I'll check before forwarding it to anyone else. I've discarded the message and attachment from the moderation queue. Here's the message: > Hi, > > I have attached a profile of the main thread, over 30 seconds, to this > e-mail. > > Let me know if you need anything else. > > Regards, > > Jochen T -- teor -- signature.asc Description: Message signed with OpenPGP ___ 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
> On 27 Aug 2019, at 05:19, Toralf Förster wrote: > >> On 8/26/19 3:14 AM, teor wrote: >> We expect to have funding to fix these bugs some time in the next month >> or two. > > So I'll just wait. Waiting might not help, if the issue is on your relay: >> I don't think the sbws bandwidth authorities are causing the issue that >> you're seeing with your consensus weight or flags. >> >> The consensus is based on majority votes, and 2/6 bandwidth authorities >> or 2/9 authorities are not a majority. > FWIW I set "RelayBandwidthRate 30 MBytes" for a day or so to see whether a > possible overload of the my relays could cause some trouble but did not see > any positive effect so far. Perhaps your provider is dropping traffic, or has bad peering? T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving throughput on weak CPU?
Hi, > On 26 Aug 2019, at 19:06, Jochen wrote: > > Hi there, I'm the operator of the following two exit nodes: > > https://metrics.torproject.org/rs.html#search/family:94C268630BEDCB64E7F8881881A23D053F243C18 > > My CPU is an Intel C2750 (8 cores total), which supports hardware accelerated > AES yet a single process still maxes out at only ~150mbit/s. > > To get the most out of the machine and my single IPv4 address, I simply ran > another relay which works fine, and now I'm averaging at around ~315mbit/s. > > Is there anything else I can tweak to improve throughput without having to > order more IP addresses? I'm running Arch with stock 5.2.9 linux kernel. > > That being said, true multi threading would be much appreciated and would > help people like me a lot :-) Which code is your relay spending most of its (main thread) time on? If you can send us a profile, we will know where to focus our effort. T ___ 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
Hi, > On 26 Aug 2019, at 00:21, Felix wrote: > >> I found another relay [2] where at least 4 of the 9 authorities doesn't set >> the "Running" flag, which is needed for "Guard", right? >> That relay has a reasonable bw value to (23,000 , FWIW the value for [1] is >> about 90,000). >> >> So now I do wonder why the Running flag is lost after a year. >> >> [1] >> https://consensus-health.torproject.org/consensus-health-2019-08-24-07-00.html#509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6 >> [3] >> https://consensus-health.torproject.org/consensus-health-2019-08-24-08-00.html#0CDCFB0B6E1500E57BDD7F240543EBAEF81C11CA > > I have a similar experience like Toralf. Since a week all my relays (but > one) are middle relays. Which is fine because they push good traffic. The Guard flags is affected by the bandwidth authority measurements. > All are measured by maatu, gabel, moria1 and farav. But only one is > measured by longc and bastet. [1] > Why is that? longclaw and bastet run sbws, the other bandwidth authorities run torflow. There are 3 high-priority bugs that make sbws leave some useful relays out of its bandwidth file: https://trac.torproject.org/projects/tor/query?status=!closed=~sbws-majority-blocker These bugs stop us deploying sbws to more than 3 authorities. We expect to have funding to fix these bugs some time in the next month or two. Even after these changes, Torflow will still have more relays than sbws, because some of the relays that Torflow reports have been down for a long time. > My understanding is six of nine authorities measure bandwitdh. I can > download bandwidth files from all six from a _non_ measured server [2], > so connection is given. But I see about 2.4MB doc size from the ones > working for me and 4MB from the ones not working. > Any clue what is the difference between those? > > My family is [3]. The good relay is 402 and the `bad´ ones are between > 405 and 415. > > Don't get me wrong. If guard, middle or exit all relays are important. > But it's a little strange. I don't think the sbws bandwidth authorities are causing the issue that you're seeing with your consensus weight or flags. The consensus is based on majority votes, and 2/6 bandwidth authorities or 2/9 authorities are not a majority. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] AvoidDiskWrites
> On 25 Aug 2019, at 21:45, Roger Dingledine wrote: > > And as a last note, I think it's been a long time since anybody tuned > AvoidDiskWrites to have actually reasonable parameters. I wrote it long > ago as a potential feature that somebody might find useful, and I just > picked some numbers that seemed plausible back in 2007. Since 2007, we've seen some significant technological changes: * More devices with batteries * More devices with SSDs * Better disk forensics techniques So it might be a good idea to change the client default to AvoidDiskWrites 1: https://trac.torproject.org/projects/tor/ticket/31507 T___ 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
Hi, > On 24 Aug 2019, at 19:38, Toralf Förster wrote: > >> On 8/19/19 4:56 AM, teor wrote: >> Yes, changing other relays' bandwidths can affect the Guard flag, because >> Guard is given to the fastest, most stable relays. > > I'm not convinced that this is the culprit for the mentioned relay [1]. > > I found another relay [2] where at least 4 of the 9 authorities doesn't set > the "Running" flag, which is needed for "Guard", right? > That relay has a reasonable bw value to (23,000 , FWIW the value for [1] is > about 90,000). > > So now I do wonder why the Running flag is lost after a year. An authority assigns the Running flag to a relay when it can reach that relay on its IPv4 ORPort. If the authority is configured to do IPv6 reachability checks, then it also checks the IPv6 ORPort (if there is one). > [1] > https://consensus-health.torproject.org/consensus-health-2019-08-24-07-00.html#509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6 At the moment, 4/9 authorities can't reach this relay. Maybe its provider is dropping traffic from some routes, or maybe it is overloaded. > [3] > https://consensus-health.torproject.org/consensus-health-2019-08-24-08-00.html#0CDCFB0B6E1500E57BDD7F240543EBAEF81C11CA At the moment, 6/9 authorities can't reach this relay. Same possibilities. 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
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 signature.asc Description: Message signed with OpenPGP ___ 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
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
Re: [tor-relays] tor relay ipv6
Hi, > 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. 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. Please copy and paste your torrc, particularly the Address, ORPort, DirPort, and OutboundBindAddress options. If we need your machines network config, we'll let you know. It can be hard to set up IPv6 for a relay, we're working on a grant to make it easier. 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 - RelayBandwidthRate vs. RelayBandwidthBurst
Hi, > On 20 Aug 2019, at 20:23, petra...@protonmail.ch wrote: > > I'm struggling a bit with the two config options for RelayBandwidthRate and > RelayBandwidthBurst - what I currently have in my torrc config file is: > > ... > RelayBandwidthRate 8 Mbit > RelayBandwidthBurst 12 Mbit > ... > > My assumption was that on average the Relay would consume 8 Mbps max. but > over a shorter period of time also up to 12 Mbps in case needed. > What I see (historical monitor data at 10 s intervals for the past 6 months) > is that the bandwidth usage never exceeds 8 Mbps. I can also see the > consumption to be levelled out at 8 Mbps for minutes or hours so it looks > like there would be a need for more bandwidth. Yes the Tor network does need more bandwidth, particularly for exits. > My question: why can't I see the bandwidth usage going above 8 Mbps and > making use of the allowed burst? Btw, I'm typically using the latest stable > tor, currently the relay is on 0.4.0.5. The burst is over a very short period of time. I think it's about 1 second. The rate is averaged is over a slightly longer period of time, and includes any burst bandwidth. That is, if the bandwidth burst to 12 Mbps in the last second, the bandwidth in this second will be 4 Mbps. The lower bandwidth in the next second keeps the average to 8 Mbps. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Very high CPU Load and low Traffic since Sunday
Hi, >>> On 15. Aug 2019, at 16:43, Tim Niemeyer wrote: >>> >>> Signed PGP part >>> Hello >>> >>> I've noticed a reduction in tor traffic about 50% since Sunday. The cpu >>> load stayed almost same. The amount of TCP Sessions increased from ~34k >>> to ~65k. Also the abuse rated about network scans got increased since >>> Sunday. >>> >>> Does anyone knows what's there going on? >>> >>> My guess is that since Sunday anyone uses Tor for extended network >>> scans, which results in a very high packet rate. >>> >>> Personally I've no problem with some network scans, but this is a bit >>> annoying and I asked myself if this is still a scan or more a DOS. >>> >>> https://metrics.torproject.org/rs.html#search/family:719FD0FA327F3CCBCDA0D4EA74C15EA110338942 >> On Aug 19, 2019, at 21:45, niftybunny >> wrote: >> >> Same here +1 > On 20 Aug 2019, at 14:35, Larry Brandt wrote: > > This may be similar to my situation with my Finland exit relay [1]. I was > finally forced to deal with kern overload that shut my cpu down. I had > several thousand IP's without hashed fingerprints opting to get into Tor. A > combination of hardening, banning and increasing kern processing to 100,000 > helped. Since then I have a Consensus Weight of 600 rather than the 8000 > before the intrusion. Strange thing: ufw banning and reboot does not seem > to stop a few of the Iranian IP addresses--they're still there. We think this is a result of Iranian censorship, I think the anti-censorship team are working on the issue. I've cc'd Philipp for more info. > On 20 Aug 2019, at 12:56, John Ricketts wrote: > > reduction++; This could be a result of load balancing changes due to Rob's bandwidth experiment. CPU overloads could also be a result of load balancing changes. The tests only used a few large bandwidth circuits, but the CPU usage of lots of small circuits is much higher. I've cc'd Rob to get his opinion. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Emerald Onion's new relays
> On 20 Aug 2019, at 06:20, li...@for-privacy.net wrote: > >> On 19.08.2019 05:03, teor wrote: >> >> We'll be able to judge the right speed once we've released the first >> few new IPv6 features. Having funding will also help us go faster. > > Maybe this year before Christmas a donation call for IPv6 features could be > made ;-) > Similar to last year, when the Mozilla Foundation doubled donations. I'm not sure what our end of year campaign will be this year. But we are working on funding for IPv6: On 13 Aug 2019, at 07:39, teor wrote: >> Tor supports IPv6 very >> poorly and nobody cares much. > > Lots of us care about IPv6. Our problem is finding *funders* who care enough > to pay for the time we need to implement this complex feature. But we're > working on a grant application right now: > > On 12 Aug 2019, at 11:54, teor wrote: > >>> It is discouraging to see so many small and large network operators not >>> using IPv6. Why is this such a problem? >> >> Tor relays don't automatically detect IPv6 addresses, and they don't test >> the reachability of IPv6 ORPorts. We are working on a grant application to >> add this support in Tor. (It's more complex than it seems, because we need >> to split the reachability checks per-ORPort, and add IPv6 extend support to >> Tor relays.) >> >>> Tor Project, please increase your #IPv6 awareness/outreach similar to how >>> ARIN and the other RIRs try very hard to do. >> >> I'll add an awareness objective to our grant application. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Emerald Onion's new relays
Hi, > On 16 Aug 2019, at 01:02, NOC wrote: > > On 15.08.2019 00:50, teor wrote: >> >> On 14 Aug 2019, at 03:42, NOC wrote: >> >>> On 12.08.2019 23:39, teor wrote: >>>> >>>> On 13 Aug 2019, at 05:08, Roman Mamedov wrote: >>>> >>>>> On Mon, 12 Aug 2019 00:46:50 + >>>>> Christopher Sheats wrote: >>>>> >>>>>> Tor Project, please increase your #IPv6 awareness/outreach similar to how >>>>>> ARIN and the other RIRs try very hard to do. >>>>> >>>>> Before outreach Tor would need some actual IPv6 support, as in using it >>>>> for >>>>> the actual traffic of relay-to-relay communication. I tried running a few >>>>> relays with very fast IPv6 and slow IPv4 (due to a common NAT frontend >>>>> which >>>>> was the bottleneck), but it was a complete nonstarter. >>>> >>>> Tor relays currently don't connect over IPv6. When 10% of the network >>>> supported IPv6, there wasn't much point, because putting a very small >>>> number of paths over IPv6 has privacy risks. So we focused on client, >>>> guard, >>>> and exit IPv6 support. >>>> >>>> But currently, about 30% of the consensus weight supports IPv6. So we >>>> are working on a grant for IPv6 support (see below). >>>> >>>> We won't be able to prefer IPv6 until 50-67% of relays support IPv6, for >>>> load-balancing and privacy reasons. But we plan on using the >>>> "Happy Eyeballs" (RFC 8305) algorithm on dual-stack relays. So >>>> sufficiently slow IPv4 will cause relays to connect over IPv6. (And we can >>>> tune the load-balancing using the IPv4 to IPv6 delay.) >>> I still would say that these stats are deeply flawed. Looking at the >>> Autonomous Systems where the relays are located from the top100, 99 of them >>> do support IPv6 (85,7625% consensus weight), the only one which doesn't >>> support is AS4224 but since they manage their AS themselves they would only >>> need to ask their LIR and would get IPv6. >>> >> The top 100 relays are only 13-18% of the total advertised bandwidth: >> https://metrics.torproject.org/advbwdist-relay.html?start=2019-05-16=2019-08-14=1=100 >> https://metrics.torproject.org/bandwidth.html > I never wrote about the top100 relays, relays don't matter, they come and go. > It is important who does host them, that is why i looked at the AS, because > the providers won't stop offer IPv6 if they have deployed it once. And that > is why i think the complete roadmap is not useful at all and will delay > everything just unnecessary. We try to add new features, while keeping the network stable and fast, and protecting user anonymity. Sometimes we are too cautious, other times we break things. We'll be able to judge the right speed once we've released the first few new IPv6 features. Having funding will also help us go faster. And it would really help if we had some researchers tell us how to do anonymity in a mixed IPv4-only/dual-stack/IPv6-only network. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
