- tor-relays - lists.torproject.org

Are BWauths punishing 'bad' relays? (not publishing measurements)
by nusenu 18 Aug '15

18 Aug '15

Hi, this is actually a question to BWauth ops. even though the new onionoo measured flag data is not* yet completely rolled out (since it has to be deployed for > a week to assign the flag to all relays), I would have a question since the data says that all relays in the previously detected AWS family [1] are unmeasured. I'm wondering whether this is a pure coincidence or on purpose (by BWauths) or by some other yet to be found reason? thanks! [1] https://lists.torproject.org/pipermail/tor-talk/2015-July/038623.html The "spikes" in the following table brought me two that group again. The table shows unmeasured running relays by the month they joined the network (note this is based on preliminary onionoo data) The "spikes" are caused by relays mentioned in [1]. +-----------+---------+ | joinmonth | #relays | +-----------+---------+ | 2015-07 | 3 | | 2015-06 | 4 | | 2015-05 | 2 | | 2015-04 | 12 | <<< AWS family part II | 2015-03 | 4 | | 2015-02 | 35 | <<< AWS family part I | 2015-01 | 2 | | 2014-12 | 2 | | 2014-11 | 8 | | 2014-10 | 1 | | 2014-09 | 3 | | 2014-08 | 3 | | 2014-07 | 2 | | 2014-06 | 2 | | 2014-05 | 1 | | 2014-04 | 4 | | 2014-03 | 1 | | 2014-01 | 2 | | 2013-11 | 1 | | 2013-02 | 1 | | 2012-04 | 1 | | 2012-02 | 1 | +-----------+---------+ onionoo data from 2015-08-18 18:00:00 (thecthulhu instance)

2 2

No guard flag?
by Tor Tor 18 Aug '15

18 Aug '15

Hi, I'm running a relay node [1], and it's been up for a few days over 68 days. I was thinking it would get the guard flag around then. It has yet to get the flag or have non-zero guard probability. Any idea why that is? Or what I could do to get it to be a guard? 1) https://globe.torproject.org/#/relay/741488D89B860E59D6391ACA27A157E87EB533… Thanks, G

5 5

Guidelines for lifetime of a bridge?
by Tim Sammut 17 Aug '15

17 Aug '15

Hi. Is there a guideline for how long a bridge should exist on a particular IP address? For example, does it make sense to keep a bridge on one IP address forever? Or is it better to move a bridge to a new IP address periodically, perhaps every 120 days? I ask because I saw traffic to my bridge ramp-up fairly steadily, and then quickly drop-off to a low number of clients per day. Thanks! hope you are all well t -- Tim Sammut ~ @t1msammut ~ tim(a)teamsammut.com Ford-Mozilla Fellow at Amnesty International

5 5

urras? [was: tor network "loses" ~50 relays/day due to bw auth problem]
by coderman 16 Aug '15

16 Aug '15

On 5/31/15, Jannis Wiese <mail(a)janniswiese.com> wrote: > ... > At the moment I just see urras missing from the consensus... i would like to report a missing Tor-DA to the authorities. ;) best regards,

2 1

do not run Tor client and OR relay together!
by starlight.2015q3＠binnacle.cx 16 Aug '15

16 Aug '15

Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process. The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis. See bug 16585, particularly comment 5 and onward: https://trac.torproject.org/projects/tor/ticket/16585#comment:5 Perhaps read comment 10 first.

7 8

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 11 Aug '15

11 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 09 Aug '15

09 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

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

08 Aug '15

>The problem is likely that your ISP is routing >some traffic via an overloaded peering point. Running traceroute -w 1 -q 5 -A <bwauth-IP> 1400 may provide more detail on this issue. The -A option causes 'traceroute' to show Autonomous System numbers with each route hop, where ASNs are Internet routing domains associated with different network providers. One can readily see where big increases in latency are occurring along the path and what peerings are associated with it. Note that some big increases are justified--such as with a hop over a transatlantic cable. Setting -q 5 (or bigger) causes traceroute to attempt each hop that many times. If you see asterisk characters, that's packet loss and may indicate congestion points. Setting the packet size to 1400 will increase the probability that network congestion will impact the results. Try pulling up https: // torstatus dot blutmagie dot de which shows IPs together with other relay attributes and experiment tracing to various major relays.

1 0

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

08 Aug '15

>. . .have physical access to the . . . ONT. > Doubt this is the case, but on the off chance that the ONT is configured to flow IP traffic over a coaxial cable attached to a CPE router (customer premise equipment), the configuration should be changed to deliver data over a Gigabit Ethernet directly to a good-quality GBE switch provided by you. New eight-port Netgears are surprisingly good managed switches for around $100. For under $600 you can purchase used 24-or-48-port Nortel/Avaya 5510/5520 switches on eBay. Though old, these enterprise grade switches have astounding performance characteristics due to the Broadcom silicon switch-fabric chipset. Were around $7000 new when they were current-gen. All above switches have VLAN support so one switch can operate as multiple isolated networks. I run a Verizon FiOS 75/75 and the default setup is for Internet traffic to pass to a Verizon supplied Actiontec router over a coax cable. Fortunately I hung out with the installer and found out up front--had it switched to the GBE from the outset. For any VZ customers reading this, note that you can connect the Actiontec to your network so it can obtain TV programming information. The coax will continue to carry video and phone data which are on separate fiber optic wavelengths/channels.

1 0

onionoo.thecthulhu.com: 500 Server Error
by nusenu 08 Aug '15

08 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Thomas, in case this is not known to you yet: There appears to be a problem with your onionoo instance: https://onionoo.thecthulhu.com/summary?limit=1 Error 500 Server Error -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVxZ6AAAoJEFv7XvVCELh05cUQALASqTfj6gZTb8gd73WT/9mB gcUHqhl6scGBNW9Vl88X0uAk55HdO36nqOc/rTv9GaMSFQQ1bgO1nUIFWTvDcpNG /yLTHwWOshoaVNLmL6kJV4KiaLDtUjA3jY8knh59mIYBjL6gLaIKjp8c55i4HUzM UmYa9vPVVOmdWhAuIoIImbEfQqRcR61Ig0NBGheYWF7AAPBgQUv9c+c4fCYOBnla hs9pEMQJ/5u860RJqfETbEe/JVwD3zD+gJL9S7tshQNWKFAShPElgVMRvPu0aRK2 7IIG4szdinqXKd/7Ii9ZtllhWGu9vDGYeFP+9U/sHg4RGZ7bJhLwsMd5VTOgLGpb b5IEPxfTxfSN27FJig+bj6NNCtsVEmYKFayeWhAbml2Rip60a9fc+OBd9tGP6jlb pGCtox02kVUt+7zFJv1sqdf3Qp05RwvETr0it5d0V2+Lm68MRfVZDZ7O24IOTaYp eG6gBMnkmL2hNbgNgUMlvqOOiLYOyjlzhJx1toFLJcdWm9yfSTn90DrfaDFzMacF RRa7oW/mCzo0vseYhTWKJO8w4HJZJUbumZ0w11liqJbJQc1bg4nSVHurVf88Fb6H 5E80IsSFqNA1/vp15tTQsuAkTCK/ycLkKpPYd4Sz8ZEGiKXVqCNszG0QX8MCgk9Q QHz0wwggcg9wGiHFG13l =9H2Z -----END PGP SIGNATURE-----

2 2

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

08 Aug '15

>I had already run tests with both speedtest-cli >and iperf3. This server consistently achieves 200 >to 300 Mb/s in both directions, with both relays >still running, and on some runs is hitting over >800 Mb/s. Final caveats: If the server is on a shared gigabit link, performance may not improve. The difference between a dedicated gigabit and a shared gigabit is immense. One expects an ISP to load a shared GB links as heavily as possible--I.E. up to the point where customers complain and terminate service. True dedicated gigabit links are expensive. If it's running in a VPS that's showing a gigabit link speed, the number is fiction.

2 1

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

07 Aug '15

One more errata: The sense of this is negative, so the current setting you have is correct: net.ipv4.tcp_no_metrics_save = 0 The double-negative got me.

1 0

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

07 Aug '15

comments backward, but the sysctls are correct * 25 milliseconds or 3125000 (for write) * 40 milliseconds or 5000000 (for read)

1 0

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

07 Aug '15

Ah, forgot to calculate the default TCP windows for you link speed rather than mine. So that's 125000000 bytes/sec ( 1 gigabit / sec ) * 25 milliseconds or 3125000 (for read) * 40 milliseconds or 5000000 (for write) net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_wmem = 4096 3125000 16777216 net.ipv4.tcp_rmem = 4096 5000000 16777216 The 25 and 40 milliseconds are my guess at roughly the faster and more middle ping times within the domestic US Internet. This just gets each connection started net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_timestamps = 1 cause the IP stack to very quickly establish precise values for the transmit and receive TCP windows.

1 0

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

07 Aug '15

First, I am assuming you are running bare-metal on a system and not in a virtualized server--everything below is premised on that. Do not expect a virtual server or Linux container to perform well as a high- capacity Tor relay. It's possible to configure a high-performance VM, but this is an esoteric art and one is better off renting a small dedicated physical server than going that route. Your story of a relay setup that should measure fast by all apparent metrics but is given terrible rankings by BWauths is common this year. BWauths scripts are known to be buggy, though supposedly have been improved very recently. 'longclaw' just came back online with the "latest" code, but after starting out with a failure to measure 2000 relays two days ago, it's still running 1000 shy of the full population: https://consensus-health.torproject.org/#bwauthstatus Scroll down a little and you will see 'longclaw' is unique in voting 976 relays not-guard and 1709 relays not-fast. That seems a more serious issue than cold start glitching IMO, and is not impressive if that is what it really is. A fifth BWauth is said to be arriving soon and it is said that it will help. Your relays currently are measured thusly: greendream848 longclaw-w Bandwidth=1694 Measured=986 gabelmoo-w Bandwidth=1694 Measured=347 maatuska-w Bandwidth=1694 Measured=874 moria1 -w Bandwidth=1694 Measured=1550 spacequeen974 longclaw-w Bandwidth=1698 Measured=493 gabelmoo-w Bandwidth=1698 Measured=970 maatuska-w Bandwidth=1698 Measured=1930 moria1 -w Bandwidth=1698 Measured=2130 You can see future and past reports of these in https://collector.torproject.org/recent/relay-descriptors/votes/ https://collector.torproject.org/archive/relay-descriptors/votes/ where longclaw is 23D15D9. . . gabelmoo is ED03BB6. . . maatuska is 49015F7. . . moria1 is D586D18. . . That the measurements are all in the same ballpark does indicate that some subtle issue with the network and/or equipment may be at work and the BWauths may not be at fault. But many have complained that nothing they do seems to work. If the firewall is performing stateful packet inspection or any kind of DPI (deep packet inspection) disable that for all incoming and outgoing Tor traffic. It's all encrypted anyway so there's no point, and DPI can drag down performance big-time. The directory traffic is unencrypted but I've never heard of a firewall with stateful rules for the Tor directory protocol. If you can put the system directly on the public IP address with no firewall or local-rack router I recommend doing this. Just make sure iptables are set to protect login and other non-tor access. Either that or disable iptables and strip the server down so that nothing but the 'tor' process and 'ssh' are running, and configure 'ssh' to accept only certificate authentication (be sure to set and test the cert auth before applying the setting). Check for minimized listeners with lsof -Pn | fgrep LISTEN The email daemon should stay up to handle alarms, just be sure it listens on 127.0.0.1. Likewise anything else that is absolutely necessary. Use *Port and *Policy settings in torrc to lock down control and socks access to the daemon. One notable sysctl that matters for high-capacity relays is net.netfilter.nf_conntrack_checksum = 0 though having this enabled would not cause the current poor measurements. You should change this setting: net.ipv4.tcp_no_metrics_save = 1 turning this off was to work around a very- long-ago kernel bug that is fixed everywhere. Turning it on improves performance. You might try net.ipv4.tcp_wmem = 4096 250000 4194304 net.ipv4.tcp_rmem = 4096 375000 4194304 which will cause the congestion window to get to full size a bit quicker, and these net.core.somaxconn = 1024 net.core.netdev_max_backlog = 524288 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_keepalive_time = 600 which increase various limits for fast networks, lots of connections. Make sure these defaults values are active and have not been changed to non-default by /etc/sysctl.conf: net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_congestion_control = cubic And try adding TXQUEUELEN=100000 to the /etc/sysconfig/network-scripts/ifcfg-ethX for the interface(s) where tor runs. Manually activated with ip link set qlen 100000 dev ethX ip link show dev ethX Finally make sure the kernel is of a vintage with the Google-advocated connection-start congestion-window increase: https://lwn.net/Articles/427104/ http://samsaffron.com/archive/2012/03/01/why-upgrading-your-linux-kernel-wi… http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi… If you end up implementing any of the above and it works please describe the results in tor-relays post.

1 0

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

07 Aug '15

Both relays are showing low BWauth-measured bandwidth and are below the 2000 threshold for the Guard flag. Recently BWauths were offline and the consensus algorithm reverted to self- measure. During that period the relays were above the 2000 threshold and were assigned Guard. But even the self-measure was very low for a gigabit link in a tier-1 network (Quest). Some more tuning work is probably needed to get performance up higher. Possibly network issues are at work. If a low-end consumer-grade router or firewall is in the picture, it could be the cause of the problem.

2 2

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

07 Aug '15

You might start with running SpeedTest via the Python script to see how the network performance looks: https://pypi.python.org/pypi/speedtest-cli/

1 0

most hibernating relays wake up at the same time
by nusenu 07 Aug '15

07 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, most hibernating relays with daily quotas start relaying traffic at 0:00 local time. The timezone introduces some distribution but most relays are located in UTC +02:00 so most of them start relaying at 22:00 UTC. If you run a hibernating relay and want to spread your resources more evenly you can set a non-default AccountingStart time, simply choose HH:MM in that setting as you wish. (yes, AccountingStart != wakup time, but in practice it is the case for most hibernating relays with daily quotas) If someone has stats on when the tor network needs most bandwidth during the day it might makes sense to set AccountingStart accordingly - - to add bandwidth when most users need it. (but bw doesn't seem to be an issue currently..) Reference: https://trac.torproject.org/projects/tor/ticket/16723 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVw9GgAAoJEFv7XvVCELh08iEP+wQ0F0+62ktQhR8fCFe+9yLS HacxpzLMG/4jDL0MmimVqCr5Ql9P05CXKzLse7ItEWNn5PlEkZ6z37DlQ9ctNgjY EwMlXZc1z+gLWRtHaWy6Yd0YUWkOfVfRu3bO2QDa5AN1/cEGv6+R8ddm1Ny2Mfem 5zMILOR3tofVNtpyFlahUQDEf2wQuZBMwmpYykD3I2+MfnOoeTe2AXHmgwtMdaNQ +CG+dEp8DueIYINqkYBWzmBZyTjtv3Z/ADHqyUDqFdwEsSWeC54Yb/2fZh1IEJub 383Zvhb4T3LRF2dUvKRFSCzTZl6FqZ4R1W2RvRV2Hg7xXtllbFUC/jY5i7zuJfe0 /aA5ZUv5+Rrqk7uOJpLaf6sXJGJBwCL1W5qDEtoZzQjHxbA8TFBQFYXtEfRUKiXA AiBFaJ+eLJlyztt38B6FxkN8auC25Y8csFtwcj25b8zykN4t+sFbrJvqy9r+dpzC klUlJuAlj3Oljjo4Ppd02k47yxmkc17e3TT5wm6tI2k8ZX7cD4GrK5ely+lxh/iz uceyEb7vphliJwt/slLQl9/wtg8dLvdIrpZ/rRO8uCVubSNodUuoyvuAtWn+xjsp BvwrCL0u6C/tkzRWR6OZPpuepnMk3vil9lNRkKuOadKnr2rihFb6qXgZg0RKpQDu IWCw2pXlUbbycW7K84Go =IYU/ -----END PGP SIGNATURE-----

3 4

Guard flag flapping
by Green Dream 07 Aug '15

07 Aug '15

I have two relays on the same Gb/s connection. I followed the optimization tips offered in another thread, and think I have things running reasonably well. What I don't understand is why the Guard flag keeps flapping back and forth on both relays. https://atlas.torproject.org/#details/89B9AE4C778DE44AFFAB791093E19979616E6… https://atlas.torproject.org/#details/11A579CC6CEE644A390704977B70CBA8D8347… If you look at the 1 week graph of weights, you'll see what I mean. I haven't been able to find any documentation or explanation for this behavior. Anyone have any thoughts on why this might be happening, or any pointers on how to further investigate?

1 0

longclaw BWauth is back, not measuring 2000 relays, what's with that?
by starlight.2015q3＠binnacle.cx 06 Aug '15

06 Aug '15

The explanation does help--thank you. Have been interested in how it would look after the script update since 7/28 (nine days ago) but did not realize it took so long to rebuild the data.

1 0

longclaw BWauth is back, not measuring 2000 relays, what's with that?
by starlight.2015q3＠binnacle.cx 06 Aug '15

06 Aug '15

longclaw 4691 Measured values in w lines maatuska 6815 Measured values in w lines gabelmoo 6347 Measured values in w lines moria1 6715 Measured values in w lines

2 1

BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 06 Aug '15

06 Aug '15

FYI list https://trac.torproject.org/projects/tor/ticket/16696 Description At present both 'longclaw' and 'maatuska' have dropped out of the BW consensus ('longclaw' is restarting with new version, not sure about 'maatuska'). This has caused the BW consensus logic to revert to using relay self-measurement for BW weightings due to fewer than three BW authorities participating. The 10000 cap placed on self-measure values is causing super-fast relays serious demotion and slower relays corresponding promotion in the consensus weighting. Possibly this may result in network unbalance issues. Some adjustment of the logic seems in order.

10 12

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

>At Tue Aug 4 11:22:22 UTC 2015 by Olaf Selke olaf DOT selke at blutmagie DOT de > >by the way... I will probably shut down blutmagie >tor network status in September this year cause >the data center has terminated the contract >housing my servers 10/31/15. Could you make your modified Torstatus code available on https://gitweb.torproject.org/torstatus so that someone else can set up another like it? Blutmagie appears to have significant and desirable enhancements to the code presently in the GIT repository. I might contribute a new Torstatus, but if not me someone surely will.

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Maybe geo-location would not be so great because two networks in the same physical area might have relatively poor connectivity to each other. Aggregated IP block might be the ticket. CIDR-Report has both actual and suggested netblock aggregations. http://www.cidr-report.org/as2.0/#Gains Shows 562259 reduced to 253420 advertisements. Perhaps too fine-grained, but 250k is not so much bigger than the 45k ASN count. Idea is to anchor metrics to maximum size BGP routable blocks, which ought to correlate performance-wise down to all the IPs in each block. >>BWauths are continuously pairing relays for >>measurements, and perhaps metrics from that >>could be mapped to autonomous system numbers > >. . .scratch AS, geo-location is >better and MaxMind specializes in that > >Pinging a FiOS relay in LA takes >75ms while a close-by relay takes >8ms. Both are in AS 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

>BWauths are continuously pairing relays for >measurements, and perhaps metrics from that >could be mapped to autonomous system numbers . . .scratch AS, geo-location is better and MaxMind specializes in that Pinging a FiOS relay in LA takes 75ms while a close-by relay takes 8ms. Both are in AS 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 22:17:54 UTC 2015 by Mike Perry mikeperry at torproject dot org > >In some instances where I have not selected >my guards manually, Tor Browser is unbearably >slow. Like really, really painfully slow. >The whole time. Until I reinstall it. > >This makes me think that the performance of >people who pick guards from the tail is much >much worse than the performance of the top >guards, and this property likely is acting as >a deterrent to adoption. > Perhaps the guard-selection algorithm could be enhanced to consider some sort of distance/reachability metric generated by BWauths? BWauths are continuously pairing relays for measurements, and perhaps metrics from that could be mapped to autonomous system numbers (from MaxMind) in a useful way without requiring tremendous effort? Matrix analysis comes to mind. If one's guard is on the other side of the world, network latency and random congestion will hurt. I've read some path selection research is under way with an eye toward reducing passive traffic correlation exposure--this seems like it would help performance in a similar way.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Many under-utilized and never-utilized exits relays back online with BWauth outage. Unscientific sample out of 234 previously Unmeasured=1 exit relays, but almost all of the ones checked are like these https://atlas.torproject.org/#details/0D7739DEF50470356744440435FED9E1F57EF… https://atlas.torproject.org/#details/1E014CF541F32F377A116E78B76A603B8346A… https://atlas.torproject.org/#details/2316E6F012ACA52FDB09C745B0F5B41E78C23… https://atlas.torproject.org/#details/2A63402166192D66018D3FCB1ED8DE740CE71… https://atlas.torproject.org/#details/37C49200E04C8FE70799430718B10CEA5DBFB… https://atlas.torproject.org/#details/47BDCB56A9CCDAAAA71D74549E388C8EA1265…

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Poking around Blutmagie, I suspect the number of relays with chopped bandwidth weightings might be more like in the range of 25-45. Perhaps the PID-controller algorithm should be adjusted to bias somewhat less toward super-fast relays.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 20:16:17 UTC 2015 by Jannis Wiese mail at janniswiese.com >Strange thing: My relay [0] is speeding up since then >significantly (finally!!) That's because with no BWauth quorum the consensus algorithm reverts to using self-measured bandwidth with a ceiling of 10000. This causes the weight super-fast relays to drop substantially and provides a corresponding boost to middle and slower relays. Also puts most of the 450 Unmeasured=1 relays back in the game. In addition, this state eliminates all the crazy-stupid-buggy behavior of the BWauths that has been vexing operators so much. Only losers are the folks with huge bandwidth + CPU + tweaking in their relays, but the drop is not all that terrible. I've been watching this for two-plus days now and the Tor network rather runs better this way. Looks like no more than 50-100 relays are in the category where the weight is cut substantially, and plenty of unused capacity exists in the other 3000 or useable relays to make up the difference. Unfortunately the BWauths will likely be back due to the problem of adversarial gaming of the self-measure values. Even with a cap of 10000 someone will figure out ways to abuse the old pre-2009 approach of balancing the network. One can only hope that enough of the bugs have been worked out that BWauths will be behaving better going forward.

1 0

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q2＠binnacle.cx 04 Aug '15

04 Aug '15

FYI list https: // torstatus DOT blutmagie DOT de is registering relays running 0.2.7.2 as having zero bandwidth. I believe this is because the write-history read-history lines in extra-info have moved from the top down to the middle of the document. Many super-fast relays running 0.2.7.2 are showing zero bandwidth and have dropped to the bottom of the ranking as a result. Might be a bug in 'metrics-db' or it might be a bug in a Blutmagie customization. Seems that the code at https://gitweb.torproject.org/torstatus.git/ retrieves advertised (self-measure) bandwidth rather than consumed bandwidth, so it's hard to say without a deep-dive into the code. I'm going by the fact that the new https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc shows advertised bandwidth and presumably runs code from the GIT repository. Sent an e-mail to Olaf Selke advising him of this issue. Not sure if he still maintains it, but the message did not bounce.

3 5

Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
by torrry＠Safe-mail.net 03 Aug '15

03 Aug '15

> debugging the old Blutmagie Perl scripts I found all routers like > splitDNA running Tor 0.2.7.2 sending two hash values in the > extra-info-digest. I suppose this isn't expected by the script parsing > the data. > > GETINFO desc/name/splitDNA > 250+desc/name/splitDNA= > router splitDNA 62.210.82.44 21 0 143 > [...] > extra-info-digest D6F7A98078BDA327D388D918EBA92D0FC9EDC487 > nMA7WhPSpQmquUdYpwIdQtdcKvTAcvNDnXleiPBia0U It shouldn't be expected by the script: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt ------------------------------------------------------------------ "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) ------------------------------------------------------------------- Fetching descriptors via: http://<DIR_SERVER>/tor/server/all has 2 values for extra-info-digest as well.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >I wonder if you could just run sslyze (or another >TLS scanning tool) on the OR ports of all the >relays, and see what ciphersuites they accept. The info would be indicative, but it would not reflect client-only Tor, which represents the majority of installations. Is why I think collecting connection statistics a good idea.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

Of course! This is implicit in my posting. What I am saying is that, like old v1/v2 handshakes, Tor should be moving in the direction of eliminating DHE. The way to approach that is to *count* the number of DHE handshakes and other TLS session attributes. This is currently begin done for TOR/NTOR handshakes but is not for TLS negotiations. 0.2.7 will not build/run with openssl 0.9.8, so once 0.2.7 is widely deployed DHE can be forcibly disabled. BUT, as with v1/v2 handshakes, one would not want to do that prematurely so counting them is a good idea. That suggesting is the principle idea of the thread. At 20:01 8/2/2015 +0300, you wrote: >I think that is to maintain a backward >compatibility. Tor tries as hard as possible to >maintain backward compatibility with older >versions, unless something critical which requires >deprecation regardless some relays will disappear >from the consensus. > >I guess this is the reason we currently prefer >ECDHE but do not reject DHE. In the future, when >we are certain everyone upgraded to new enough >OpenSSL, we can safely reject DHE all the time. >

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >It also may not tell you their ordering >preference (but it might! again, >you'd have to look at the code.) That "openssl s_client" test I ran was against my 0.2.6.10 with openssl 1.0.2 relay. It's certain that ECDHE is preferred over DHE, but my thought is that, especially with 0.2.7 dropping openssl 0.9.8 (no ECDHE), that relays should refuse to accept DHE connections entirely. We've seen many downgrade attacks and who knows for certain if none remain buried in the openssl? Seems prudent to kill-off DHE.

2 1

relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

In the next-above thread I had mistakenly conflated relay handshakes and 'openssl' TLS negotiations, which are it seems entirely independent. Thanks to Yawning for correcting that misconception. TLS encryption protects the relay-to-relay conversation protocol if I understand correctly, while cells are further encrypted with EC curve 25519 for the actual layered/onion encryption. Per ticket https://trac.torproject.org/projects/tor/ticket/15212 relay handshake types are counted and logged in the heartbeat message with the idea that the old v1/v2 handshake support should soon be eliminated soon. Now I wonder why the TLS handshake types are not also counted with the idea that DHE-RSA-AES256-SHA should be eliminated entirely due the near certainty that the NSA can decrypt any such sessions negotiated using the default DH 1024 bit primes, per the LogJam research https://weakdh.org/ I know that 0.2.7 is eliminating 'openssl' 0.9.8 from the picture, but this does not prevent $ openssl s_client -connect addr:port -tls1 -cipher EDH from successfully establishing a connection to relay OR ports with the aforementioned suspect DHE encryption level. Seems to me forcible prevention of this level of TLS session should be nearly as important as moving to the new ed25519 identity keys. In addition to ECDHE vs DHE, it might make sense to count how many SSL 3, TLS 1.0, 1.1 and 1.2 connections are established to be certain SSL 3 is really dead and to see how quickly TLS 1.2 is fully supported everywhere. Perhaps which ECDHE curve is selected should also be tracked.

2 1

Tor 2.6.10 fails to generate fresh DH Keys
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

>Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. > Looks like you have DynamicDHGroups enabled in your torrc file. This is interesting because the recent LogJam research indicates the NSA has probably broken commonly used 1024 bit DH groups, which suggests turning on this parameter. However it was disabled by default some time ago for anti-fingerprinting reasons: https://trac.torproject.org/projects/tor/ticket/5598 AND, it's probably a moot issue now that Ntor handshakes (elliptic curve) have overtaken older RSA connections. So you should delete DynamicDHGroups 1 from torrc and let it be disabled by default.

3 3

Tor 2.6.10 fails to generate fresh DH Keys
by cyb3rwr3ck 01 Aug '15

01 Aug '15

Hi there, after a unsuspected reboot of wr3ck3d0ni0n01 I decided to refresh all the keys. I took the chance to upgrade to 2.6.10 (Debian) and recognized that the relay wont start afterwards. It looks like it is unable to generate the new krypto: Aug 01 11:56:01.000 [notice] Tor 0.2.6.10 (git-71459b2fe953a1c0) opening log file. Aug 01 11:56:01.000 [notice] Generating fresh dynamic DH modulus. This might take a while... Aug 01 11:56:01.000 [err] tor_assertion_failed_(): Bug: ../src/common/crypto.c:1788: crypto_generate_dynamic_dh_modulus: Assertion r == 0 failed; aborting. Aug 01 11:56:01.000 [err] Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. Stack trace: Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x7f892b3b3601] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x9f) [0x7f892b3c0def] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(crypto_set_tls_dh_prime+0x7db) [0x7f892b3cfb1b] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(set_options+0x1ce5) [0x7f892b35ee25] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_string+0x2d3) [0x7f892b35f503] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_torrc+0x1ca) [0x7f892b35f81a] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_init+0x2e2) [0x7f892b2d1202] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_main+0x55) [0x7f892b2d23a5] Aug 01 11:56:01.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f8929bc2ead] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(+0x362ad) [0x7f892b2cd2ad] I wasn’t able to find any known bugs regarding this behaviour. Anyone out there who has seen this before? Best regards! Felix

1 0

Re: [tor-relays] what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Ended up reading rephist.c for awhile. Seems the up/down time is accumulated with downtime discounted %5 every 12 hours. So absolute worst-case age-out for 100% downtime would be something like .95 ^ 76 (35.5 days) to get down it to 2%. Since the outage is not as bad as that, the guard flag should show up sooner. Not interested enough to calculated the exact answer. Will just watch it.

1 0

what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Does anyone know how long it takes for the guard flag to come back after a multi-day relay downtime? Know that WTU (weighted time up) is 98%, and new-relay TK (time known) minimum is eight days. Reading rephist.c the the WTU is calculated from uptime history but rather then spend awhile to fully understand it seemed worth asking. Presently watching a relay that has been around six weeks, has been down four days recently and five total, has 14-day 100% uptime, Globe- calculated 1-month uptime of 85% and 3-month uptime of 90%. Had guard a couple of times but has not seen it return after the last outage.

1 0

my provider null routed my exit. advice?
by Christopher Yeager 31 Jul '15

31 Jul '15

Hello, I run a 100mb exit hosted at server.lu since sometime in late 2013. There have been a couple dozen abuse reports but normally they forward them to me to deal with and nothing much happens. However a week or so ago, while I was travelling, there was an abuse report that made them decide to file a ticket which then led to them suspending my IP as I 'ignored' it while I was gone. So now I'm trying to convince them to turn the system back on and they are pushing back, and after some back and forth they say they want me to run an exit policy consisting of ports 53, 80, and 443. I've been running the suggested reduced exit policy since day one and am very reluctant to pare it down further, and certainly not to just 3 ports. I wrote a short note explaining my point of view and I wonder if any of you would do me the courtesy of telling me if I am likely to convince them to let me leave the exit policy alone. I'm very willing to edit my response as required. I think it bears mentioning that I am several messages in and I did not get a good sense that whoever I am talking to understands Tor very well at all - I was repeatedly asked to find and block my customer, and told I must have logs if I provide a service, etc. I can show you the longer exchange if you think it might be helpful. Thanks in advance and here goes: --- Hello, We have nothing against Tor but IP is listed at 11 blacklists including Spamhaus ZEN. So we have to ask you block all ports except 80, 53 and 443 to prevent scan, spam and other infringing activity from your IP. Hope such proposal will be suitable for you. Regards, ROOT S.A. --- Hello again, I would rather not block any more ports that are already blocked. The system is already set up to use the reduced exit policy detailed at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy which allows as many Internet services as possible while still blocking the majority of TCP ports. Currently, the policy allows approximately 65 ports. I am reluctant to further reduce the ports because there is vastly more to the internet than just the world wide web. Email, chat, remote desktop, cache, and vpn services are all valid uses of the network that would not be allowed by such a restrictive exit policy. I'm also afraid that it will not help much in getting this IP off the various blocklists that it is on, as 2/3rds of the abuse reports I've been sent were due to traffic on ports 80 or 443. Several of the lists such as SECTOOR and Dans TOREXIT and related are simply reporting to the world that this system is a Tor node. The system is only in the Spamhaus Zen list due to its listing in the CBL for being "infected with, or is NATting for a machine infected with s_vawtrak" which is a Microsoft Windows virus that connected to their sinkhole IP on port 80. Being on blocklists is something that happens when you are running a Tor exit node and supporting Tor means putting up with them and explaining why Tor is worth supporting even though abuse is guaranteed to happen. Naturally if you require this change I will be forced to make it. I hope, however, that you can be persuaded that it is not helpful to Tor and will not solve the problem of abuse and blacklists even if it were. Thanks again. -- Thanks for getting this far. I await your replies with interest. :)

3 2

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Welcome. This event led to my discovering the Unmeasured=1 flag in the cached-*consensus files (was wondering where it was). That new BWauth is badly needed. See about 460 unmeasured relays and from an unscientific sample it seems like many of them are stuck-at-20 exit nodes--valuable resources that should be utilized. At 15:17 7/30/2015 -0500, you wrote: >On 30 July 2015 at 12:14, Tom Ritter <tom(a)ritter.vg> wrote: >> Thanks for the heads up! >> >> A fifth bwauth is expected to start >> voting "real soon now", and I'm >> not sure why maatuska didn't vote >> on bwauth data last vote, but I've >> pinged some folks so hopefully we >> can get this resolved quickly. > >Aaaand we're back! =) Sorry for the outage. > >Bandwidth scanner status > >maatuska 6890 Measured values in w lines >gabelmoo 6444 Measured values in w lines >moria1 6754 Measured values in w lines > >-tom

1 0

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Much of Tor traffic is from long-term circuits moving bulk data, so apparently it will take many hours or even days for rebalancing to fully take effect. Is not clear whether it will cause serious trouble or not. My thought is that one BWauth in a consensus is better than self-measure, as BWauths are trusted entities and a single rouge BWauth in some kind of attack taking out the rest would be dealt with via manual intervention or the closing down of Tor. Perhaps the self-measure cap of 10k should be raised as well. Was an anti-gaming mitigation from the pre- BWauth days and may have even preceded the arrival of super-fast relays. At 12:14 7/30/2015 -0500, you wrote: >Thanks for the heads up! > >A fifth bwauth is expected to start voting "real >soon now", and I'm not sure why maatuska didn't >vote on bwauth data last vote, but I've pinged >some folks so hopefully we can get this resolved >quickly. > >-tom > >On 30 July 2015 at 12:04, <starlight.2015q2(a)binnacle.cx> wrote: >> FYI list >> >> https://trac.torproject.org/projects/tor/ticket/16696 >> >> Description >> >> At present both 'longclaw' and 'maatuska' have >> dropped out of the BW consensus ('longclaw' >> is restarting with new version, not sure >> about 'maatuska'). >> >> This has caused the BW consensus logic to revert >> to using relay self-measurement for BW weightings >> due to fewer than three BW authorities participating. >> >> The 10000 cap placed on self-measure values >> is causing super-fast relays serious demotion >> and slower relays corresponding promotion >> in the consensus weighting. >> >> Possibly this may result in network >> unbalance issues. Some adjustment >> of the logic seems in order. >>

1 0