- tor-relays - lists.torproject.org

Re: [tor-relays] Pi3 mid relay dropping lil bit of packets
by Pi3 16 Aug '16

16 Aug '16

Ok thank you for replies, will keep an eye on this. On Tue, Aug 16, 2016 at 6:11 AM, Green Dream <greendream848(a)gmail.com> wrote: Counter-point... transmission errors are not a certainty: RX packets:323526978271 errors:0 dropped:0 overruns:0 frame:0 TX packets:249565709357 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:285274358053849 (285.2 TB) TX bytes:287754558279252 (287.7 TB) Ideally there should be no errors. :) 11 dropped packets isn't a big deal, but I wouldn't be quick to dismiss these errors by default. In certain cases things might be improved with driver updates, or sysctl tweaks, or a new ethernet cable, etc. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

spelling mistake
by I 16 Aug '16

16 Aug '16

2 1

Pi3 mid relay dropping lil bit of packets
by Pi3 16 Aug '16

16 Aug '16

Hello, I just started running my little 5 mbits mid relay on Pi3 on raspbian and all seems to be dandy, it picked traffic nicely, hovering around 700-800 total connections, its not unusual to see it pushing full advertised bandwidth during peak hours (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice. Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 (eleven) packets dropped on eth0. Google says it can be ring buffer on NIC getting full, but ethtool -g eth0 says Ring parameters for eth0: Cannot get device ring settings: Operation not supported ethtool -S eth0 = no stats available Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard conntrack cstate established related iptable rule with default drop. Pi3 is in LAN behind modem nat. It worries me because if I get more consensus, drops will probably go up. I didnt apply any sysctl tweaks. Using official deb NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and its internally connected to usb2 by design - it shows under lsusb. ethtool says 100Mb/s full duplex. Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt miss anything. Or is it so marginal I should forget about it? Im not sure what should I do about it, any suggestions are welcomed. Thanks

4 3

obfs4 - git how to ?
by Petrusko 15 Aug '16

15 Aug '16

Trying to use obfs4 from git on a test bridge : With "root" user: cd /home/TEST git clone https://git.torproject.org/pluggable-transports/obfs4.git ln -s /home/TEST/obfs4/obfs4proxy /usr/bin/obfs4proxy torrc file : [...] ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy managed ServerTransportListenAddr obfs4 0.0.0.0:48001 In the log when starting Tor : [...] [warn] Could not launch managed proxy executable at '/usr/bin/obfs4proxy' ('Permission denied'). [...] Tor is still working and is connected to the network... Humm, I think I've not understand how to use this source, and how to manage it ?! Thx for you help :) -- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

4 4

Re: [tor-relays] Pi3 mid relay dropping lil bit of packets
by Tristan 15 Aug '16

15 Aug '16

Personal opinion here: 11 packets dropped on 20GB of data sounds pretty small, and these packets might not even be from Tor. Literally any network service could have dropped those packets (ntp, ssh, updates, etc.) I wouldn't worry about it unless it starts to dramatically increase. On Aug 15, 2016 1:08 PM, "Pi3" <tor-relays(a)mixbox.pl> wrote: Hello, I just started running my little 5 mbits mid relay on Pi3 on raspbian and all seems to be dandy, it picked traffic nicely, hovering around 700-800 total connections, its not unusual to see it pushing full advertised bandwidth during peak hours (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice. Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 (eleven) packets dropped on eth0. Google says it can be ring buffer on NIC getting full, but ethtool -g eth0 says Ring parameters for eth0: Cannot get device ring settings: Operation not supported ethtool -S eth0 = no stats available Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard conntrack cstate established related iptable rule with default drop. Pi3 is in LAN behind modem nat. It worries me because if I get more consensus, drops will probably go up. I didnt apply any sysctl tweaks. Using official deb NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and its internally connected to usb2 by design - it shows under lsusb. ethtool says 100Mb/s full duplex. Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt miss anything. Or is it so marginal I should forget about it? Im not sure what should I do about it, any suggestions are welcomed. Thanks _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Do middle nodes create multiple connections to the same Exit node? (with different source port)
by don.gould＠tuta.io 15 Aug '16

15 Aug '16

Hello, Do middle nodes create multiple connections to the same Exit node? (with different source port) The reason I ask is because I am a little confused. Even the tor relay operators are completely honest and don't log anything, the ISP / upstream ISP could still log all the connections. So they can see: [MiddleNode IP]:[Source Port] ==> [ExitNode IP]:[Dest Port (ORport)] -- Timestamp + Duration of connection. So if I create a long running ssh connection that is going for 6 hours this will be unique to the middle node. During this 6 hours, if another tor client chooses the same MiddleNode + ExitNode, does the MiddleNode create a new connection to the ExitNode? (Can be found out using netstat) Or does it use the same connection that it already has established with the exit node? Thanks.

2 1

High speed Tor relay advice
by i3 15 Aug '16

15 Aug '16

Hi all, I've ran multiple Tor relays before but I have moved to a new server and would like some advice. My new server has 10Gb/s connection (I've observed it at 900MB/s to the drives) with plenty of CPU and RAM to complement. I typically use default configurations on my relays but I feel that to get the most out of this one I'll need to do some configuration to tweak it. Does anyone have advice on getting the most out of this server, in terms of speed? Thanks

10 14

90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 14 Aug '16

14 Aug '16

RFC-5961 CVE-2016-5696 http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… FYI all

5 4

How to exclude a CDN ?
by Toralf Förster 13 Aug '16

13 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Got few times an informal report containing something like: It is most likely the attack traffic is directed at one of the following endpoints: account.sonyentertainmentnetwork.com auth.np.ac.playstation.net auth.api.sonyentertainmentnetwork.com auth.api.np.ac.playstation.net I was just wondering how would somebody handle a request to exclude those IP addresses, b/c 2 attempts to get the affected netwrok gives: # host account.sonyentertainmentnetwork.com account.sonyentertainmentnetwork.com is an alias for account.sonyentertainmentnetwork.com.edgekey.net. account.sonyentertainmentnetwork.com.edgekey.net is an alias for e380.b.akamaiedge.net. e380.b.akamaiedge.net has address 104.109.72.158 # whois 104.109.72.158 | grep CIDR CIDR: 104.64.0.0/10 CIDR: 104.109.64.0/20 and at another system : ~/devel/wireshark $ host account.sonyentertainmentnetwork.com account.sonyentertainmentnetwork.com is an alias for account.sonyentertainmentnetwork.com.edgekey.net. account.sonyentertainmentnetwork.com.edgekey.net is an alias for e380.b.akamaiedge.net. e380.b.akamaiedge.net has address 184.24.193.168 $ whois 184.24.193.168 | grep CIDR CIDR: 184.24.0.0/13 CIDR: 184.24.192.0/20 - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAleqBwUACgkQxOrN3gB26U7YXQD+PHgO8nVRo01abzdu1P7zC6TZ gDMkb+L51zt/k7hBJOsA/0czdSd8p8AnINKx+FP2Gi5ZSjVzzBuUM9o+htw5BdIX =Tz+I -----END PGP SIGNATURE-----

4 5

Re: [tor-relays] 90% of exits vulnerable to TCP off-path attack
by starlight.2016q3＠binnacle.cx 13 Aug '16

13 Aug '16

At 12:01 8/12/2016 -0400, Zack Weinberg wrote: >Also, if you read the paper, raising the global rate limit (as >suggested by the reg. article) doesn't help; it only slows the >attacker down a little. The paper indicates that a global counter limit other than 100 can be easily discovered. However the recommended mitigation effectively removes the global counter by setting it to 10^9. The described attack requires the counter be exhausted inside the temporal bounds of one second and the Internet as it exists today cannot support 10^9 probes on that deadline. IMO the recommended mitigation is effective and should be applied by those believing RFC-5961-as-presently- implemented changes worse than the weaknesses addressed by the RFC. I applied the mitigation.

2 1