tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

Multicore, bandwidth, relays, capacity, location
by grarpamp 13 Aug '15

13 Aug '15

On Wed, Aug 12, 2015 at 9:16 AM, Thomas White <thomaswhite(a)riseup.net> wrote: > For relays, being able to make more use of available bandwidth would > vastly increase the network speed, furthermore make home clients see > an improvement in their daily Tor usage. It also benefits hidden > service people as they can then run their Tor processes on more than > one core and thus handle higher volumes of traffic. Tor appears maybe operating at 50% of bandwidth capacity... https://metrics.torproject.org/bandwidth-flags.html https://metrics.torproject.org/bandwidth.html https://metrics.torproject.org/bwhist-flags.html If that's true, more bandwidth won't have any end user affect. So for the moment it might be worthwhile to study reducing node based latency by ensuring relay CPU's have similar free capacity available for circuit negotiation, interrupt processing, and other tor functions. And to consider not dropping more bandwidth weight into already saturated jurisdictions, but dropping some into the Southern Arc and Eastern Zones in an effort to avoid Orion's Belt... https://metrics.torproject.org/uncharted-data-flow.html [Yes I broke the thread because "no subject" and gmail are even lamer than I].

2 1

IPv6 vs IPv4 exit policies
by spriver 12 Aug '15

12 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I just activated IPv6 support for my two exit relays today, but I do not unterstand/misconfigured the exit policies. I just want to open certain ports at IPv4 (the common known reduced exit policy) and open all Ports at IPv6 except 25. How do I configure such a thing? Current sample config is: [snip] IPv6Exit 1 ExitPolicy accept6 *:* ExitPolicy reject6 *:25 [full reduced exitpolicies snipped out] ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* But at Globe only this is visible: https://globe.torproject.org/#/relay/F5B1FC9038A5A65FF16D6729AAB2AEDD67F D2F2A https://globe.torproject.org/#/relay/D9D7A9C203C99945D0DCBD545A20C0CB936 7C742 Can someone help me out there? Cheers! spriver -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVyNfsAAoJEMkUf8VoejgPiEEP/jS0fkncI8EWdnNm6mWvOB2Z GybS2ZpzKMYzXTx277gp5AXsySBYsMjVDpxKLsWnfhejbKiv5SxgOYipnfROLoyd uTiqP+Ha+SB83DLM9/x9/OWOImT5qdEhKHVZVrW5UeQQJ9kZPO2R7eQ5w2aQfpVd wJ5nv8iSOuL79LPDVidNcAbFrqZ07R1DW/XUMXdlgdWjNd3ToJEBxussIQFMkQLH l6mQf8lF44Hau+udwiOvmKW6xjkMMPcg16jd/hHmimcQ1pgYV0sVS3XKxJifjKKQ VLIGa1oR1rV6rJEpE+F+6f+8HGJsoilda+eDMdgLzkD0Mi+/kHNbKEokyhAEqmxd fTyY5tt10ypXprYr75F6KEvBEP9h0qHY1NRt38YbLW2J4UCGDcW9ZB3xggFCa2iz 14twdT7qnyu8QuFUzox4DaxEyzeTeZXkKpjHsNABAPlGgenDhDkNldeuQnv4n3xc mBGhoobtDKRsi9aKg+9n1qgePOk7kJVUzEyi1Vwk8RdXwu8AyucejVoC7m7cgakW bFWGyNumezGlY2jMz+ARAEDJfG0LrgpEalJ06qZovUibLBCcOludI0Xdp7Y04vH0 PnWotybn7YZjOa69oJ7HGxiAHEoNgT4SeRM/NIvVWTOdgLPbE1Nr2o1drYpmMyjR aoSklTseBiKF+b1bex1L =Bo5q -----END PGP SIGNATURE-----

3 2

Re: [tor-relays] Guard flag flapping
by torrry＠Safe-mail.net 10 Aug '15

10 Aug '15

> So we now have the bandwidth, IP, and dirport of the fastest exits. With this list in hand, I just needed to form a proper URL, wget each one, and grep out the transfer speed: > > http://37.130.227.133:80/tor/server/all 1.17 MB/s > http://176.126.252.11:443/tor/server/all 4.54 MB/s > http://176.126.252.12:21/tor/server/all 666 KB/s > http://77.247.181.164:80/tor/server/all 111 KB/s > http://77.247.181.166:80/tor/server/all 330 KB/s > http://195.154.56.44:80/tor/server/all 3.65 MB/s > http://77.109.141.138:80/tor/server/all 2.20 MB/s > http://96.44.189.100:80/tor/server/all 13.4 MB/s > http://197.231.221.211:1080/tor/server/all 347 KB/s > http://89.234.157.254:80/tor/server/all 295 KB/s > > I'm not seeing anything immediately, although I need to run it on a larger set. There's no smoking gun so far though. Some of the speeds are a bit slow, but nothing low enough to explain the extremely low measured bandwidth these relays are getting. The current BW auth measurement results are around 1.0MBit/s for greendream848. I had a couple of measurements in the 300-500KBit/s range. So, if the auths heavily weight towards low individual measurements, things might make sense. Maybe one of the BW auth guys can comment on how the total measurement result is cooked up!?

2 1

Re: [tor-relays] Guard flag flapping
by torrry＠Safe-mail.net 10 Aug '15

10 Aug '15

> Thanks for running the tests. Which exit nodes led to poor performance? I would like to try to reproduce any performance problems. I did not record the nodes (they were in Europe). A simple test you could run on your server is fetching directory info from nodes that have directory functionality enabled. wget http://<relay IP>:<dir port>/tor/server/all e.g.: wget http://176.126.252.11:443/tor/server/all You can get a bandwidth-sorted list of nodes at: https://torstatus.blutmagie.de/ There is a column that has the directory port. > How would you measure performance between my node and a given exit without being influenced by the properties of the middle relay? You can only set me as an entrynode, and you can't pick a specific middle, You are wrong. :-) You can build arbitrary circuits by hand. There are libraries like Stem, Txtorcon, TorCtl and there is a text based, SMTP-like protocol that you can use directly: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt > so how would you know that the low performance was my node and not the random middle relay? Your node would be a non-random middle relay. > > The bandwidth auths probably downrate the measurement results of your server severely because of those slow connections. > > Probably? How can we investigate further? AFAIK, the raw bandwidth auth measurements are not published, only the total result.

4 3

Re: [tor-relays] I.P. being Blocked?
by Carlin Bingham 10 Aug '15

10 Aug '15

On Mon, 10 Aug 2015, at 05:19 AM, Roman Mamedov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, 9 Aug 2015 13:02:14 -0400 > Zack Weinberg <zackw(a)cmu.edu> wrote: > > > several "this IP is a source of spam" blacklists indiscriminately list _all_ > > Tor relays, whether or not they are exit nodes. > > Now this is just unnecessarily FUDish, at http://bgp.he.net/ one can check > their IPs against 49 RBLs, I checked several of my long-running relays' IPs, > and they are on none of the 49. > Try MX Toolbox's blacklist check[0], it searches over 90 blacklists and you'll find at the very least you're on one of the Tor-specific lists. [0] https://mxtoolbox.com/blacklists.aspx -- Carlin

5 4

I.P. being Blocked?
by Kurt Besig 09 Aug '15

09 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Without going into any detail at this point I'm wondering if others, running a simple middle relay, have encountered any governmental harassment as a direct result of running a relay. The blocking of state agencies e.g, CA.SDI.gov, CA.DMV.gov? Over the past month I've noticed regardless of which browser, machine on my LAN, and wired or wireless connection utilized it's become impossible to connect to any ca.gov site. I've researched my router, cable modem, and firewall settings, all appear to be fine. Spoke with my ISP, for whatever worth that might have, and was assured no blocking or filters were in place that would keep me from reaching these services and my settings looked fine from what they could see from their end. I'm able to connect to ca.gov sites using my phones 4G network or through Tor, however for some reason my home network and associated I.P. is poison. Any experiences/input would be appreciated. Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJVx4UrAAoJEJQqkaGlFNDPILMIALq/zYHqdm/QpThUI/vbr74L Q5lzLiVJBbxOxC3nWX/fuJL35FyS2FwOY4K+piI0EcDpY+wZ/m2hZh7wJLzwh9ok z0j0Dcp7GL3N2c64UP/7XFCrlaNtMm/0ke1xsxUkd0NahZNDCqv7BOkR9IX5yAfx lK5qOw9fpjyzVIdLd1LM1VArWGoEI6dR8PI3rmmGmzP6m9OGC8MxqW2rx+g1p0C5 0F+wDgnmM9rUa2VcgGXf7F4lJkEpUOtjwrsrasclLE8WbwBVv47a84eSSCLKCnUm rD5fUjFBgcaJtrVRgrwydWBcCuIujfxyiCz+Ku8+jtazB5cMdeiZjZN1pgRgKS8= =z1cc -----END PGP SIGNATURE----- --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 4

Re: [tor-relays] Guard flag flapping
by torrry＠Safe-mail.net 09 Aug '15

09 Aug '15

-------- Original Message -------- From: Green Dream <greendream848(a)gmail.com> Apparently from: tor-relays-bounces(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Guard flag flapping Date: Fri, 7 Aug 2015 21:49:16 -0700 > I've learned from this thread that the Guard flag flapping is a direct result of the low measured bandwidth. I still have no idea why the measured bandwidth is so (terribly, comically) low. The fact that it's so wrong is somewhat telling. Actual performance on the network is like 1000 times better than what the measured bandwidth says! Something feels very broken here. I ran some tests against your node. While performance is generally very good, it has very low performance connecting to some exit nodes. The problem is likely that your ISP is routing some traffic via an overloaded peering point. Some ISPs have been know to do that on purpose, e.g. to make connections to Netflix or Youtube extremely slow while claiming not to do throttling. The bandwidth auths probably downrate the measurement results of your server severely because of those slow connections.

2 1

BoingBoing: What happened when we got subpoenaed over our Tor exit node
by starlight.2015q3＠binnacle.cx 08 Aug '15

08 Aug '15

http://boingboing.net/2015/08/04/what-happened-when-the-fbi-sub.html check out comment #2 as well as the blog article

4 3

Re: [tor-relays] Guard flag flapping
by torrry＠Safe-mail.net 08 Aug '15

08 Aug '15

-------- Original Message -------- From: starlight.2015q3(a)binnacle.cx Apparently from: tor-relays-bounces(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Subject: [tor-relays] Guard flag flapping Date: Sat, 08 Aug 2015 14:39:48 -0400 > My advice is that this QWest service is third-rate > and rather than bleeding for the length of the > contract, run for the hills! > > If you are still in the 1-month cancellation > period (relays are about a month old), terminate > the service immediately and place an order for > Verizon FiOS. Verizon is one of those ISPs who have played routing games, slowing down Netflix and other traffic that happens to use use the same routing: http://www.extremetech.com/computing/186576-verizon-caught-throttling-netfl…

1 0

Guard flag flapping
by starlight.2015q3＠binnacle.cx 08 Aug '15

08 Aug '15

[apologies to all for thread-breaking, am really going on hiatus but the horror-show performance GBE topic was too darn interesting--last post I promise!] >I would call it a dedicated gigabit link. This is >probably up for debate. The provider's overall >capacity is very likely not [number of customers] >x [1 Gb/s] but I've never witnessed signs of >throttling or over-subscription. Pulling a whois on the IP 184.100.166.110 and a quick Google turned up that you are probably a bleeding-edge subscriber to this new Quest service: https://www.centurylink.com/fiber/ Running a filter on Blutmagie hostname contains quest shows that your relays are, by a huge margin, the fastest of about a dozen. My advice is that this QWest service is third-rate and rather than bleeding for the length of the contract, run for the hills! If you are still in the 1-month cancellation period (relays are about a month old), terminate the service immediately and place an order for Verizon FiOS. FiOS costs more, but sells real bandwidth instead of imaginary bandwidth. You can run a relay on a 75/75 MBit link (like mine) and obtain respectable bandwidth ranking. FiOS goes up to 1/2 GB for about $300-400 per month but the bandwidth is real and the network is good-to-excellent. Either that or switch to leasing a colo server in Germany or some other country where bandwidth is extremely cheap, or perhaps finding a cheap bandwidth colo in the US. QWest GBE looks like a turkey.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays