Re: [tor-relays] Attack on Tor exit and back-up directory server
Hi, > On 16 Aug 2019, at 04:22, potlatch wrote: > > One question remains: At any time I look there are 20-150 Iranian IP > addresses trying to access the Tor server. Their IP range is from 5.113.x.x > to 5.126.x.x. None have hashed fingerprints. Is it okay to let these guys > go? Can they harm or slow Tor? Should I ban them? I'd like to learn from > this. This is probably a connection error caused by Iranian censorship. We're working on anti-censorship and stats fixes, but I can't find the tickets right now. In the meantime, try using a lower value for Tor's DoSConnectionMaxConcurrentCount option. The consensus value is 50, but you should set your value based on the number of connections from a single IP address. Or just try 25, then 12, ... If no single IP address is problematic by itself, you can use a firewall to limit the number of connections, or the new connection rate, from an entire address block. 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
Hi, > On 17 Aug 2019, at 18:11, Toralf Förster wrote: > > Signed PGP part > On 7/26/19 4:18 PM, Rob Jansen wrote: >> I am planning on performing an experiment on the Tor network to try to gauge >> the accuracy of the advertised bandwidths that relays report in their server >> descriptors. > > Hi, > > does this by any chance caused the lost of the "guard" flag ? Observed here > now 2 times for 2 relays running at the same ip [1] and [2] within the last > few days. > > > [1] > https://metrics.torproject.org/rs.html#details/509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6 > [2] > https://metrics.torproject.org/rs.html#details/63BF46A63F9C21FD315CD061B3EAA3EB05283A0A Yes, changing other relays' bandwidths can affect the Guard flag, because Guard is given to the fastest, most stable relays. 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] removal from the Fallback Directory list
Hi, > On 14 Aug 2019, at 22:50, contact-tor-tur...@g0b.eu wrote: > > hello, I managed until now the relay tor-turing - > 8456DFA94161CDD99E480C2A2992C366C6564410 - ip 62.210.254.132 for four years > and it was in the list of Fallback Directory. However he did not answer for 2 > weeks, the support of my hosting provider told me that the motherboard is out > of order and data are irrecoverable, so it should remove it from the list of > Fallback Directory. Thanks for letting us know, and sorry about your relay. We'll remove your relay when we rebuild the list in 6-12 months: https://trac.torproject.org/projects/tor/ticket/30972#comment:3 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] Fwd: Emerald Onion's new relays
Hi, We didn't clear the moderation queue last week, and this message was dropped from the queue. We'll make sure someone is looking at the queue every 1-3 days in future. T Begin forwarded message: >> On Mon, Aug 12, 2019 at 09:02:58PM +0200, li...@for-privacy.net wrote: >>> On 12.08.2019 02:46, Christopher Sheats wrote: >>> >>> It is discouraging to see so many small and large network operators >>> not using IPv6. Why is this such a problem? Tor Project, please >>> increase your #IPv6 awareness/outreach similar to how ARIN and the >>> other RIRs try very hard to do. >>> >> +1 >> >> Twitter :-( Wish you're on Mastodon, too. > > EO's Shawn Webb is on Mastodon: @lattera@bsd.network > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal:+1 443-546-8752 > Tor+XMPP+OTR:latt...@is.a.hacker.sx > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 ___ 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 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 > So my conclusion is not that there is any need to wait for adaption, only for > software support. > It's hard to draw accurate conclusions from less than 20% of the network. What about the other 80% of the network? > Release one stable from which point you need IPv6 and the operator will see > that there is something to be done. You won't affect older versions since > they still can speak with you but you won't get in the consensus from that > point because you don't fulfill all requirements for it. > I don't think kicking relay operators off the network when they upgrade to a new version is helpful. We *want* people to upgrade. Also, abruptly reducing the capacity of the network is a bad experience for Tor users. They will have slow traffic or connection failures. We call these kinds of abrupt changes "flag days", and we try hard to avoid them. Here's a plan that will take longer, but help more relay operators get on IPv6: Automatically detect and use IPv6 on relays: 1. Release a tor version that automatically detects IPv6 on relays, and uses it if it works. But turn it off by default, and have an option and a consensus parameter to turn it on. 2. Ask relay operators to test the new feature in the alphas and release candidates. 3. Once the feature has had enough testing, turn it on for all relays using the consensus parameter. 4. Encourage relay operators to configure IPv6 on their relay's network stack and upstream connection Reduce the consensus weight for IPv4-only relays: 1. Wait until we have enough dual-stack relays, that we can afford to send them more traffic. (We need metrics for IPv6 traffic, which we don't have right now.) 2. Add a consensus parameter and consensus method that reduces the consensus weight for IPv4-only relays by a percentage. 3. Gradually reduce the weight of IPv4 relays. 4. Encourage relay operators to configure IPv6 on their relay's network stack and upstream connection Wait until we have seen some good research on non-clique anonymity networks, or remove IPv4 and allow IPv6 at the same time. Allow IPv6-only guards: 1. Add automatic IPv6 support to clients, so clients use IPv4 and IPv6 when available 2. Optional: add automatic IPv6 support to bridges, so bridges use IPv4 and IPv6 when available 3. Wait until we have enough dual-stack middle relays, and dual-stack or IPv6 clients and bridges 4. Allow IPv6-only guards 5. Optional: allow IPv6-only bridges Allow IPv6-only exits: 1. Improve Tor client and Tor exit support for IPv6 exit connections, allowing clients to discover and remember whether a site is IPv4-only, dual-stack, or IPv6-only 2. Wait until we have enough dual-stack middle relays, and enough internet sites that support IPv6 3. Allow IPv6-only exits Allow
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Hi, > On 9 Aug 2019, at 23:25, Rob Jansen wrote: > >> On Aug 6, 2019, at 5:31 PM, Rob Jansen wrote: >> >> Over the last 2 days I tested my speedtest on 4 test relays and verified >> that it does in fact increase relays' advertised bandwidth on Tor metrics. >> >> Today, I started running the speedtest on all relays in the network. So far, >> I have finished about 100 relays (and counting). I expect that the >> advertised bandwidths reported by metrics will increase over the next few >> days. > > Update: the measurement finished around 0100 UTC on 2019-08-09. I attempted > to measure each relay that appeared in the latest consensus over time. Due to > relay churn, this resulted in more measurements than the number of relays in > a single consensus. > > I attempted 7001 measurements: > - 4867 relays were successfully measured for 20 seconds each. > - 2134 relays timed out while trying to build the 10 speedtest circuits. > > The measurement should be reflected in most server descriptors of > successfully measured relays within 36 hours, at about 1300 UTC on 2019-08-10. It looks like the measurement has increased advertised bandwidths: Middle: 69% Exit: 72% Guard: 53% Exit and Guard: 28% https://metrics.torproject.org/bandwidth-flags.html The growth is mainly in the top 10% of relays: https://metrics.torproject.org/advbwdist-perc.html?start=2019-05-14=2019-08-12=100=95=90=75=50=25 The IPv6 stats are similar: Guards with IPv6 ORPort: 47% Exits with IPv6 ORPort: 42% Exits with IPv6Exit: 39% https://metrics.torproject.org/advbw-ipv6.html We don't have stats for consumed bandwidth yet, they should arrive in the next 3-5 days. 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 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.) > 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] Removal from fallback directory mirror list
Hi, > On 12 Aug 2019, at 07:55, Augusto Cezar Amaral wrote: > > I'll need to shut down relay KrigHaBandolo > (46791D156C9B6C255C2665D4D8393EC7DBAA7798). > > Can someone here help me with removing it from the fallback directory > mirror list? Thanks for letting us know. We'll do a rebuild around the end of 2019 or start of 2020, and we will remove your fallback from the list during the rebuild. (Tor clients are designed to work well even if a few fallbacks go down.) We're tracking fallback changes here: https://trac.torproject.org/projects/tor/ticket/30972#comment:2 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] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Hi Rob, > On 8 Aug 2019, at 22:15, Rob Jansen wrote: > >> On Aug 6, 2019, at 5:48 PM, Roger Dingledine wrote: >> >> On Tue, Aug 06, 2019 at 05:31:39PM -0400, Rob Jansen wrote: >>> Today, I started running the speedtest on all relays in the network. So >>> far, I have finished about 100 relays (and counting). I expect that the >>> advertised bandwidths reported by metrics will increase over the next few >>> days. For this to happen, the bandwidth histories observed by a relay >>> during my speedtest are first committed to the bandwidth history table >>> (within 24 hours), and then reported in the server descriptors (within >>> 18-36 hours, depending on when the bandwidth history commit happens). >> >> Great. >> >> There will be another confusing (confounding) factor, which is that the >> weights in the consensus are chosen by the bandwidth authorities, so >> even if the relay's self-reported bandwidth goes up (because it now sees >> that it can handle more traffic), that doesn't mean that the consensus >> weight will necessarily go up. In theory it ought to, but with a day or >> so delay, as the bwauths catch on to the larger value in the descriptor; >> but in practice, I am not willing to make bets on whether it will behave >> as intended. :) So, call it another thing to keep an eye out for during >> the experiment. > > Another wrinkle to keep in mind is that my script measures one relay at a > time. If there are multiple relays running on the same NIC, after my > measurement each of them will think they have the full capacity of the NIC. > So if we just add up all of the advertised bandwidths after my measurement > without considering that some of them share a NIC, that will result in an > over-estimate of the available capacity of the network. > > To avoid over-estimating network capacity, we could use IP-based heuristics > to guess which relays share a machine (e.g., if they share an IP address, or > have a nearby IP address). In the long term, it would be nice if Tor would > collect and report some sort of machine ID the same way it reports the > platform. More precisely, we're trying to answer the question: "Which small sets of machines are limited by a common network link or shared CPU?" A machine ID is an incomplete answer to this question: it doesn't deal with VMs, or multiple machines that share a router. Here are some other potential heuristics: * clock skew / precise time: machine/VM? * nearby IP addresses and common ASN: machine?/VM?/router? * platform: machine * tor version: operator? (a proxy for machine/VM/router) Is there a cross-platform API for machine IDs? Or similar APIs for our most common relay platforms? (Linux, BSDs, Windows) 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] 10 Years Torservers.net: Death or Future?
Hi niftybunny, Mitar, > On 7 Aug 2019, at 17:37, niftybunny > wrote: > > Thats complete and utter bullshit. After thinking about it for a while, I have allowed this email through moderation. I considered rejecting it, because this thread is getting repetitive. And it seems like you're getting frustrated, because you don't agree with each other. Disagreements are ok, but sometimes you need to summarise, then move on. Please stay on topic, provide new, useful information, and stay calm. If that doesn't happen, we might reject or delay future emails on this thread. 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] Running gigabit relay
Hi, > On 6 Aug 2019, at 20:12, Mitar wrote: > > Hi! > > I have deployed it: > > https://metrics.torproject.org/rs.html#details/567E9785458C605E59202755C74898E3C96FB1CC > > On gigabit fiber, using this NUC: > > https://ark.intel.com/content/www/us/en/ark/products/126140/intel-nuc-kit-nuc8i7beh.html > > Now I just have to wait for traffic to build-up to see if it can > really achieve gigabit. Is there any way to speed this process up? Is > there anyone who would like to do some circuits through the node to > exercise its bandwidth a bit? Rob might like to test your relay, because it should show a big speed increase if his tests are working. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor server setup of keys
> On 5 Aug 2019, at 09:10, potlatch wrote: > > I have not installed a Tor relay since the gpg server change. I started a > new relay today and found that the instructions for ubuntu Bionic did not > work for me. Specifically, > > url > https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc > | gpg --import > gave me an error message that --import is not an option of curl. Has anyone > come across this and worked out the problem? It looks like you might have mistyped the pipe "|" ? Please try again, and send us the full command from the $ prompt, and the full output. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [metrics-team] New Fallbacks from June 2019
> On 5 Aug 2019, at 03:28, Toralf Förster wrote: > >> On 7/2/19 1:33 PM, teor wrote: >> Dear Relay Operators, >> >> The FallbackDir flags on Consensus Health [2] and Relay Search [3] >> might take a week or two to update. >> >> [3]: For example, this relay is a new fallback, but its flag isn't >> shown yet: >> https://metrics.torproject.org/rs.html#details/1211AC1BBB8A1AF7CBA86BCE8689AA3146B86423 > > I'm just curious b/c that relay doesn't show the FallbackDir-Flag even after > a month. We had an in-person meeting early July, so maybe people forgot to do the updates. I opened a ticket for relay search: https://trac.torproject.org/projects/tor/ticket/31332 Stem also hasn't updated yet, and Stem's list is used for consensus-health: https://trac.torproject.org/projects/tor/ticket/31315 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 has low consensus weight
Hi, We get this question a lot. > On 4 Aug 2019, at 00:38, Piers wrote: > > Hi, i have been running a tor relay (link: > https://metrics.torproject.org/rs.html#details/858BEC79D7355EC0631E98D47CF14B576BFD6D0F) > on a raspberry pi 2 for 15 days, however i think there might be a problem > with it. My consensus weight is only 43 and thus the relay doesn't get used > much. Please advise if there is an issue > There are lots of reasons why relays are slow. Maybe your relay can't do Tor's cryptography fast enough on its CPU? We've noticed similar issues with other Raspberry Pi 2 relays. Try reading this problem-solving guide, and let us know how you go: 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] ORPort // DirPort
Hi, You must not forward your control port to the internet. If you accidentally disable control authentication, then anyone on the internet can control your relay. > On 3 Aug 2019, at 21:10, Fabio De Sicot wrote: > > Hello everyone > I have a problem I wasn't able to fix until now. Could you help me whit this? > > > - when I start tor I receive this error: > > [...] > Aug 03 09:48:29.000 [notice] Have tried resolving or connecting to address > '[scrubbed]' at 3 different places. Giving up. > Aug 03 09:48:40.000 [notice] Have tried resolving or connecting to address > '[scrubbed]' at 3 different places. Giving up. > [...] > Aug 03 10:07:09.000 [warn] Your server () has not managed to confirm that its > ORPort is reachable. Relays do not publish descriptors until their ORPort and > DirPort are reachable. Please check your firewalls, ports, address, > /etc/hosts file, etc. > Aug 03 10:07:09.000 [warn] Your server () has not managed to confirm that its > DirPort is reachable. Relays do not publish descriptors until their ORPort > and DirPort are reachable. Please check your firewalls, ports, address, > /etc/hosts file, etc. > > - I verified, and ports 9051, 9001 and 9030 were not filtered > > … > - I checked my torrc file > > # cat /usr/local/etc/tor/torrc > Nickname xx > ORPort 9001 > ControlPort 9051 > DirPort 9030 > # > # > RunAsDaemon 0 > ExitRelay 0 > CookieAuthentication 1 > ContactInfo xxx > > - I verified the internal ip > > # ifconfig eth0 > eth0: flags=4163 mtu 1500 > inet 192.168.0.8 netmask 255.255.255.0 broadcast 192.168.0.255 > inet6 fe80::1874:3d84:ac42:fa97 prefixlen 64 scopeid 0x20 > ether b8:27:eb:90:a2:b8 txqueuelen 1000 (Ethernet) > RX packets 1118761 bytes 398404534 (379.9 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 1095304 bytes 428598871 (408.7 MiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > - and I verified that on my router the port forwarding was active > > # > Port Forwarding > Name Port Range Protocol IP Address Enable > TOR 9051TCP 192.168.0.8 x > ORPORT9001TCP 192.168.0.8 x > DIRPORT 9030TCP 192.168.0.8 x > Maybe tor isn't guessing your external address correctly. (It's hard to tell, because you deleted the addresses in your logs, and deleted the log lines where tor guesses your address.) Try following these instructions to set Address, NoListen, and NoAdvertise: https://lists.torproject.org/pipermail/tor-relays/2019-June/017401.html 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 again, > On 2 Aug 2019, at 08:18, Rob Jansen wrote: > >> On Jul 31, 2019, at 7:34 PM, teor wrote: >> >> Can you define "goodput"? > > Application-level throughput, i.e., bytes transferred in packet payloads but > not counting packet headers or retransmissions. In our case I mean the number > of bytes that Tor reports in the BW controller event. > >> How is it different to the bandwidth reported by a standard speed test? > > I believe that iperf also reports goodput as defined above. > >> How is it different to the bandwidth measured by sbws? > > I am not an expert on sbws, but I believe it also measures goodput. > >> Where is your server? > > West coast US. > >> How do you expect the location of your server to affect your results? > > I expect that the packet loss that occurs between my measurement machine and > the target may limit the goodput I am able to achieve, and packet loss tends > to occur more frequently on links with higher latency. Tor's stream window also limits the goodput of a single stream. The in-flight bandwidth is limited to 500 cells * 498 RELAY_DATA cell goodput bytes = 243 kBytes > I plan to use multiple sockets (as standard speed testing tools like iperf > do) and multiple circuits to try to mitigate the effects. Good. sbws only uses one stream at a time, and its streams are open for 5-10 seconds. > Note that this is meant to be a fairly simple experiment, not a complete > measurement system. Of course I won't be able to measure more than the > bandwidth capacity of my measurement machine, but many relays already carry > significant load so I'll just be giving them a boost. Sounds like a useful experiment. If using multiple circuits for 20 seconds makes a significant difference to some relays, we should consider changing sbws to: * use multiple circuits, * use 2 streams per circuit (to fill each circuit window), and * run each test for 20 seconds. Or we could modify the relay bandwidth self-test to: * use significantly more bandwidth, and try to find the bandwidth limit for each relay, and * run each test for 20 seconds. (The relay bandwidth self-test uses DROP cells on multiple circuits, so stream windows don't apply.) T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unutilized bandwidth
Hi Matt, > On 30 Jul 2019, at 21:18, Matt Westfall wrote: > > You're right, it went offline for around 2 days due to a power outage and a > Bios error that needed continue pressed. > > That's what the stable flag is for, lol. > > I lost guard probability for 2 more weeks. > > If a relay has been up connected and stable for more than 2 weeks, it gets > the -stable- flag so it's leaned on more. > > That doesn't really affect the underlying issue of tor nodes with TONS of > bandwidth not being utilized a little more. > > But I'm happy to donate whatever the tor protocol decides it wants to use :( Comcast typically has poor peering to Europe and some other top-tier networks. We've investigated these issues in the past: search the list archives. So your relay's bandwidth to the rest of the tor network may be accurately represented by its consensus weight. 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] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Hi Rob, > On 27 Jul 2019, at 00:18, Rob Jansen wrote: > > I am planning on performing an experiment on the Tor network to try to gauge > the accuracy of the advertised bandwidths that relays report in their server > descriptors. Briefly, the experiment involves running a speed test on every > relay for a short time (about 20 seconds). Details follow. > > ... > > Motivation > -- > The capacity of Tor relays (maximum available goodput) is an important > metric. Combined with mean goodput, it allows us to compute the bandwidth > utilization of individual relays as well as the entire network in aggregate. > Generally, capacity is used to help balance client load across relays, and > relay utilization rates help Tor make informed decisions about how to > allocate resources and prioritize performance and scalability improvements. Can you define "goodput"? How is it different to the bandwidth reported by a standard speed test? How is it different to the bandwidth measured by sbws? > ... > > We will conduct the speed tests while minimizing network overhead. We will > use a custom client that builds 2-relay circuits. The first relay will be the > target relay we are speed testing, and the second relay will be a fast exit > relay that we control. We will initiate data streams between a speedtest > client and server running on the same machine as our exit relay. > > The setup will look like: > > speedtest-client <--> tor-client <--> target-relay <--> exit-relay <--> > speedtest-server > > All components will run on the same machine that we control except for the > target-relay, which will rotate as we test different relays in the network. > For each target relay, we plan to run the speedtest for 20 seconds in order > to increase the probability that the 10 second mean goodput will reach the > true capacity. We will measure each relay over a few days to ensure that our > speedtest effects are reported by every relay. Where is your server? How do you expect the location of your server to affect your results? 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] DoS attack on Tor exit relay
Hi, > On 1 Aug 2019, at 02:27, Larry Brandt wrote: > > Yes, I have fail2ban installed but the attack is focused on my ORPort 9001. > Similarly, I have an external firewall but it permits 9001 port passage. If you're trying to prevent too many connections, you can adjust the DoS torrc options: DoSConnectionEnabled 1 DoSConnectionMaxConcurrentCount 1 DoSConnectionDefenseType 2 If that works, try adjusting DoSConnectionMaxConcurrentCount a bit higher: 10 or 25 are good values. 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] Windows Relay Setup
Hi, On July 11, 2019 10:58:07 PM UTC, William Pate wrote: >I'm interested in hosting a Windows-based relay, if anyone can point me >to a good tutorial. I've tried the most common ones. That's a good question. The Tor Relay Guide mainly covers Linux and BSD. None of the core tor developers run Windows relays, so our Windows support is not great. But we have had some enthusiastic Windows relay operators submit patches. Maybe they are around and can help? You could also try using the Tor Relay Guide platform-independent instructions, after installing the Windows Tor Expert bundle? T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] New Fallbacks from June 2019
Dear Relay Operators, Thanks to everyone who opted-in their relays as fallback directory mirrors. We rebuilt the list of fallbacks in June 2019. [0] The new list will be released in Tor 0.4.1.4-alpha/rc. It was backported to all supported Tor releases. [1] The FallbackDir flags on Consensus Health [2] and Relay Search [3] might take a week or two to update. Don't worry if your relay missed out this time. It's still helping Tor users. And we will rebuild the fallback list again in 6-12 months time. We are tracking future fallback changes in this ticket [4]. To opt-in your relays, add a comment to the ticket [4], or reply to this thread. If you have multiple relays, you can opt-in as many as you like. (We picked up to 7 per operator this time, and we may pick more next time.) T [0]: See: https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc https://trac.torproject.org/projects/tor/ticket/28793 [1]: 0.2.9, 0.3.5, 0.4.0, and 0.4.1: See https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current [2]: https://consensus-health.torproject.org/graphs.html Which uses stem's cached fallback list at: https://gitweb.torproject.org/stem.git/log/stem/cached_fallbacks.cfg [3]: For example, this relay is a new fallback, but its flag isn't shown yet: https://metrics.torproject.org/rs.html#details/1211AC1BBB8A1AF7CBA86BCE8689AA3146B86423 [4]: https://trac.torproject.org/projects/tor/ticket/30972 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] exit operators: overall DNS failure rate above 5% - please check your DNS resolver
> On 1 Jul 2019, at 21:41, Tyler Durden wrote: > > I can't really understand why our relays should fail so often because > the logs of our DNS daemon don't show anything and I haven't seen the > warning about nameservers that failed for a long time... > > Maybe the script that checks about DNS failures on Exits is not > reporting correctly? There are some other options worth considering: * the script is overloading its client, which fails some requests * the exit is overloaded with circuits or streams (and not DNS), so it fails some requests without a DNS query * DNS fails in a way that the exit doesn't detect and log Tor's DNS support is quite old, and it has had some significant bugs in the past. So I'd start looking there. It's also worth checking the health of your DNS resolver. Tor exits put an unusual amount of load on DNS: there are lots of requests, for lots of different domains. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] obfs4 relay lost stable flag
Hi, > On 1 Jul 2019, at 04:12, tor wrote: > > Hi > > I've been running an obfs4 bridge for about a month. > > My hashed fingerprint is: > E120A0492F789F5367EAD84C64F92EE279018F98 > > I recently lost the stable flag. Not sure why. > > Any thoughts? The Stable flag isn't relevant for bridges: Tor uses the bridges it is given, regardless of their flags. Your bridge might have been down or unreachable, or the average stability of *other* bridges might have increased: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2575 T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] torrelays have no bandwith
Hi, > On 27 Jun 2019, at 13:56, TorGate wrote: > > Hi to all, i have issues with my 3 relays, there is no bandwith ?! i have not > changed the config only updatet the tor software. In nyx can i see there are > smal bandwith connections 1-100 kbs. > All 3 relays have a 5mbit up/down connection. > https://metrics.torproject.org/rs.html#search/torgate It looks like your relays lost their state files during the upgrade. Your bandwidth should be back to normal after a few days. Did you know that TorGate3 is on 0.3.5.8, but the others are on 0.4.0.5? 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] Build problem
Hi, > On 25 Jun 2019, at 18:03, dns1...@riseup.net wrote: > > I'm trying to build tor What version of tor? > for from source on a x86 Debian stretch machine. I first installed all > dependencies, but when I launch the "./configure" command I see the following > error: > > configure: WARNING: Unable to find liblzma. > configure: WARNING: Unable to find libzstd There are a bunch of configure log lines that can help us diagnose the issue. Please paste the configure log lines that answer these questions: Did the configure fail, or did it complete successfully? (And just skip lzma and zstd.) > I installed, among the others liblzma-dev, lzma, libzstd-dev and zstd. Did you install pkg-config? Tor uses pkg-config to find lzma and zstd. What did configure say about pkg-config? What minimum versions of lzma and zstd was configure looking for? What did it find? > I'm working through ssh. What I'm doing wrong? > Could It be caused by a wrong environment variables settings? PKG_CONFIG_PATH needs to contain the path of the lzma and zstd pkg-config files. That should happen automatically, but it might not work with older lzma and zstd Debian packages. You could also try giving configure the paths to lzma and zstd. See configure --help for details. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] fresh assault on Tor network
Hi, > On 25 Jun 2019, at 09:32, Gunnar Wolf wrote: > > Signed PGP part > teor dijo [Sun, Jun 23, 2019 at 02:54:51PM +1000]: >>> https://metrics.torproject.org/userstats-relay-country.html?start=2017-06-22=2019-06-22=all=off >> >> It seems to be a significant increase in users all over Iran: >> >> https://trac.torproject.org/projects/tor/ticket/30636#comment:8 >> >> https://metrics.torproject.org/userstats-relay-country.html?start=2017-06-22=2019-06-22=ir=off > > If all those users are detected to be connecting directly from Iran, > and following the text written in that very page you mention: > >This graph shows the estimated number of directly-connecting >clients; that is, it excludes clients connecting via bridges. > > Does this mean that Tor is no longer blocked from within Iran (and > users no longer need to connect via bridges)? Any other explanations? > > Anyway, I still find the sharp uptake in direct connections quite > odd. People connecting via obfs4 (which continues to work just fine) > wouldn't migrate to direct connections massively as this shows... It looks like many clients in Iran can't download the full consensus, so they keep on trying. And Tor is measuring directory requests, even if the client fails to download the response. Follow the ticket for more details. 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] Become a Fallback Directory Mirror
Hi, > On 24 Jun 2019, at 02:49, tscha...@posteo.de wrote: > > On 2019-06-23 14:32, teor wrote: > >> But your relay needs a DirPort to be a fallback directory mirror. >> Here are some instructions for different platforms: >> https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#PlatformspecificInstructions > > This should be clarified in the Tor manual [1] too! > > "Tor will contact the authority at ipv4address to download directory > documents. The provided port value is a dirport; clients ignore this in > favor of the specified "orport=" value. If an IPv6 ORPort is supplied, > Tor will also download directory documents at the IPv6 ORPort." > > Am I right that for fallback directory mirrors DirPort is needed but > ignored by clients? It is needed to make sure that the relay serves directory documents. We run a script that uses the DirPort to check the download speed. > Possibly this explains why I lost the fallback > directory flag since I have removed the DirPort in torrc … Fallbacks need the same ports, IP addresses, and keys for 2 years. That includes the DirPort. It's not possible to configure a fallback without a dirport: FallbackDir ipv4address:port orport=port id=fingerprint [weight=num] [ipv6=[ipv6address]:orport] (The first port is a dirport, and both dirport and orport are required.) I have updated the template: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors/FallbackEmailTemplate?action=diff=2 And opened a ticket for the man page: https://trac.torproject.org/projects/tor/ticket/30955 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] Become a Fallback Directory Mirror
Hi, > On 23 Jun 2019, at 23:52, Toralf Förster wrote: > > Signed PGP part > On 5/21/19 3:32 PM, gus wrote: >> [1] >> https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors > > contgains outdated links > >> [3] >> https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist > 404 Thanks, the correct links are here: https://lists.torproject.org/pipermail/tor-relays/2019-May/017323.html We've updated the template for next 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] Become a Fallback Directory Mirror
Hi jajtor, > On 16 Jun 2019, at 03:07, TOR wrote: > > On 21/05/19, gus wrote: >> Dear Relay Operators, >> >> Do you want your relay to be a Tor fallback directory mirror? >> Will it have the same address and port for the next 2 years? >> Just reply to this email with your relay's fingerprint. > > C6B656BA6BC16E31115A1B2D56396A53165F3408 Your relay needs a DirPort to be a fallback directory mirror. Here are some instructions for different platforms: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#PlatformspecificInstructions Please let us know when you've configured one. 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] Become a Fallback Directory Mirror
Hi Nikos, > On 7 Jun 2019, at 20:05, Nikos Roussos wrote: > > On 21/05/19, gus wrote: >> Dear Relay Operators, >> >> Do you want your relay to be a Tor fallback directory mirror? >> Will it have the same address and port for the next 2 years? >> Just reply to this email with your relay's fingerprint. > > E8D114B3C78D8E6E7FEB1004650DD632C2143C9E Your relay needs a DirPort to be a fallback directory mirror. Here are some instructions for different platforms: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#PlatformspecificInstructions Please let us know when you've configured one. 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] Become a Fallback Directory Mirror
Hi Marek, > On 23 Jun 2019, at 22:28, teor wrote: > >>> Il 21 maggio 2019 15:32:57 CEST, gus ha scritto: >>> Dear Relay Operators, >>> >>> Do you want your relay to be a Tor fallback directory mirror? >>> Will it have the same address and port for the next 2 years? >>> Just reply to this email with your relay's fingerprint. > >> On 7 Jun 2019, at 02:30, Marek Worreschk wrote: >> >> A850B6A31ED83FB92B34FB3AE0513902D053A1C8 > > It looks like your relay has been down for at least a week. > So we can't add it to the fallback whitelist. > > Please let us know when it's back up. Oops, sorry, I got your relay mixed up with another one. It is actually up. But your relay needs a DirPort to be a fallback directory mirror. Here are some instructions for different platforms: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#PlatformspecificInstructions Please let us know when you've configured one. 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] Become a Fallback Directory Mirror
Hi Kushal, > On 7 Jun 2019, at 00:31, Kushal Das wrote: > > On 21/05/19, gus wrote: >> Dear Relay Operators, >> >> Do you want your relay to be a Tor fallback directory mirror? >> Will it have the same address and port for the next 2 years? >> Just reply to this email with your relay's fingerprint. >> > A85FF376759C994A8A1168D8D8219C8C43F6C5E1 It looks like your relay has been down for at least a week. So we can't add it to the fallback whitelist. Please let us know when it's back up. 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] Become a Fallback Directory Mirror
Hi, >> Il 21 maggio 2019 15:32:57 CEST, gus ha scritto: >> Dear Relay Operators, >> >> Do you want your relay to be a Tor fallback directory mirror? >> Will it have the same address and port for the next 2 years? >> Just reply to this email with your relay's fingerprint. > On 7 Jun 2019, at 02:30, Marek Worreschk wrote: > > A850B6A31ED83FB92B34FB3AE0513902D053A1C8 It looks like your relay has been down for at least a week. So we can't add it to the fallback whitelist. Please let us know when it's back up. 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] Become a Fallback Directory Mirror
Hi, >> Il 21 maggio 2019 15:32:57 CEST, gus ha scritto: >> Dear Relay Operators, >> >> Do you want your relay to be a Tor fallback directory mirror? >> Will it have the same address and port for the next 2 years? >> Just reply to this email with your relay's fingerprint. > > On 22 May 2019, at 02:26, tor-re...@riseup.net wrote: > > 2206C72ECC0D55593BC7B698F982533F1E141DD2 It looks like your relay has been down for the last 6 days. So we can't add it to the fallback list. Please let us know when it's back up. 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] fresh assault on Tor network
Hi, > On 22 Jun 2019, at 17:23, starlight.201...@binnacle.cx wrote: > > https://metrics.torproject.org/userstats-relay-country.html?start=2017-06-22=2019-06-22=all=off It seems to be a significant increase in users all over Iran: https://trac.torproject.org/projects/tor/ticket/30636#comment:8 https://metrics.torproject.org/userstats-relay-country.html?start=2017-06-22=2019-06-22=ir=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] Moving Exit Node
Hi, > On 20 Jun 2019, at 07:28, Yggdrasil Admin wrote: > > Hi at all. > Yesterday i was kicked by my hosting provider urdn (https://urdn.com.ua) > kicked me because "someone we can't name here, wasn't happy" about what i did > on a non urdn server. That's why they nullrouted my ipv4 and made the Exit > Node inaccessible. After a talk with the support over jabber he told my that > the server was still accessible over ipv6 so i backuped my identity keys and > tried to setup my exit node on another server which wasn't possible because > it alway tried to connect to the nullrouted ipv4. My main question is: Can i > setup my exit node on another server with another ipv4 or is this impossible? Yes, copy the keys directory to the new server. Update the Address, ORPort, DirPort, and OutboundBindAddress* lines in your torrc. See this FAQ for more details: https://2019.www.torproject.org/docs/faq#UpgradeOrMove 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 Debian repo update
Hi, > On 20 Jun 2019, at 01:20, Peter Ludikovsky wrote: > > Does the official Tor Project repo provide upgrades to the new 0.4.0.5 > stable for anyone? I can see the new packages in pool/main/t/tor/, but > the package index in dists/stretch/main/binary-amd64/Packages still > points to 0.3.5.8. I'm not sure why, but it's only in tor-experimental-0.4.0.x-stretch. Try: deb https://deb.torproject.org/torproject.org stretch main deb-src https://deb.torproject.org/torproject.org stretch main deb https://deb.torproject.org/torproject.org tor-experimental-0.4.0.x-stretch main deb-src https://deb.torproject.org/torproject.org tor-experimental-0.4.0.x-stretch main If you add tor-experimental-0.4.0.x-stretch, then you will upgrade to 0.4.0 now. If you keep the stretch line, you will automatically stay with the latest version, even when tor-experimental-0.4.0.x-stretch goes away. We haven't updated the tor versions on this web page, either. But we'll get there: https://2019.www.torproject.org/docs/debian.html.en 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] Questions about relays on IPv6
Hi, > On 19 Jun 2019, at 05:56, tscha...@posteo.de wrote: > > I have enabled IPv6 on my Relay [1] and setup a new one [2]. > Both got the additional Flag 'ReachableIPv6' - fine. > > In the 'IPv6 HOWTO' [3] I found: > > "Since clients only use the ORPort (because it's more anonymous2), and > relays only use IPv4, there is no reason to configure an IPv6 DirPort - > if you do, it will never be used." > > Hmm - 'relays only use IPv4' seems to be true. Until now I can see only > incoming connections from the authorities; no other IPv6 and no outgoing > IPv6 connection while on [1] there are over 6800 und on [2] over 4800 > IPv4 connections! > > So I wonder: Does it make sense to setup IPv6 non-exit relays when IPv6 > is not used? Or must I wait patiently - how long? If your relay becomes a Guard, a small number of clients will use its IPv6 ORPort. We want to use IPv6 more in tor, but we have to write the code to do it, and work out if it has any anonymity issues. I updated the wiki page so it is clearer: https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto?action=diff=13 > [1] 6A7551EEE18F78A9813096E82BF84F740D32B911 (Tormachine) > [2] 9556D34D97C0382E8B9901B036ACAA2F2B453FEC (Tormachine2) > [3] https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Home Router limits question
Hi, > On 15 Jun 2019, at 02:14, to...@protonmail.com wrote: > > Would tor show something in its log if I were hitting my router's limit? > Seeing nothing there or in my router's gui log interface, but not sure what I > should expect to see. It's hard for tor to work out the difference between a relay that's not being used, a slow relay, and a relay that is being restricted by the router. We expect fast, busy relays to have about 5000 connections open all the time. Can you tell us the fingerprint of your relay, and how many connections it has open right now? There should be a heartbeat message in 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] Relay Consensus Low
Hi, > On 2 Jun 2019, at 16:57, Matt Westfall wrote: > > Hey toer, I actually removed the Bandwidth Rates per another suggestion. You might need to wait a week or two for the new setting to increase your bandwidth. It takes a few days for the bandwidth authorities to measure the whole network. > Just sucks I can donate more to the TOR Network, but because other people > abused the advertised bandwidth settings now it is what it is. I'm sorry, but Comcast's peering is the problem here, not Tor. Tor clients choose random relays, regardless of their location. So we need to measure how well your relay connects to the rest of the world. Lots of relay operators expect Tor to use all their bandwidth. But Tor is low-latency, so it should never use all a relay's bandwidth. (10% is ideal, 30% is typical, any more than that causes lots of latency for clients.) There's a detailed explanation on this wiki page: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow#WhyRelayLoadVaries > Also I guess the fact that most of the traffic across tor is http/https It's > not ever going to "observe" a whole lot because it's quick small packets of > data. Tor Browser regularly downloads 100MB+ updates over Tor. And people use Tor for other bulk downloads. And remember: clients choose relays at random, so all relays see a similar mix of small and large downloads. > I moved it to another IP and put it on 443 / 80 so maybe that will help cause > firewalls and such. It's also directly on a public wan IP now, so > firewall/router complications. If you keep your relay stable for a few weeks, it will probably get the Guard flag again. Relays with the Guard flag get more traffic. > I didn't see if anyone answered if I need a separate IP or if I can create > another tor instance on different ports but on the same IP, to increase the > load I'm handling. You can create 2 relays per IPv4 address: >> On 27 May 2019, at 11:54, Igor Mitrofanov >> wrote: >> >> Matt, if you only have 1 host, it may be more beneficial to create 2 >> relays on it (or more than 2 - if you have more than 1 IPv4 address >> available) using tor-instance-create. You could be hitting the limits >> of what a single CPU core can do. Even if your relay isn't used much for client traffic, it still works well as a directory mirror for relay and onion service information. If you'd like Tor to use more of your traffic, and your relay will be on the same address and port for the next 2 years, you can sign up as a fallback directory mirror: https://lists.torproject.org/pipermail/tor-relays/2019-May/017321.html Since you just changed your relay port, your relay won't be included in the June 2019 list. But we'll do another list in 6-12 months. 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] Onionoo and ASN Number/AS Name
Hi, > On 2 Jun 2019, at 15:14, Conrad Rockenhaus wrote: > > Onionoo returns “unknown” for my ASN for some reason (should return 63080) > and returns “unknown” for AS Name (Should be GreyPony Consultants - as named > in ARIN). I’m trying to find out where things might be potentially breaking > here before I start connecting to the route servers at DE-CIX next week. Has > anyone seen this type of issue before? Onionoo uses MaxMind's AS database, which is slow to update: https://trac.torproject.org/projects/tor/ticket/26585 If you use RIPE, you can see that the AS is present in IANA and WHOIS, but not in MaxMind: https://stat.ripe.net/63080 T 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 Consensus Low
Hi, > On 1 Jun 2019, at 14:57, Matt Westfall wrote: > > Hello thanks for the comments, I might do that, remove the limits, because > it's self limiting by the 1 Gbps network port, so it can't use more than that > anyway. Following the instructions here: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow#TorNetworkLimits It looks like your relay is limited by its own observed bandwidth. (The observed bandwidth that your relay has seen itself using.) So increasing the RelayBandwidthRate would be a good idea. If your relay's observed bandwidth gets above 9 megabytes a second, your relay will be limited by the bandwidth authorities' measurements. (The median measurement for your relay is 8910 scaled kilobytes per second.) https://consensus-health.torproject.org/consensus-health-2019-06-02-04-00.html#B1B10104EB72A1FBBF6687B05F1915D87D00DBDE There might not be much you can do about this: Comcast has slow peering with a large number of internet networks. And it looks like 4/6 of tor's current bandwidth authorities are on those networks. This isn't something Tor can fix: we can only measure the bandwidth that Comcast is giving you. If Comcast has slow peering to US East and Europe, then clients using your relay will be slow. > I tried to run chutney tests to see what hardware supports but haven't quite > figured out what the command line I should be using is. > > Any help with that would be appreciated. You're right, the README is more confusing than it needs to be. Try: ./chutney/tools/test-network.sh --data $[10*1024*1024] If a 10 MB transfer is too fast, try 100 MB. I opened this ticket for us to fix our documentation: https://trac.torproject.org/projects/tor/ticket/30720 T 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] Auto Upgrading Tor Using Unattended Ugrades
> On 31 May 2019, at 10:34, Keifer Bly wrote: > > Upon trying to open that folder, I got this. > > var/log/unattended-upgrades: No such file or directory Try a leading slash: /var/log/unattended-upgrades T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Low
Hi, > On 25 May 2019, at 01:13, Matt Westfall wrote: > > My tor node: > https://metrics.torproject.org/rs.html#details/B1B10104EB72A1FBBF6687B05F1915D87D00DBDE > > Doesn't ever go up above 8800 or so. > > One thing I notice in Nyx is that my connections never go above about 2000 in > and out connections. That's unusual, because there are about 7,000 relays in the network. How many simultaneous connections does your router support? (Lots of them claim to support unlimited connections, but only support a few hundred or a few thousand.) > I have advertised bandwidth of just shy of a gigabit in my config. I > understand now that the "advertised bandwidth" is calculated based on > observed traffic through the node, which while more reliable and avoids > abuse, seems to be counter productive to a degree. > > Ultimately what do I need to do to get more traffic through my node? Cause I > have a 2Gbps fiber sitting here basically doing nothing so I was giving 1Gbps > to tor :) You could remove all the bandwidth limits, and put them back in when tor is using more than you want it to. (Tor tries to keep some extra bandwidth to deal with traffic spikes, so a 1 Gbps limit will get you around 300 kbps sustained traffic.) Here's a more detailed explanation, and some other things to try: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Auto Upgrading Tor Using Unattended Ugrades
Hi, > On 28 May 2019, at 06:18, Keifer Bly wrote: > > So I am now auto upgrading tor using the method at > https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpdates > > > Upon testing, this is what I got. > > … > > No packages found that can be upgraded unattended and no pending > auto-removals > > What I am attempting to do is automatically install new tor versions when > they are released. Will this do that automatically? How can I keep this > process running? Step 4 of the instructions runs the process automatically every day. You will also need to follow these instructions to get the latest tor version: > From my last email: > When I tried updating tor I got a message saying that was the newest version. >>> >>> It looks like you're on Debian or Ubuntu, please follow these instructions >>> to update: >>> https://2019.www.torproject.org/docs/debian.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] Tor relay says it is reachable, but is not appearing on the network.
Hi, > On 24 May 2019, at 11:41, Keifer Bly wrote: > > Hi all, so I believe I found the problem. In my torrc file, there was a rogue > line which read "PublishServerDescriptor" with nothing after it. I removed > this line and restarted the relay, now it is saying "May 24 01:38:16.000 > [notice] Self-testing indicates your ORPort is reachable from the outside. > Excellent. Publishing server descriptor. > May 24 01:38:20.000 [notice] Performing bandwidth self-test...done." > > So it seems this solved the problem. It looks like your relay changed keys about 2 hours ago: https://metrics.torproject.org/rs.html#search/torworld If you keep changing your relay keys, it won't be used very much. > Now, I am also wondering, is there a tool that can be used to automatically > update tor? Thank you. Yes! From my last email: >>> When I tried updating tor I got a message saying that was the >>> newest version. >> >> It looks like you're on Debian or Ubuntu, please follow these instructions >> to update: >> https://2019.www.torproject.org/docs/debian.html.en >>> May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, >>> and you probably shouldn't. >> >> I don't know how you are configuring and running your relay. Using a guided >> relay configuration tool might help you. See my suggestion below. >> You seem to have a lot of trouble configuring relays manually. >> You might have a better experience with a guided setup tool, like this >> Tor Relay role in Ansible: >> https://github.com/nusenu/ansible-relayor I really think that something like ansible is your best chance of having a working relay. 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 says it is reachable, but is not appearing on the network.
Hi, > On 24 May 2019, at 14:08, Conrad Rockenhaus wrote: > > In April 2018 Google released an update that caused VPNs and Tor services to > stop working on GCE and App Engine. It was a long planned network update. > > The following ticket refers: > https://trac.torproject.org/projects/tor/ticket/25804 That ticket is about domain-fronting, which is used by meek and snowflake bridges. But these issues do not affect other relays. Do you have any information about Google blocking relays? 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 says it is reachable, but is not appearing on the network.
Hi, > On 24 May 2019, at 09:19, Keifer Bly wrote: > > Hi all, so this is the tor log since the last restart. It includes the relay > fingerprint. The tor version is (0.2.9.16-1). The log you posted is missing a few lines at the start, including the lines that tell us the tor version. We need to see the tor version that is *running*, not the tor version that you installed. Just in case they are different. (Authorities reject really old Tor versions.) > When I tried updating tor I got a message saying that was the > newest version. It looks like you're on Debian or Ubuntu, please follow these instructions to update: https://2019.www.torproject.org/docs/debian.html.en > The relay has an assigned static ip and port which are both allowed by the > firewall. It seems strange that > Dmitrii Tcvetkov was able to reach the relay though teor cannot, We looked in different places: Dmitrii connected to the IP and ports of your relay using SSL. I looked for your relay in the votes and the consensus, but I did not find it. > also that the relay says it is reachable and receiving traffic but not > appearing in the relay list. I think your relay is not publishing its descriptor. See my comments below about the relay log. > It seems like the relay > would not be able to start at all if Google was blocking it. There are lots of different ways to block relays. Some let the relay start, but it never gets in the consensus. But I don't think that has happened to your relay. > May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, > and you probably shouldn't. I don't know how you are configuring and running your relay. Using a guided relay configuration tool might help you. See my suggestion below. > May 21 20:01:33.000 [notice] Your Tor server's identity key fingerprint is > 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2' I have confirmed that this fingerprint is not in the votes or consensus. > May 21 20:01:33.000 [notice] Bootstrapped 0%: Starting > May 21 20:03:53.000 [notice] Bootstrapped 80%: Connecting to the Tor network > May 21 20:03:54.000 [notice] Guessed our IP address as 104.154.93.253 > (source: 128.31.0.34). 128.31.0.34 is the IP address of moria1, so your relay can connect to the directory authorities. That means that Google isn't blocking connections out. > May 21 20:03:58.000 [notice] Bootstrapped 100%: Done > May 21 20:03:58.000 [notice] Now checking whether ORPort 104.154.93.253:65534 > is reachable... (this may take up to 20 minutes -- lookfor log messages > indicating success) > May 21 20:04:01.000 [notice] Self-testing indicates your ORPort is reachable > from the outside. Excellent. Your relay and Dmitrii have confirmed that this port is reachable from the outside. But your relay log does not say "Publishing server descriptor." That's why your relay is not in the votes or the consensus. So we need to answer these questions: * Is your relay configured as a bridge? * Is your relay configured to *not* publish its descriptor? (Relays publish their descriptors by default.) Please copy and paste your torrc into your next email. Your logs were also missing these things: > * tor version, > * role (relay or bridge), and > * descriptor posts to authorities. Please post the parts of your logs that contain this information. There is no need to paste more than 2 repetitions of the Heartbeat/Cell/Circuit/Connection/DoS lines. You seem to have a lot of trouble configuring relays manually. You might have a better experience with a guided setup tool, like this Tor Relay role in Ansible: https://github.com/nusenu/ansible-relayor T > On Thu, May 23, 2019 at 2:09 PM teor wrote: > > On 23 May 2019, at 18:41, Dmitrii Tcvetkov wrote: > >> On Tue, 21 May 2019 23:36:28 -0700 >> Keifer Bly wrote: >> >>> Hi, so the relay in question does indeed have a reserved Static IP >>> (104.154.93.253), and the traffic is allowed by the firewall, but the >>> relay is still not appearing in the consensus. The port it's running >>> on is 65534. This is starting to seem odd.any thoughts are >>> appreciated. Thanks. --Keifer >>> >> >> Indeed, I don't have any problem connecting to your relay with openssl >> from multiple locations (at least Russia, Netherlands and Germany): >> >> >> $ openssl s_client -connect 104.154.93.253:65534 >> >> Certificate chain >> ... > > I can't find a relay called "torworld" or at "104.154.93.253" on the tor > network: > * using consensus health, which shows relays with votes: > https://consensus-health.torproject.org/ > * or relay search, which shows relays in the consensus: > https://metrics.torproject.org/rs.html#search/104.154.93.253 > >
Re: [tor-relays] Tor relay says it is reachable, but is not appearing on the network.
Hi, > On 23 May 2019, at 18:41, Dmitrii Tcvetkov wrote: > > On Tue, 21 May 2019 23:36:28 -0700 > Keifer Bly wrote: > >> Hi, so the relay in question does indeed have a reserved Static IP >> (104.154.93.253), and the traffic is allowed by the firewall, but the >> relay is still not appearing in the consensus. The port it's running >> on is 65534. This is starting to seem odd.any thoughts are >> appreciated. Thanks. --Keifer >> > > Indeed, I don't have any problem connecting to your relay with openssl > from multiple locations (at least Russia, Netherlands and Germany): > > > $ openssl s_client -connect 104.154.93.253:65534 > > Certificate chain > ... I can't find a relay called "torworld" or at "104.154.93.253" on the tor network: * using consensus health, which shows relays with votes: https://consensus-health.torproject.org/ * or relay search, which shows relays in the consensus: https://metrics.torproject.org/rs.html#search/104.154.93.253 Please copy and paste the latest logs from your relay the last time you started it up. We need to see logs that cover your relay's: * tor version, * role (relay or bridge), * nickname, * fingerprint, * IPv4 address, * reachability self-test, and * descriptor posts to authorities. We might need info-level logs to see some of these things. Do you know if Google supports tor relays? They could be blocking some connections. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] forward relay connections
Hi, > On 22 May 2019, at 16:24, tor-re...@riseup.net wrote: > > Do you think would be feasible to use SSH to forward all connections, except > DNS queries, between my Lime2 and the remote VM in order to use an additional > VM's IP? I just wanted to highlight the DNS queries from your home address. It's risky for you to allow anyone on the internet to use your home DNS. Your ISP may terminate you or report you to the police for looking up some sites. (Or they may block your exit users *from* looking up some sites.) The DNS load might also be more than your ISP can handle. There is also the risk that your forwarding fails, and all the exit traffic comes from your home IP. 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 says it is reachable, but is not appearing on the network.
Hi, > On 21 May 2019, at 16:11, Keifer Bly wrote: > > Hi all, something very strange is going on with my relay called torworld. This looks like the same question as your previous thread: https://lists.torproject.org/pipermail/tor-relays/2019-May/017317.html Did you assign a static address to your relay? Did you set up port forwarding correctly? Your relay is only receiving a few connections (5) from the outside. But you should be seeing many more connections. At least 1 connection from each of 9 authorities, every few hours. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ipv6 behaviour consensus
Hi, > On 19 Apr 2019, at 07:41, Charly Ghislain wrote: > > I feel there is an issue in case the operator advertises an unreachable ip6 > address in the config. This seems like a configuration error that should be > spotted by a self-reachability mechanism that is yet to come, like for ipv4. > I can imagine however that directories could be able to flag the relay as > reachable over ipv4 and not over ipv6, and that the relay would still be > usable over ip4. I thought it was the case actually. We asked the directory authority operators what they wanted Tor to do when relays are reachable over IPv4 but not IPv6. They told us that the relays should not be in the consensus, because then operators would notice, and fix them. (As Jake Visser did.) We also talked with relay operators, and there were a range of different opinions. If we want to have enough IPv6 relays to support lots of IPv6 clients, we need every relay that can do IPv6, to have working IPv6. > On 19 Apr 2019, at 08:46, s7r wrote: > > One use I can think for this is in a world where an IPv6 only client > gets to use such a relay as Guard, by connecting it to its advertised > IPv6 address (regardless that will be actually converted to IPv4 before > it hits the relay, this will be transparent to the client and will > actually work). I think having more ways to do IPv6 is useful as we transition to IPv6. When most relays support IPv6, we can start deprecating some of the less useful ways of doing IPv6. But we're not there yet. > On 19 Apr 2019, at 08:54, Jake Visser wrote: > > Thanks Charly – yes.. in this case a flag or error in logging that IPv6 was > not reachable would have saved me many hours of debugging (for us, this was > an obscure IPv6 issue, where all other IPs on the same range work; it was > broken as a function of a very restrictive ND policy on the firewall). > > So regardless of Full v6 support, or v6 only support [both are needed], at > the very least some good logging to say if its failing would be great After a few hours, your relays should have warned you that they were not in the consensus. Maybe you missed the warning, because you were looking at debug logs? A relay can't tell you that its own IPv6 address is unreachable, because it never checks its IPv6 address for reachability. We have a ticket to implement IPv6 reachability checks, but it's more complex than you might expect, because relays don't extend to other relays over IPv6 yet. https://trac.torproject.org/projects/tor/ticket/24403 We're working on getting funding for IPv6 improvements in 2020, and this feature will be first. (There's no point in making clients do IPv6 better, if we don't have enough IPv6 relays.) 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] Making use of new bandwidth
>> On 8 Apr 2019, at 07:57, teor wrote: >> >>> The reason I ask is that I wonder if I should run a second Tor instance or >>> if the current one will be able to make use a a reasonable part of the >>> 500Mps. >> >> It looks like your relay could be CPU-core-limited, or limited by some other >> local resource, or limited by its location. >> >> To work out where the limit is, run another Tor instance. > On 8 Apr 2019, at 13:00, Conrad Rockenhaus wrote: > > If Tor doesn't scale on multicore CPUs, setting NumCPUs to 2 and > running two threads has no effect at all on throughput? On most systems, Tor automatically sets NumCPUs to the number of physical CPU cores. Tor is partially multithreaded, so those extra threads do make a difference. But if your tor process is limited by main thread operations, then you need to run another tor process. 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] Making use of new bandwidth
One more thing: > On 8 Apr 2019, at 07:57, teor wrote: > > Hi, > >> On 7 Apr 2019, at 05:19, Logforme wrote: >> >> I run the non-exit relay: >> https://metrics.torproject.org/rs.html#details/855BC2DABE24C861CD887DB9B2E950424B49FC34 >> The relay run on a debian stretch machine with an i5-4670 at 3.8GHz with 4GB >> memory. CPU usage at 250Mbps traffic is around 40% of 1 core out of 4. >> >> On April 1st my ISP doubled my bandwidth, from 250Mbps to 500Mbps. >> So far the Tor bandwidth authorities seems to not have picked up on all the >> new bandwidth. The observed bandwidth number has changed twice, increasing >> with small amounts. >> >> How long does it take for the BW authorities to eventually observe a BW >> closer to 500Mbps. Weeks? Months? > > Your relay observes its own bandwidth, and tells the bandwidth authorities the > maximum over the last 5 days. > > Looking at the 6 months graph from 1 April, your relay's observed bandwidth > has > increased about 5-10%. A small increase per week isn't bad for a guard: even > if > your consensus weight goes up, it takes time for clients to rotate guards. > > The bandwidth authorities also measure the excess bandwidth on your relay > every few > days, and combine their measurements with your relay's observed bandwidth to > generate their consensus weight votes. The consensus value is the low-median > of > those votes. > > Looking at the consensus weight graph, the votes haven't changed much at all. > > (The consensus weight changes the number of clients that use your relay, which > increases its observed bandwidth, but decreases the measured bandwidth. > Eventually > these changes balance out.) > >> The reason I ask is that I wonder if I should run a second Tor instance or >> if the current one will be able to make use a a reasonable part of the >> 500Mps. > > It looks like your relay could be CPU-core-limited, or limited by some other > local resource, or limited by its location. It's probably a local resource, because the bandwidth authority measurements don't vary much, even though the bandwidth authorities are on two different continents: https://consensus-health.torproject.org/consensus-health-2019-04-07-20-00.html#855BC2DABE24C861CD887DB9B2E950424B49FC34 > To work out where the limit is, run another Tor instance. > > You could also wait another week to see if your relay picks up another 5-10% > traffic increase. > > 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] Making use of new bandwidth
Hi, > On 7 Apr 2019, at 05:19, Logforme wrote: > > I run the non-exit relay: > https://metrics.torproject.org/rs.html#details/855BC2DABE24C861CD887DB9B2E950424B49FC34 > The relay run on a debian stretch machine with an i5-4670 at 3.8GHz with 4GB > memory. CPU usage at 250Mbps traffic is around 40% of 1 core out of 4. > > On April 1st my ISP doubled my bandwidth, from 250Mbps to 500Mbps. > So far the Tor bandwidth authorities seems to not have picked up on all the > new bandwidth. The observed bandwidth number has changed twice, increasing > with small amounts. > > How long does it take for the BW authorities to eventually observe a BW > closer to 500Mbps. Weeks? Months? Your relay observes its own bandwidth, and tells the bandwidth authorities the maximum over the last 5 days. Looking at the 6 months graph from 1 April, your relay's observed bandwidth has increased about 5-10%. A small increase per week isn't bad for a guard: even if your consensus weight goes up, it takes time for clients to rotate guards. The bandwidth authorities also measure the excess bandwidth on your relay every few days, and combine their measurements with your relay's observed bandwidth to generate their consensus weight votes. The consensus value is the low-median of those votes. Looking at the consensus weight graph, the votes haven't changed much at all. (The consensus weight changes the number of clients that use your relay, which increases its observed bandwidth, but decreases the measured bandwidth. Eventually these changes balance out.) > The reason I ask is that I wonder if I should run a second Tor instance or if > the current one will be able to make use a a reasonable part of the 500Mps. It looks like your relay could be CPU-core-limited, or limited by some other local resource, or limited by its location. To work out where the limit is, run another Tor instance. You could also wait another week to see if your relay picks up another 5-10% traffic increase. 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] Another Slow Relay
Hi Ben, > On 4 Apr 2019, at 10:58, Ben Riley wrote: > > I've read over a couple of other threads regarding relays being slow, > however, I can't figure out why mine is running as slow as it is. Have you read our wiki page about slow relays? https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow What do you see when you follow the steps on that page? > I used to have a FAST flag and was getting a throughput of several hundred > KB/sec on my relay. Now I can't remember if I upgraded TOR or just updated > the OS, but I lost the flag. I figured that I'd changed something and would > have to 'earn' it again after a few days, week and now months? Normally, relays with slow or high-latency connections to North America and Europe won't get used much. Since you're on the other side of the globe, that's inevitable. > According to NYX, my average is 6.4KB/sec. I did have the limit set to 1MB > and 2MB burst for the last few months thinking that would be more than enough. > > This morning I changed those (via NYX) to 0 (default) 1GB/s and it looks like > it's starting to climb. Setting a limit faster than your connection makes Tor delay or drop packets. Since you already have high latency, drops or delays are going to make your measurements worse. > My internet connection is on a home set up with a connection speed of about > 97Mb, so plenty of speed available. Just use the speed of your connection. (And if it's asymmetric, use the minimum of your upload and download.) Careful with the difference between megabits and megabytes per second! > If you look at my previous reports > on:https://metrics.torproject.org/rs.html#details/9F19251CEE17B1E05084898D164F0544CCB095DD > there appears to be a massive drop off in speed during Feb 2019. I'm open to > suggestion. Looking at the 5 year graphs, your relay was used when the network was under heavy load for a few months in 2017/2018, and 2018/2019. Now the network isn't overloaded any more, clients don't need your relay as much, so it's back to its usual level. > Additionally, I'm considering opening an exit port, but everyone seems to say > that is a REALLY bad idea on a home set up. Plus I don't really know what I'm > doing :) Don't open an exit port at home, unless you like dealing with confused police officers. If you have another IPv4 address, consider setting up a bridge relay. (Bridges on the same IP as relays are easy to censor.) If you don't, try setting up another relay instance on the same IPv4. (There's a limit of two relays per IPv4 address.) 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] Relay C19B33758B3A5144894233EC4C95D7985B9FD101
Hi, > On 12 Mar 2019, at 05:34, ylms wrote: > >> On 3/9/19 5:07 AM, teor wrote: >> ORPort [IPv6]:Port >> >> For example: >> >> ORPort [2001:db8::1]:9001 >> >> Tor doesn't guess IPv6 addresses yet. > > That was very helpful to find my stupid mistake. We would like to make tor more helpful, and make it guess IPv6. But we're not there yet. Until then, people have to learn the details of tor'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] Please help, my relay is unresponsive
Hi, > On 10 Mar 2019, at 08:56, digitalist00 wrote: > > Sorry, germin because of your torrc-example: > I added MaxMemInQueues 1024 MB > LimitNOFile 5000 doesn't work, neither does LimitNOFILE = 5000 and I deleted > it. > Nyx didn't start anymore and then I first had to "chown ". > Tor is running again and nyx says "Relay unresponsive - Relay resumed - 3, no > 4 duplicates hidden. > I have traffic, some flags and everything seems fine except those nyx-notices. Maybe you're seeing a bug in nyx, and tor is ok? Have you tried reading tor's logs directly? (It looks like you are reading them through nyx.) Tor's logs should be at /var/log/tor/log , or a similar path. 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] bastet BW scanner barking mad
Hi, > On 9 Mar 2019, at 14:04, teor wrote: > > It's probably a bug in the scaling in the dev version of sbws It is a kilobyte-to-byte scaling bug: https://trac.torproject.org/projects/tor/ticket/29707 > No need to stress. Medians are designed to ignore outlying values like this. > We'll get it fixed soon. If you scroll down these graphs, you can see that bastet is below the median for almost all relays: https://consensus-health.torproject.org/graphs.html#bwauthgraphs The change is too recent to be in the metrics graphs: https://metrics.torproject.org/totalcw.html 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] Relay C19B33758B3A5144894233EC4C95D7985B9FD101
Hi, > On 9 Mar 2019, at 13:08, Roger Dingledine wrote: > >> I also have some questions. >> >> Atlas does not show any IPv6 address, is this normal? > > I see that you have an ipv6 exit policy set, but I don't see any > ipv6 address in your relay descriptor. > > (You can see your relay descriptor with > "wget 5.199.130.188/tor/server/authority" ) > > If you were advertising an ipv6 address, you would have an "or-address" > line in your descriptor. Compare to Fission1's descriptor: > "wget 158.69.30.132/tor/server/authority" If you want to set an IPv6 address, use: ORPort [IPv6]:Port For example: ORPort [2001:db8::1]:9001 Tor doesn't guess IPv6 addresses yet. 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] bastet BW scanner barking mad
> On 9 Mar 2019, at 13:36, starlight.201...@binnacle.cx wrote: > > Anyone know what caused bastet's loss of grip on reality? > > > 600 IPredator > 440 xenoidRelay > 300 PrivacyRepublic0001 > 270 ExitNinja > 260 DipulseIT2 > 240 hyacinthinus > 230 PIAzrhexit > 230 Unnamed > 220 volatile > 210 Chenjesu > 210 drazisil > 210 exit3 > 210 radieschen > 200 Spigen > 200 TotorBE2 > 200 tagos It's probably a bug in the scaling in the dev version of sbws, or the machine that sbws is running on is very slow: bandwidth-file-headers timestamp=1552095292 version=1.2.0 destinations_countries=HK,ZZ,US earliest_bandwidth=2019-03-04T01:35:26 file_created=2019-03-09T01:35:03 generator_started=2019-03-09T00:00:59 latest_bandwidth=2019-03-09T01:34:52 minimum_number_eligible_relays=3970 minimum_percent_eligible_relays=60 number_consensus_relays=6616 number_eligible_relays=6247 percent_eligible_relays=94 scanner_country=US software=sbws software_version=1.0.3-dev0 http://204.13.164.118/tor/status-vote/current/authority No need to stress. Medians are designed to ignore outlying values like this. We'll get it fixed soon. 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] IPv6 ORPort autodetection on relays (Was: Re: Running 2 relays with 0.4.0.2_alpha [err] descriptor at 0x8a0acdb0830 begins with unexpected string "".)
> On 1 Mar 2019, at 10:26, s7r wrote: > > teor wrote: >> >> >> Cc'ing Linus, because he is also interested in IPv6. >> >> On 28 Feb 2019, at 19:01, s7r mailto:s...@sky-ip.org>> >> wrote: >>> >>> However, shouldn't the line: >>> ORPort 9050 >>> >>> bind to all v4 and v6 available interfaces / IP addresses? If it does >>> not, we should fix it to do so. As in: >>> >>> ORPort 9050 - bind to all available v4 and v6 >>> ORPort 0.0.0.0:9050 - bind to all available from the v4 class >>> ORport [::]:9050 - bind to all available from the v6 class >>> ORPort :port - bind to specified address exactly >> >> Tor already binds to IPv4 and IPv6 by default. >> But it only autodetects IPv4 addresses. >> (Binding to IPv6 doesn't really do much, if you don't have an IPv6 >> address to advertise.) >> > > Oh > I thought IPv6 needs to be stated explicitly or at least generally by > omitting IPv4 at all even as the general 0.0.0.0. > > So ORPort 0.0.0.0:9001 would bind to all IPv4 and IPv6 available > addresses on a server? No, 0.0.0.0 is an IPv4 address, so Tor only binds to IPv4. [::] is the equivalent IPv6 address, but that doesn't work for ORPorts, because Tor doesn't autodetect IPv6 addresses. (I think you can specify Address [IPv6], but I'm not sure if that works the way it should. We should fix it along with autodetection.) > The same would ORPort 9001 ? Yes, a missing address means IPv4 and IPv6, if the OS supports it. (There are flags that turn off IPv4 or IPv6 binding, too.) >> I'd love to make Tor autodetect IPv6 addresses. >> >> Here's what we need to do to make that happen: >> 1. make relays extend over IPv6 >> * these relays should declare a new protocol version "IPv6Relay=1" >> 2. make relays check their IPv6 ORPorts for reachability using an IPv6Relay >> * make relays connect to their own IPv6 ORPort (needs 1) >> * detect and track IPv4 and IPv6 ORPort reachability separately >> 3. make relays autodetect an IPv6 address (needs 2) >> >> Here's the parent ticket for this change: >> https://trac.torproject.org/projects/tor/ticket/24403 >> >> Our next step is to write a proposal for this change. >> (There is already some code in some of the tickets.) > > Sounds like a good plan. > > I'd love that too -- but the thing I am thinking now is how to address > the temporary addresses that are used in operating systems (in some my > default, in some not by default)? Those addresses change over time > randomly, and maybe more often than a relay would find useful. > > Is there a flag or something that can make an application tell the > difference between a temporary IPv6 address and a static one, for example If temporary addresses are allocated from temporary address ranges, Tor should ignore them. (Or we can teach it to ignore them.) If they are allocated from permanent address ranges, then the operator needs to tell Tor which address to use. It's just like IPv4. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] IPv6 ORPort autodetection on relays (Was: Re: Running 2 relays with 0.4.0.2_alpha [err] descriptor at 0x8a0acdb0830 begins with unexpected string "".)
Hi, Cc'ing Linus, because he is also interested in IPv6. > On 28 Feb 2019, at 19:01, s7r wrote: > > However, shouldn't the line: > ORPort 9050 > > bind to all v4 and v6 available interfaces / IP addresses? If it does > not, we should fix it to do so. As in: > > ORPort 9050 - bind to all available v4 and v6 > ORPort 0.0.0.0:9050 - bind to all available from the v4 class > ORport [::]:9050 - bind to all available from the v6 class > ORPort :port - bind to specified address exactly Tor already binds to IPv4 and IPv6 by default. But it only autodetects IPv4 addresses. (Binding to IPv6 doesn't really do much, if you don't have an IPv6 address to advertise.) I'd love to make Tor autodetect IPv6 addresses. Here's what we need to do to make that happen: 1. make relays extend over IPv6 * these relays should declare a new protocol version "IPv6Relay=1" 2. make relays check their IPv6 ORPorts for reachability using an IPv6Relay * make relays connect to their own IPv6 ORPort (needs 1) * detect and track IPv4 and IPv6 ORPort reachability separately 3. make relays autodetect an IPv6 address (needs 2) Here's the parent ticket for this change: https://trac.torproject.org/projects/tor/ticket/24403 Our next step is to write a proposal for this change. (There is already some code in some of the tickets.) T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running 2 relays with 0.4.0.2_alpha [err] descriptor at 0x8a0acdb0830 begins with unexpected string "".
Hi, > On 28 Feb 2019, at 09:57, technon...@fea.st wrote: > > I run one relay and another tor instance for hidden services and socksport. > Haven't had a problem until 0.4.0.2_alpha. Ive had it crash twice so far. > Maybe my configs aren't sane? > > [err] descriptor at 0x8a0acdb0830 begins with unexpected string "". Is > another process running in our data directory? Exiting. Which instance do the errors occur on? > ORPort []:9050 This config line will probably cause a parse error. If this is meant to be an IPv6 ORPort, try: ORPort [::]:9050 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] 2 ip addresses at the same device, works except for the DirPort
Hi, On February 6, 2019 7:38:26 PM UTC, "Toralf Förster" wrote: >I ordered a 2nd ip address for my server and put them in the first >order in my network configuration. I'm not sure I understand what your network config is, and what you expected to happen. Try setting the Address option. Tor will guess your IPv4 address, and it doesn't always guess the one you want. >I do wonder, why this adapted torrcconfiguration: > > > >$> cat /etc/tor/torrc ># torrc at tor-relay ># >PIDFile /var/run/tor/tor.pid >DataDirectory /var/lib/tor/data > >Nickname zwiebeltoralf >OutboundBindAddress 5.9.158.75 >DirPort 80 >ORPort 443 >DirPort [2a01:4f8:190:514a::2]:80 NoAdvertise >ORPort [2a01:4f8:190:514a::2]:443 > >ControlPort 9051 > >Log warn file /tmp/warn.log >#Log notice file /tmp/notice.log >#Log info file /tmp/info.log > >ExitRelay 0 >IPv6Exit 0 > > > >works at the first glance (about 6,000 connection) but still give after >a while in the log: > > > >Feb 06 19:59:08.000 [notice] Tor 0.4.0.1-alpha opening log file. >Feb 06 20:19:26.000 [warn] Your server (:80) has not managed to >confirm that its DirPort is reachable. Relays do not publish >descriptors until their ORPort and DirPort are reachable. Please check >your firewalls, ports, address, /etc/hosts file, etc. > >(where is the new main ip address at my eth0 device) I'm not sure what you mean: is xx the wrong address? If you're still having trouble, please send us your latest config, and address and reachability check logs. Unredacted logs are best (relay info is public), but if you must redact, please give each address a different replacement string. Please also tell us your exact network config, and what you want Tor to do. T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] plans to require ContactInfo to be non-empty
Hi, On February 6, 2019 10:48:29 AM UTC, grarpamp wrote: ... > >And if nicknames go away (status on that proposal), >then contact is likely to absorb that function, including >the current always present nature of nickname. There is no proposal to remove Nicknames. The authorities don't vote for the Named flag any more, because relying on names to identify relays is fragile. I'm not sure if we have removed the special handling code for Named yet. T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Installing Tor As Windows Service And Updating Via Script (was RE: Having Trouble With Speed Of OBFS4 Bridge)
On January 30, 2019 12:01:02 AM UTC, Keifer Bly wrote: >Darn, I just restarted the relay because tor 0.3.5.7 came out today >before seeing this email. I have been playing with the Windows >Powershell regarding this and made some interesting discoveries. > >So, I found that the Windows Powershell equivalent to linux's "apt-get" >is "install-package -Name". And so, I tried running "install-package >-name tor" and got this error (see the attached screenshot). > >The error is that tor project is not in the list for Windows to install >packages from on Windows (it's not finding tor packages as a result), >as I discovered at the other attached image. > >However, according to my research at >https://docs.microsoft.com/en-us/powershell/module/packagemanagement/register-packagesource?view=powershell-6 > >Windows Powershell can register sources to install packages from via >Register-PackageSource -Name command listed. So Something along the >lines of > >PS C:\> Register-PackageSource -Name "tor" -Location "http://torurl; >-ProviderName "TorProject" may have interesting results possibly. What >is the tor packages download url so I may try this? Once this is >returned to me I will return to the list with my findings. I don't think Tor maintains a package source list in Windows PowerShell format. You might be able to create one yourself if you search Microsoft's website for the format reference. Here is our downloads page with our available downloads: https://www.torproject.org/download/download.html T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Having Trouble With Speed Of OBFS4 Bridge
On January 29, 2019 3:45:55 AM UTC, Keifer Bly wrote: >Thanks. I also wanted to ask, is there a way to upgrade tor using >Windows Powershell? The way I am doing that is downloading the tor >expert bundle when a new one is released and manually replacing both >tor.exe and obfs4.exe with the new versions. I have tor installed as a >Windows service via powershell, so is there a way to do this? I am >asking because the current tor expert bundle is tor 0.3.4.8 whereas I >believe 0.3.5.7 has been released. Thank you. Hmm, I thought someone answered this question already, but I can't find the answer in the list archives. 0.3.4.8 is still a supported version. You don't need to update. One simple way to keep Tor up to date on Windows is to use the Chocolatey package manager to install the tor package: https://chocolatey.org/packages/tor It has Tor 0.3.3.9, which is still a recommended version. You can script chocolately using the "choco" command. Otherwise, you can script powershell to download and install packages. I can't help you with the details, because I don't do a lot of work on Windows. But maybe someone else on the list can. If you work out how to do it, please write back to the list with the scripts you used. T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Having Trouble With Speed Of OBFS4 Bridge
On January 27, 2019 8:19:43 PM UTC, Keifer Bly wrote: >So, advertised bandwidth is based on how much bandwidth the clients are >currently using and not how fast it actually is? Yes. Here is the description of advertised bandwidth from the glossary: "Bandwidth The volume of traffic, both incoming and outgoing, that this bridge is willing to sustain, as configured by the operator and claimed to be observed from recent data transfers." https://metrics.torproject.org/glossary.html#advertised-bandwidth >I had another question as well, I guess I should update the ContactInfo >line to a not obfuscated email address so the bridge authority can >reach me easier We don't send out automated emails to relay or bridge operators. So obfuscated emails are fine. > how can I do this without restarting the relay? I have >tor expert bundle installed as a Windows service via powershell Don't worry, you can restart your bridge whenever you need to. Any clients using your bridge will switch to one of their other bridges. If you really don't want to restart your bridge, and you have time to look up the detailed steps: On unix-based operating systems, you can reload Tor's config by sending a SIGHUP. Windows doesn't have signals, but you can send a SIGHUP over the control port using stem or another Tor controller. You'll need to configure a control port first. Search the list archives, https://stem.torproject.org , or the internet for details. If you can't get it to work, write back to us with a link to the steps you tried, and links to a paste of your Tor logs and controller session. Or just restart the bridge. T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] diff-cache OOM
On January 27, 2019 1:07:12 PM UTC, notatorserver wrote: >I am running tor 4.0.1-alpha inside a docker container with a memory >limit (6GB). Tor runs out of memory and aborts or crashes periodically. Tor assumes that 64-bit machines have 8 GB of RAM, unless the relevant APIs return a lower value. How does docker implement memory limits? Does it modify the values returned by the Linux RAM APIs? >Usually I see an error message like this: >Could not mmap file "/var/lib/tor/data/diff-cache/1149": Out of memory >...(repeated some number of times) Please paste your log on https://paste.debian.net How many times are these messages repeated? Is the diff number the same, or different? How many files are in that directory? >followed by segfault > >Sometimes I see a message: >Out of memory on malloc(). Dying >followed by abort. > >Am I correct to assume the diff-cache is the issue here? Looking at the >files it seems they are all pretty small (~500K). Is some badly behaved >client requesting 12,000 of these diffs causing my relay to mmap them >all at once? How many times are these messages repeated? > or is it just expensive to generate and generating 30-60 >at once is enough to use all the memory? The diffs are generated once an hour, then cached for requests. Do the errors happen at generation time, or request time? >Are there any config options to reject expensive queries or otherwise >limit concurrency? Try MaxMemInQueues 4 GB If that doesn't work, try NumCPUs 2 and please let us know, because we'd like to fix these kinds of bugs. T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Having Trouble With Speed Of OBFS4 Bridge
Hi, Tor isn't like bittorrent or other bull download protocols. It's mainly used for quick web page accesses. So it only uses the data it needs. Users get their web pages faster if Tor bridges and relays have spare capacity. So spare capacity is really good for users. Bridge and relay operators shouldn't expect Tor to use all their bandwidth. On January 27, 2019 7:23:30 AM UTC, Keifer Bly wrote: >Hi, based on the heartbeat log, about 2 clients seem to use the bridge >every six hours. The log says. > >"In the last 6 hours I have seen 2 unique clients. Tor's uptime is 12 >hours, with 0 circuits open." 2 clients probably won't use all your available bandwidth, unless they are always downloading big files. But you are still helping them get to the internet. And if they ever do need lots of bandwidth, your bridge will give it to them. >> How are you measuring the speed? > >On my bridge listing at >https://metrics.torproject.org/rs.html#details/148BD64BED9F2C27637D986DE032ECF14E5B9E9A, >it says "Advertised Bandwidth 59 kb/s" Your bridge isn't being used very much. That's ok. >As requested, the torrc has been posted with the port numbers removed >at >paste.debian.net/1062702 > >Another strange thing is that the ContactInfo string is not showing up >for some reason, even though when I started tor it said "ContactInfo >listed more than once, all but the last entry will be ignored" or >something similar. You have 3 ContactInfo lines. You can delete 2 of them. Bridge contact info is not shown on relay search for privacy reasons. The IP addresses and ports are also hidden. T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Shutdown of fallback directory mirror armbrust: E781F4EC69671B3F1864AE2753E0890351506329
On January 26, 2019 10:52:56 AM UTC, Michael Armbruster wrote: >After a long time maintaining an exit relay that was also chosen to be >a >fallback directory mirror, I decided that the time has come to shut the >relay down. > >It has only financial reasons (being a cheap server, but still using >money out of my own pocket) and I will stay a happy user of Tor and, of >course, will provide a new relay as soon as my financial situation gets >better. Thank you for running a relay, and thank you for letting us know. >How should we proceed and how long should I still let the fallback >mirror run in order to gracefully migrate the fallback status away from >my server? I do not want to disappear immediately without any further >notice, so I wanted to ask how to further proceed. You can shut down the relay as soon as you need to. We designed Tor clients so they work even when most of the fallbacks are down. We regularly monitor the list of fallbacks, and start a rebuild when 25% go down. T Hi Michael, -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Having Trouble With Speed Of OBFS4 Bridge
On January 27, 2019 3:04:37 AM UTC, Keifer Bly wrote: >So my OBFS4 bridge at >https://metrics.torproject.org/rs.html#details/148BD64BED9F2C27637D986DE032E >CF14E5B9E9A seems to be having some speed issues, only reaching about >40-50 >kb/s of speed. This is strange, as it should be much faster than this. Why do you expect your bridge bandwidth to be fully used? How many clients are using your bridge? Please paste a heartbeat log line into your reply. How are you measuring the speed? What have you tried to do to change the speed? What happened? >Where I living, am probably nowhere near the bridge authorities for >one. There is one bridge authority. It does not measure bandwidth. >I am running an obfuscated bridge (which as this requires an additional >process to be running alongside the tor process, could this be a part >of >it?) Please remove IP addresses and ports, then paste your torrc into https://paste.debian.net . >I am running off of the only internet provider available in my area >(Charter >/ Spectrum) which is an isp that uses cable structure so maybe they >have >some kind of limitation in place? Many ISPs have limits. Many of them don't tell you about them. >My router is a Netgear Orbi router which should be able to handle up to >60,000 connections at once so there should be no issue there. Many home routers have limits. Many of them don't tell you about them. I can't find the number of supported connections in Netgear's documentation: https://www.netgear.com/Orbi/CBR40.aspx T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bandwidth limiting at relay or network?
> On 15 Jan 2019, at 13:09, Isaac Grover, Aileron I.T. > wrote: > > I haven’t ever taken the time to configure bandwidth limits in torrc, always > preferring to manage it at the firewall as we have other bandwidth limits set > there as well. However, I’m curious - what do other relay operators prefer? How does your network handle packets that are over the limit? Tor delays sending cells that would exceed its bandwidth limits. This increases in-process latency, but does not require network retransmits. But it also does not change the relevant TCP bandwidth delay product. Most networks drop packets that are over their bandwidth limits. This increases network retransmits, and triggers a bunch of TCP algorithms that slow down the connection. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] community team highlights: Relay Advocacy
Hi, > On 14 Jan 2019, at 11:37, Vasilis wrote: > > Signed PGP part > teor: >> Colin also asked relay operators to opt-in as fallback directory mirrors >> (in the last half of 2018). In December, he helped rebuild the fallback >> directory mirror list. > > Thank you for working on this. > > The fallback directory mirrors are being checked daily by the OONI probe TCP > connect test that runs by default from many probes around the world. It > currently tests the TCP connectivity (successful connection: true/false) of > the > directory authorities and bridges. > > This list lives on the ooni-resources repository [1] it will be really neat if > one can drop a notification or open a ticket so that this list gets updated. We rebuilt the list at end of 2018, then I was distracted by the holidays. I just did the tor-relays announcement, and emailed metrics for Relay Search: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors#ATypicalRelease Telling OONI is on our list, and I made a ticket for next time: https://trac.torproject.org/projects/tor/ticket/29093 It would be slightly easier for us to cc OONI on the tor-relays email. Is there a mailing list we could use? We don't mind opening GitHub tickets, if that's easier for you. 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] New Fallbacks from December 2018
Dear Relay Operators, Thanks to everyone who opted-in their relays as fallback directory mirrors. We rebuilt the list of fallbacks in December 2018. [0] The new list was released in Tor 0.3.5.6-rc, and it was backported to all supported Tor releases. [1] The FallbackDir flags on Consensus Health [2] have been updated. The flags on Relay Search [3] might take a few days to update. Don't worry if your relay missed out this time. It's still helping Tor users. And we will rebuild the fallback list again in 6-12 months time. We are tracking fallback changes in this ticket [4]. To opt-in your relays, add a comment to the ticket [4], or reply to this thread. If you have multiple relays, you can opt-in as many as you like. (We picked up to 7 per operator this time, and we may pick more next time.) T [0]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc https://trac.torproject.org/projects/tor/ticket/24801 [1]: 0.2.9, 0.3.3, 0.3.4, 0.3.5, and 0.4.0. See https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current [2]: https://consensus-health.torproject.org/graphs.html [3]: For example, this relay is a new fallback: https://metrics.torproject.org/rs.html#details/0C039F35C2E40DCB71CD8A07E97C7FD7787D42D6 [4]: https://trac.torproject.org/projects/tor/ticket/28794 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] slow relays
> On 14 Jan 2019, at 09:32, ronqtorrel...@risley.net wrote: > > Thanks. I'm curious what, in the consensus, suggests that I'm too far from > the Authority Servers? I don't know how to read that page; I can't even > figure out what units they're using to report bandwidth. It's a unitless amount due to scaling, but it starts as kilobytes per second. > One of the relays is one hop away (via a lightly-loaded terabit switch) from > the (formerly known as) Level3 tier 1 network, so should have excellent > peering worldwide unless CenturyLink has degraded it since their acquisition > last year. The other sits two or three hops (depending, apparently, on the > phase of the moon) from the tier 1 network run by Telia. So, at least with my > limited understanding of internet topography, they should both be > topologically close to most hosts worldwide. Your relays are on the south and west coasts of the US, which means they're further away from the Tor bandwidth authorities in northern North America and north western Europe. Tor load-balances for client latency and bandwidth capacity. Relays with higher latency or lower bandwidth are only partly used. But this reserve capacity helps during peak times. Tor also load-balances according to relay position in the circuit. Tor guards currently have about 200 Gbps capacity, and clients are currently using 75 Gbps, or 37%: https://metrics.torproject.org/bandwidth-flags.html So your guards have slightly lower than average utilisation: 1 Mbps / 5.1 Mbps = 20% 1.2 Mbps / 7.4 Mbps = 16% I wouldn't worry about it too much. > On 14 Jan 2019, at 09:49, niftybunny wrote: > > Hard to tell. A few years ago I had an ISP with a fat shiny direct line to > the DE-CIX. So in theory everything was wonderful, it was not. Rule of thumb: > Get as near as possible to the auth servers, same data center would be > perfect :) > > Having all relays in one data center would make the state actors very very > happy. I am still a fan of more auth servers all over the world. But who am I > to tell what to do. We're focused on migrating to a stable bandwidth measurement system for the next year or so. A failed bandwidth measurement system is even worse: then relays can just claim to be as big as they want to be. After that, we'll look at geographical dispersion. But if we spread the relay load out too far, client performance will suffer. (And users wont see reliable, consistent performance, which is even worse.) > If you really want to know how much Tor will give you, run it as an Exit. Tor > will love you and gives you every bit of traffic it has. Please don’t do this > from home or if you are not sure what you are doing etc . (insert big fat > disclaimer) Yes, Tor needs more exits, their utilisation is often close to 75%. 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 drops continuously 28h after getting guard flag
Hi, > On 12 Jan 2019, at 01:44, Ilka Schulz wrote: > > Is there actually any detailed documentation on how consensus weight is > calculated? Consensus weight is calculated using a relay's self-reported peak bandwidth usage, and measurements from ~6 bandwidth authorities around the world. The process is slightly different on some of the bandwidth authorities, because we are migrating to a newer system. There is detailed documentation here: 5/6 bandwidth authorities run torflow: https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.spec.txt#n298 1/6 bandwidth authorities run sbws: https://github.com/juga0/sbws/blob/master/docs/source/specification.rst#simple-result-processing https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n656 > Also, my bandwidth (as well as my cpu, etc.) is only used to a fraction of > its capacity, even though my relay is three weeks old now. The > RelayBandwidthRate option does not limit here... Tor is a connection-oriented, reliable-transport, low-latency network, so it will never use your full bandwidth capacity. If it did, latency would suffer. Here are some initial steps for troubleshooting: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow 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] community team highlights: Relay Advocacy
> On 12 Jan 2019, at 21:54, nusenu wrote: > > Forwarded Message > Subject: [tor-project] community team highlights -- November and December > Date: Wed, 09 Jan 2019 18:15:00 + > From: Alison Macrina > To: tor-proj...@lists.torproject.org > > Relay Advocacy > == > Colin resumed running once a month IRC relay operator meetings. He also > started planning the FOSDEM relay operator meet-up. Steph and Colin are > working on updating the relay flyers. Colin continues to work on > communicating with OVH regarding relays without contactinfo added to the > network. Finally, Colin has been working with Bill from EFF on a Tor > relay challenge. Colin also asked relay operators to opt-in as fallback directory mirrors (in the last half of 2018). In December, he helped rebuild the fallback directory mirror list. 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] Metrics show Relay donw
> On 26 Dec 2018, at 07:11, Darek Kramin wrote: > > Looks problem is solved. Online now > > On Tue, Dec 25, 2018, 21:13 Darek Kramin hi, > > I did started 2 days ago tor relay. when I set daily accounting was ok and > now with weekly set of GB relay is listed down. It is a glitch or my > misconfiguration. > Relay is named dasBoot at IP 46.175.238.8 Accounting causes your relay to hibernate at a random time each interval. If you don't want that to happen: 1. set the accounting limit very high 2. wait one interval for Tor to get good bandwidth estimates 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] My Fallback Directory Mirror is going down
Hi, > On 31 Dec 2018, at 20:52, Viktor Nikolov wrote: > > Hi! > > My Fallback Directory Mirror B6904ADD4C0D10CDA7179E051962350A69A63243 at > 81.2.209.10 is going down permanently because my provider decommissioned the > data center where I had my HW. :-( > > I will likely host my HW at a new provider soon, but at a new IP address. Thanks for letting us know. We're tracking this change here: https://trac.torproject.org/projects/tor/ticket/28794#comment:6 If you'd like your new IP address and relay fingerprint added to the list, just let us know. 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] consensus-health.html and fallback dirs
> On 16 Dec 2018, at 17:01, starlight.201...@binnacle.cx wrote: > > The cause is > > https://gitweb.torproject.org/tor.git/commit/?id=78e177d622f5f3b24023d04458f5948275a44766 > > https://trac.torproject.org/projects/tor/ticket/24803 > > Would be appreciated if the Tor project published outputs > of UpdateFallbackDirs.py job runs used when rebuilding > the list. Thus operators who have expended effort to keep > their relays eligible will know why when dropped. We usually attach the logs to the relevant ticket. This time, I saved the logs, but accidentally overwrote them. And I didn't ask Colin to attach his logs. We'll try to do better next time: I've added a note on the ticket for 2019. > On 17 Dec 2018, at 10:45, starlight.201...@binnacle.cx wrote: > > Ran the script: output is attached to this message for anyone > interested. Live-network test results will vary by time and by > the location of tester. Attached run was made over Tor > itself using 'torsocks'. Thanks! > I was bit by having disabled the unencrypted DIR port for > one day recently as an experiment. We rely on onionoo's last changed field: https://metrics.torproject.org/onionoo.html#details_relay_last_changed_address_or_port Changing or removing a published address or port resets the last changed date. Adding an IPv6 address does not reset the last changed date. I realise that it's disappointing for relay operators to lose a flag. But we're not too worried if a fallback drops out of the list for a release or two: changing the fallback list regularly makes it harder to block. And that's good for users. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Who is permanently checking my bridge relay?
Hi, > On 4 Dec 2018, at 21:27, tscha...@posteo.de wrote: > > Hi all! > > I wonder who is permanently connecting/checking(?) my Tor bridge relay. > The ip is 66.111.2.129 and the period of the connects are 21 min 21 sec, > e.g.: > > Dec 4 10:32:00 SRC=66.111.2.129 > Dec 4 10:53:21 SRC=66.111.2.129 > Dec 4 11:14:43 SRC=66.111.2.129 > Dec 4 11:36:04 SRC=66.111.2.129 > Dec 4 11:57:26 SRC=66.111.2.129 > Dec 4 12:18:52 SRC=66.111.2.129 > > https://metrics.torproject.org/rs.html#search/66.111.2.129 gives no match. > > Any more experiences with other bridges? A few years ago, I opened a ticket to randomise authority reachability testing: https://trac.torproject.org/projects/tor/ticket/13928 But we triaged it out with the comment: My rationale for redlining it during triage was that the best place to do unpredictable-order testing is probably in a successor to torflow. (sbws is a successor to torflow, and it does randomise the testing order.) Are there any good reasons to randomise the order of authority tests? One good reason is that it breaks patterns in the authority checks, so relays really do need to be up all the time to be listed as reachable. 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] IP addresses on the list
> On 5 Dec 2018, at 00:20, Charly Ghislain wrote: > > I am also questioning myself whether addresses should be printed in log files > altogether. Maybe even with the unsafe flag on - at least for released > versions. If one wants to know which ip is connecting to her bridge, she can > use whatever network capture software already existing. Tor has a SafeLogging option that's on by default. But deciding which information to redact is a tradeoff. If users need help, we usually need to know which bridges or relays they are connecting to. If there's information in the logs that you think we should put behind SafeLogging, let us know here, or log a ticket on https://trac.torproject.org under Core Tor/Tor. 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 warning - what is mean ?
Hi,
> On 29 Nov 2018, at 07:29, dluga...@protonmail.com wrote:
>
> today I have found this. If You need more informations please let me know.
>
>
> 16:48:56 [WARN] {BUG} Bug: 0x1076f25 <_start+0xa5> at /usr/local/bin/tor (on
> Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x1077119 at /usr/local/bin/tor (on
> Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x107727c at /usr/local/bin/tor
> (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x107bfe9 at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x107a221 at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x801b4de1f at
> /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x801b51cd2
> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x107fc3e at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x107e55b at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x11caf6a at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: 0x11aff98 at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} Bug: Non-fatal assertion
> !(connection_is_reading(conn)) failed in conn_close_if_marked at
> src/or/main.c:1047. Stack trace: (on Tor 0.3.4.9
> │ 4ac3ccf2863b86e7)
> │ 16:48:56 [WARN] {BUG} tor_bug_occurred_: Bug: src/or/main.c:1047:
> conn_close_if_marked: Non-fatal assertion !(connection_is_reading(conn))
> failed. (on Tor 0.3.4.9
> │ 4ac3ccf2863b86e7)
>
>> ...
>>
>>> I extracted that from Nyx.
>>> FreeBSD 11.1
>>
>> We recently fixed a FreeBSD bug with a similar stacktrace.
>> We're testing the fix in 0.3.5 before we backport it.
>>
>> https://trac.torproject.org/projects/tor/ticket/27750
It looks like bug #27750.
It is safe to ignore these warnings.
The bug should be fixed in the next 0.3.4 release, or you can use 0.3.3.10 or
0.3.5.5-alpha.
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] Relay with VPN
Hi, Just one clarification: > On 28 Nov 2018, at 22:23, s7r wrote: > > You say you want to run a middle relay, why do you want to run it behind > a VPN in this case? Middle relays get no abuse complaints or anything as > they can not be used as exit points. Occasionally, clients will ask middle relays to connect to another server as if it was a relay. We don't know why this happens: it could be a custom Tor client bug. It's a pretty useless attack, because it's slow, and it provides very little information about the server. It's very unlikely you will get an abuse notice from activity like this. 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 There A Windows CMD Command To Update Tor.exe?
Hi, > On 28 Nov 2018, at 14:10, Keifer Bly wrote: > > Hello, so today when I started my bridge relay, tor popped up with a warning > saying this > > WARNING: According to directory authorities, this version of tor [0.3.4.8] is > out of date or no longer recommended. > > I am running the obfs4 bridge via tor expert bundle, and was told previously > that that is updated when the tor browser is updated, but am wondering, > seeing as there is a way to do this on MacOS and Linux, is there a way to > update the tor process (I guess I would also need to update the obfs4 exe > process) via the Windows command line? You could use chocolatey, but they only have Tor 0.3.3.9: https://chocolatey.org/packages/tor 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 warning - what is mean ?
Hi,
Thanks for reporting this bug.
> On 28 Nov 2018, at 04:10, dluga...@protonmail.com wrote:
>
> does any could tell me what is mean that Warn ?
>
> 16:32:33 [WARN] {BUG} Bug: 0x1076f25 <_start+0xa5> at /usr/local/bin/tor (on
> Tor 0.3.4.9 4ec3ccf2863b86e7)
> │ 16:32:33 [WARN] {BUG} Bug: 0x1077119 at /usr/local/bin/tor (on
> Tor 0.3.4.9 4ec3ccf2863b86e7)
> │ 16:32:33 [WARN] {BUG} Bug: 0x107727c at /usr/local/bin/tor
> (on Tor 0.3.4.9 4ec3ccf2863b86e7)
> │ 16:32:33 [WARN] {BUG} Bug: 0x107bfe9 at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ec3ccf2863b86e7)
> │ 16:32:33 [WARN] {BUG} Bug: 0x107a221 at
> /usr/local/bin/tor (on Tor 0.3.4.9 4ec3ccf2863b86e7)
> ─┘ 16:32:33 [WARN] {BUG} Bug: 0x801b4de1f at
> /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.4.9 4ec3ccf2863b86e7)
Tor bugs come with a log message that tells us the assertion that failed.
Is there any more log output around this bug?
> I extracted that from Nyx.
> FreeBSD 11.1
We recently fixed a FreeBSD bug with a similar stacktrace.
We're testing the fix in 0.3.5 before we backport it.
https://trac.torproject.org/projects/tor/ticket/27750
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] How To Update The Tor Expert Bundle To Tor 0.3.4.9
Hi, > On 24 Nov 2018, at 05:46, Keifer Bly wrote: > > Hello, So I am running an obfscated bridge on Windows 10 via the tor expert > bundle, which, even when I tried downloading it today, is running tor > 0.3.4.8. I was unaware that tor 0.3.4.9 had been released due to this. Do to > being away from where the relay is running, I will not be able to update it > for about 4 days, but how could I update the tor expert bundle to tor > 0,3,4,9? How could I update the tor expert bundle to the newest tor in > general? The Tor Expert Bundle is build when Tor Browser is built. So sometimes the release is delayed a few weeks after the Tor release. When the update is available, you should update to get this fix: o Major bugfixes (relay, backport from 0.3.5.3-alpha): - When our write bandwidth limit is exhausted, stop writing on the connection. Previously, we had a typo in the code that would make us stop reading instead, leading to relay connections being stuck indefinitely and consuming kernel RAM. Fixes bug 28089; bugfix on 0.3.4.1-alpha. 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] notices.log: "[warn] Rejecting DNS request from disallowed IP"
> On 23 Nov 2018, at 21:20, petra...@protonmail.ch wrote: > > Hi, > on a small server I did try to force local DNS requests to the local Tor via > iptables/ferm (Nat, Output-Chain, protocol udp dport domain REDIRECT to-ports > 5300). Torrc has the following included: 'DNSPort 127.0.0.1:5300'. > > Unfortunately, it doesn't work as expected, but I get a warning in Tor's > notices.log stating "[warn] Rejecting DNS request from disallowed IP" for > each DNS request and even after hours of searching around and trying > different configs I could't find the root cause yet. This warning comes from the socks policy check: https://github.com/torproject/tor/blob/a1b0283040723474377a5746dbd01782a9b7eaa7/src/feature/client/dnsserv.c#L84 > Question: what does "disallowed IP" really mean, i.e. what IPs are allowed by > Tor and which ones are not? Any ideas and hints on how to investigate further > are highly welcome! :-) You're right, the documentation and logging isn't great here. I opened a ticket to fix it: https://trac.torproject.org/projects/tor/ticket/28597#comment:2 Have you set the SocksPolicy option? SocksPolicy policy,policy,… Set an entrance policy for this server, to limit who can connect to the SocksPort and DNSPort ports. The policies have the same form as exit policies below, except that port specifiers are ignored. Any address not matched by some entry in the policy is accepted. https://www.torproject.org/docs/tor-manual.html.en 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] Bridge Relay Internet Speed Much Slower Than Actual Internet Speed
> On 16 Nov 2018, at 06:22, Keifer Bly wrote: > > But is it normal for the fast flag to be off and on? Thank you. Yes. Change is normal. Embrace change. Do not worry. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Relay Internet Speed Much Slower Than Actual Internet Speed
Hi, >> On 14 Nov 2018, at 07:11, entensai...@use.startmail.com wrote: >> >> Hello List, my bridge relay at >> https://metrics.torproject.org/rs.html#details/148BD64BED9F2C27637D986DE032ECF14E5B9E9A >> >> Is reporting the relay speed is between 50 kb/s and 60 kb/s, when the speed >> of the internet connection it is running off of is actually much faster than >> this, generally about 50mbps (the relay is running on a home internet >> connection, where the isp is Charter Communications / Spectrum). As a >> result, I have the “fast” flag on/off randomly. >> >> I do not want my bridge to suck up a huge amount of my internet speed, but >> why would the tor software report relay speed that is so much slower than >> the speed of the internet connection it runs off of? >> > The advertised bandwidth is not the bandwidth of your > connection but the bandwidth observed. > Your relay probably hasn't been used as a relay so far. > When it's being used the advertised bandwidth will rise. > Are bridges chosen based on their advertised bandwidth? Yes, but it's clamped to a narrow range, so it doesn't have much impact on which bridge a client chooses. > It's been up nonstop for 7-8 days, so I would say it's definitely been used. > It jumped down to 10kb/s for a day then back up to 55kb/s. Any thoughts on > why this might happen are appreciated, thank you. BridgeDB allocates bridges to different pools. Some pools are not used by many users, and there is a reserve pool. Even if your bridge is sent to users, those users might not be online all the time. Please don't worry about the usage of your bridge or relay. It is very normal for usage to vary. T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Configuring relay
On 12 Nov 2018, at 08:40, DeMarcus Sullivan wrote: > > I am running the latest version on Tor 8.0.3 on my Windows desktop. I would > like to run a non-exit relay 24/7 and I'm having trouble finding the > step-by-step process to do so. Before I could just copy amd paste the torrc > configuration text in the torrc file. It seems that has changed because now > Tor won't run properly when I change the torrc file. Please send us Tor's log output. You will probably need to send Tor's log output to a file, then paste that file to a pastebin service like https://paste.debian.net If you try to see tor's logs in a command shell, you get a blank line, because of this bug: https://trac.torproject.org/projects/tor/ticket/28344 T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] # of connections of a exit relay dropped down by about 90% exactly after 1 month after installation time
> On 9 Nov 2018, at 20:18, nusenu wrote: > > teor: >> 1. If your exit's DNS fails, it will reject all exit requests in its >> descriptor. > > are you saying that > https://trac.torproject.org/projects/tor/ticket/21989 > is already implemented and released in an alpha version? This ticket is not yet implemented. But some kinds of DNS failures will cause Tor exits to reject all exit traffic, see ServerDNSTestAddresses and ServerDNSDetectHijacking in: https://www.torproject.org/docs/tor-manual.html.en > the affected relays show 0% failure rate at Arthur's DNS check page > https://arthuredelstein.net/exits/ I am not sure if this DNS check checks for hijacking. But it looks like the issue was an overlong or overbroad exit policy. 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] # of connections of a exit relay dropped down by about 90% exactly after 1 month after installation time
Hi, There are two likely possibilities here: > On 9 Nov 2018, at 06:17, Toralf Förster wrote: > > Signed PGP part > On 11/8/18 9:12 PM, nusenu wrote: >>> 2018-11-06 21:00 UTC >> are you sure this is UTC? >> > ick, it was 21:00 CET (the dropdown may even started at 20:00 CET), but > obvious it was an hour later 1. If your exit's DNS fails, it will reject all exit requests in its descriptor. >> I did not look at the underlying descriptor data but onionoo data suggests >> that >> an exit policy change occurred which could have caused the change in >> connection counts. > > indeed, I added networks to the reject lists at that time, but only 2 */8 > class A nets - but will check ofc. 2. If you reject enough IP addresses in your exit policy: If your exit blocks enough /8 networks, then its exit policy summary becomes reject all. If the exit policy summary is too long, then it is truncated to a list of accept ports. (That doesn't seem to have happened here.) Separately, if your exit doesn't exit to at least one /8 on ports 80 and 443, it loses the Exit flag: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2531 >> I'm still surprised that you do not have more connections since >> even non-exits have more than 1k concurrent connections unless you are >> talking >> about specific connections only? > > I can try to check with "ExitRelay 0" - currently I downgraded to 0.3.4.9 to > check that version. 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] Running an exit node from home
> On 31 Oct 2018, at 22:47, Ralph Seichter wrote: > > * teor: > >> If a client doesn't have a circuit to an exit that supports the port >> it wants, it randomly chooses an exit that allows that port. > > Sure, but is the distinction of what is considered "an exit" reflected > in the exit flag? I don't understand what you mean by "an exit". Do you mean "the Exit flag" or "an exit policy that allows some ports"? >> The Exit flag means "useful for general exiting". Clients build preemptive >> circuits to Exit-flagged relays. When a client has an available circuit for >> exiting, it will use that circuit. >> >> The Exit policy means "allows exiting to these ports". > And is it truly random, or does the consensus weight > factor into it, the latter being what I thought to be the case? Clients filter Exits by exit policy or Exit flag, then choose an exit randomly weighted by consensus weight. Almost everything in Tor is chosen randomly by consensus weight. (HSDirs are an exception.) > My point is that a Tor node not flagged as an exit is pretty much > useless for that role, and removing all exit rules is appropriate in my > opinion. I agree, but each operator can make their own choice. 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] Running an exit node from home
> On 31 Oct 2018, at 16:41, DaKnOb wrote: > > You can exit to one of (80,443) to at least a /8 to receive it.. So if you > add an allow 443 on a not so populated /8, it will get the exit flag.. :-) Careful: * this isn't a great experience for users who use your exit, and * getting the Exit flag changes how your relay's bandwidth is measured 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] Running an exit node from home
> On 31 Oct 2018, at 01:53, Ralph Seichter wrote: > > * Isaac Grover: > >> You are correct in that I won't maintain the exit flag without ports >> 80 and 443 open, *and* I lose my eligibility for a free t-shirt, *but* >> I am not likely to attract attention at my home either. =) > > No exit flag means your relay will not be used as an exit, just as a > regular relay. You can therefore get rid of all exit rules because they > won't make any difference. That's not quite true. The Exit flag means "useful for general exiting". Clients build preemptive circuits to Exit-flagged relays. When a client has an available circuit for exiting, it will use that circuit. The Exit policy means "allows exiting to these ports". If a client doesn't have a circuit to an exit that supports the port it wants, it randomly chooses an exit that allows that port. So you may see a small amount of traffic over those ports. 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 log message: [warn] Unparseable microdescriptor
Hi, Thanks for reporting this bug. > On 30 Oct 2018, at 04:18, Felix wrote: > > Are the two warnings below of the same type for this issue? Not really: they're corrupt on disk, rather than from the network. > Am 29.10.2018 um 07:03 schrieb teor: >> >> >>> On 24 Oct 2018, at 07:38, Toralf Förster wrote: >>> >>> Get this at my exit relay since yesterday: >>> >>> # head /tmp/warn.log >>> Oct 23 23:30:17.000 [notice] Tor 0.3.5.3-alpha opening new log file. >>> Oct 23 23:30:33.000 [warn] parse error: internal NUL character. >>> Oct 23 23:30:33.000 [warn] Unparseable microdescriptor >>> Oct 23 23:30:33.000 [warn] parse error: internal NUL character. >>> Oct 23 23:30:33.000 [warn] Unparseable microdescriptor >>> >>> even with log level "debug" there seems to be no more information. >> >> ... > > Non-exit > Oct 28 23:48:32.587 [notice] Tor 0.3.5.3-alpha running on FreeBSD with > Libevent 2.1.8-stable, OpenSSL LibreSSL 2.7.4, Zlib 1.2.11, Liblzma > 5.2.3, and Libzstd 1.3.5. > ... > Oct 28 23:48:33.000 [notice] Bootstrapped 0%: Starting > Oct 28 23:48:34.000 [warn] couldn't find start of hashed material > "network-status-version" > Oct 28 23:48:34.000 [warn] Unable to compute digest of network-status > Oct 28 23:48:34.000 [warn] Unable to parse networkstatus consensus > Oct 28 23:48:34.000 [warn] Couldn't load consensus microdesc > networkstatus from cache This looks like file corruption, but we'd still like to see the corrupt file, because it might be tor's fault. > Oct 28 23:48:34.000 [warn] parse error: Malformed object: missing object > end line > Oct 28 23:48:34.000 [warn] Unparseable microdescriptor This is probably also file corruption: tor won't download microdescs until it has a list of microdescs from a valid consensus. > Bridge: > Oct 28 14:35:17.667 [notice] Tor 0.3.3.9 (git-45028085ea188baf) running > on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.7.4, Zlib > 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.5. > ... > Oct 28 14:35:53.000 [notice] Bootstrapped 0%: Starting > Oct 28 14:35:55.000 [warn] parse error: Annotations mixed with keywords > Oct 28 14:35:55.000 [warn] Unparseable microdescriptor Given the timing, this is probably also file corruption. Please post any corrupt directory files that you have to: https://trac.torproject.org/projects/tor/ticket/28241 It would also be useful to have the logs from when tor last shut down. (Was it a clean shutdown?) 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 log message: [warn] Unparseable microdescriptor
Hi Toralf, Thanks for reporting this issue. > On 24 Oct 2018, at 07:38, Toralf Förster wrote: > > Get this at my exit relay since yesterday: > > # head /tmp/warn.log > Oct 23 23:30:17.000 [notice] Tor 0.3.5.3-alpha opening new log file. > Oct 23 23:30:33.000 [warn] parse error: internal NUL character. > Oct 23 23:30:33.000 [warn] Unparseable microdescriptor > Oct 23 23:30:33.000 [warn] parse error: internal NUL character. > Oct 23 23:30:33.000 [warn] Unparseable microdescriptor > > even with log level "debug" there seems to be no more information. You should see an info-level message that starts: "Unable to parse descriptor of type" Can you send any messages like this to the list? If those messages contain a filename, can you please send us a pastebin link to the contents of that file? (If the messages just contain a hash, look for a file with a name that contains that hash in unparseable-descs in your data directory.) I opened a ticket for this bug: https://trac.torproject.org/projects/tor/ticket/28223 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
