- tor-relays - lists.torproject.org

exit relay not utilising full capacity (even after months)
by Rejo Zenger 29 Oct '14

29 Oct '14

Hi, I am running an exit-relay and noticed a couple of odd things: 1. Last months, the node seems to be slow in using the full capacity. - Back in April, I changed the relay's configuration to allow the relay to use all the bandwidth it could take. As a result, within a week or two the bandwidth consumption went up to 50 Mbps. In the months of May to July, I had to limit the capacity of the node again. Mid-July I reverted to the same configuration from April. However, the node was a lot slower to pick up the full capacity. [1] - So, the question is: why is it so much slower maximising the full bandwidth? The configuration from mid-July onwards is identical to the one in April. The only thing that has changed is in mid-August, when I moved to relay into a LXC container. However, that doesn't explain the slow pickup in mid-July to mid-August. - And yes, I am aware of the Roger's blogpost. That does explain why the node may be slow to pick up traffic, but it doesn't explain why it was a lot faster in doing so in April then in mid-July. 2. Since Friday there is a considerable drop in the traffic. - Last Friday, around 23:00 hours CET the traffic dropped to about a third of it's usage the days before. Since then, there have been some increase from time to time, but the average is still half or even less than before Friday. There was no change in configuration. I don't have the time to investigate these issues myself. However, if someone wants to look into this, let me know and I am more than happy to provide the details needed. [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-year.png [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-week.png -- Rejo Zenger E rejo(a)zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo(a)zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF

2 2

minimal specifications for a non-exit relay?
by René Ladan 29 Oct '14

29 Oct '14

Hi, I was running a non-exit relay from my 50/5 Mb/s (more like 35/4 in practice) home connection on a Raspberry Pi B (496 MB RAM, 700 MHz) running FreeBSD using the following configuration: Tor 0.2.4.24 % cat /usr/local/etc/tor/torrc SocksPort 0 Log notice file /var/log/tor ORPort 9001 ORPort [2001:980:d7ed:1:ba27:ebff:fe96:9eb2]:9001 Nickname ymkeo RelayBandwidthRate 500 KB RelayBandwidthBurst 500 KB ContactInfo Rene <r.c.ladan(a)gmail.com> DirPort 9030 ExitPolicy reject *:* ExitPolicy reject6 *:* This seemed to be fine until last night the socket connection pull ran over, so I increased the value from 128 to 32768 (kern.ipc.somaxconn) Things mostly seemed to be fine again until the kernel ran out of resources later last night: ==> /var/log/tor <== [warn] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 148 buildtimes. ... Oct 29 00:28:44.000 [notice] Performing bandwidth self-test...done. ==> /var/log/messages <== Oct 29 01:15:35 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:15:35 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:16:30 raspberry-pi last message repeated 36 times Oct 29 01:18:31 raspberry-pi last message repeated 1094 times Oct 29 01:19:30 raspberry-pi last message repeated 450 times Oct 29 01:19:30 raspberry-pi kernel: smsc0: warning: Failed to write register 0x114 Oct 29 01:19:35 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:20:07 raspberry-pi last message repeated 157 times Oct 29 01:20:50 raspberry-pi last message repeated 234 times Oct 29 01:20:50 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:20:52 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:21:37 raspberry-pi last message repeated 216 times Oct 29 01:22:31 raspberry-pi last message repeated 558 times Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: Failed to read register 0x114 Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: MII is busy Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: failed to create new mbuf ==> /var/log/tor <== Oct 29 01:22:32.000 [warn] Your system clock just jumped 332 seconds forward; assuming established circuits no longer work. Oct 29 01:22:32.000 [warn] Your system clock just jumped 332 seconds forward; assuming established circuits no longer work. ==> /var/log/messages <== Oct 29 01:23:12 raspberry-pi last message repeated 10 times Oct 29 01:25:13 raspberry-pi last message repeated 855 times Oct 29 01:25:51 raspberry-pi last message repeated 123 times Oct 29 01:25:51 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:25:51 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:26:21 raspberry-pi last message repeated 222 times Oct 29 01:28:21 raspberry-pi last message repeated 279 times Write failed: Broken pipe <-- local SSH connection dropped It might be a matter of further tuning as ticket #9708 and the new doc/TUNING suggest, once I log in at its console. But if a Raspberry Pi is structurally underpowered (I don't imagine relaying at fiber speed on them ;) ) shouldn't there be something on the homepage or FAQ about this? I have seen at least one blog from someone running a relay on a Raspberry Pi with Debian Linux. Regards, René

1 0

RPM for Tor 0.2.5.10 updated with Curve25519 reenabled
by Ondrej Mikle 28 Oct '14

28 Oct '14

Hi, when switching RPMs from 0.2.4.x to 0.2.5.x branch I forgot to merge re-enabling of Curve25519 (it was a historic artifact of EL5 workarounds). RPM packages of 0.2.5.10 with Curve25519 reenabled are now uploaded and should get to you shortly. Ondrej

2 2

How many IOERRORs are common ?
by Toralf Förster 28 Oct '14

28 Oct '14

Watching the status of a tor-relay (4 MB bandwith, guard + exit, having more than open 1000 connections) with arm shows a rather high frequent amount of connection errors. Nearly every seconds or so a connection can't be established. /me just wonders if this is common (replaced ip addresses with <XXXXXX>) │ 19:22:17 [ORCONN] STATUS: CONNECTED ENDPOINT: $822E5F038D5FE387FC0CDE5DF209ABBD947FD485~Ololosha │ 19:22:17 [ORCONN] STATUS: CLOSED ENDPOINT: $C29E64C8988A06B4CF67673C7A4B94F5392F03F5~default REASON: IOERROR │ 19:22:17 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:49631 │ 19:22:17 [ORCONN] STATUS: CLOSED ENDPOINT: $6B939266A97973428AA9224CCFD2F6A38AB49745~BaboxTelecom REASON: IOERROR │ 19:22:17 [ORCONN] STATUS: CONNECTED ENDPOINT: $99B72A7C0980DEAA922B4E3BA576E95E03F558EB~RiotRelay │ 19:22:17 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:57447 │ 19:22:16 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:55347 │ 19:22:16 [ORCONN] STATUS: CLOSED ENDPOINT: $8260ADE00B93448C9CE35780BDBA742AC5E91256~McBoobies REASON: IOERROR │ 19:22:16 [ORCONN] STATUS: CLOSED ENDPOINT: $702491F10EFBE6412F6E93E883F1F586839996F8~1tornetpw REASON: IOERROR │ 19:22:15 [ORCONN] STATUS: CONNECTED ENDPOINT: $A4F3A9B0C54EAB665EA00406CEFBCBE7CB9A0138~bygkjynfyn │ 19:22:14 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:47531 │ 19:22:14 [ORCONN] STATUS: CLOSED ENDPOINT: $1337C0053C46F16F6344426029F58870017B24F9~Unnamed REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: <XXXXXX>:55608 │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $D90B107A1907302E43A6A4E6C851A3AA0B42F094~digitaldoge REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $72534C95CFB55F91B764421A1EFFEB421519DE2F~allyourbase REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:55608 │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $BD0D574F70708E96618492E31F516037E857FC39~wazong REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $D369D86310CBC8FFBE064940B55458C754F1B03C~Kyat1 REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: $039003C320D9980E0A740F107A1A9C13C99C5FE3~ry4an │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: $5E184FEA02B7C54172BBC757636F501047CF9691~pook0oow │ 19:22:12 [ORCONN] STATUS: LAUNCHED ENDPOINT: $5E184FEA02B7C54172BBC757636F501047CF9691~pook0oow │ 19:22:12 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:35274 │ 19:22:12 [ORCONN] STATUS: CLOSED ENDPOINT: $64186650FFE4469EBBE52B644AE543864D32F43C~PsychoOnion3 REASON: DONE ─┘ -- Toralf pgp key: 0076 E94E

1 0

My VPS relay has just been hacked
by Nick Sheppard 27 Oct '14

27 Oct '14

For the last month I've been running a middle relay (no guard flag yet) on a 512 MB VPS provided by Edis.at in Switzerland (4.99 euro per month). The software is Tor 0.2.5.8-rc with obfsproxy 2 and 3 running on up-to-date Debian Wheezy 7.6. I left the iptables at their defaults. Last night Edis suspended my VPS because of a suspected outgoing DDoS attack, and emailed me. I rang their (very helpful) phone support in London and they de-suspended the VPS so I could ssh into it and investigate. ( I told them it was running a tor non-exit relay - that wasn't a problem.) Sure enough the Solus control panel traffic graphs show the tor relay traffic stopping abruptly last night, followed about 40 minutes later by an exponentially increasing spike of outgoing traffic, soon cut off when the VPS was suspended. I ssh'd into the VPS ("last login" showed my own last login, so no problem there) and looked at logs and top. notices.log simply cut off when the tor traffic stopped, but showed nothing unusual before that. The Solus control panel traffic graph started showing (a very small amount of) outgoing traffic as soon as the VPS was de-suspended, so I assumed the malware was still active, and used top. This is typical of what I found. 1 root 20 0 10604 832 700 S ... 0:00.10 init 2 root 20 0 0 0 0 S ... 0:00.00 kthreadd/3277 3 root 20 0 0 0 0 S ... 0:00.00 khelper/3277 1370 root 20 0 36976 660 492 S ... 0:00.38 hxyqbutesc 1400 root 20 0 109m 1616 1188 S ... 0:00.00 rsyslogd 1446 root 20 0 18836 884 680 S ... 0:00.00 cron 1473 root 20 0 49888 1212 608 S ... 0:00.00 sshd 3187 root 20 0 27556 744 504 S ... 0:00.00 vzctl 3188 root 20 0 17808 1968 1500 S ... 0:00.00 bash 5374 root 20 0 21584 1416 1072 R ... 0:00.00 top 5440 root 20 0 6244 536 296 S ... 0:00.00 akcviaxtbl 5443 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl 5446 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl 5448 root 20 0 6244 536 300 S ... 0:00.00 akcviaxtbl 5449 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl There is a strange line near the top for process "hxyqbutesc", which didn't change; and a strange block of lines at the bottom, which changed every second or two. Sometimes it was five similar lines, as above; sometimes it was several block of lines, eg this: 5276 root 20 0 6244 528 292 S 0.0 0.1 0:00.00 qscntoweqb 5277 root 20 0 6244 536 300 S 0.0 0.1 0:00.00 qscntoweqb 5280 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 qscntoweqb 5282 root 20 0 6244 536 300 S 0.0 0.1 0:00.00 qscntoweqb 5283 root 20 0 6244 528 292 S 0.0 0.1 0:00.00 qscntoweqb 5290 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 saqizxaihz 5294 root 20 0 6244 528 300 S 0.0 0.1 0:00.00 saqizxaihz 5295 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 saqizxaihz 5296 root 20 0 6244 524 296 S 0.0 0.1 0:00.00 saqizxaihz 5298 root 20 0 6244 528 296 S 0.0 0.1 0:00.00 saqizxaihz Each block is always 5 lines, and the names (always 10 lower-case letters) seem to be different every time. The blocks change fairly regularly every second or two. I shut the VPS down to stop it doing any more harm, but I didn't delete anything; I can restart it and ssh in again for further investigation if necessary. Eventually I'll have to reinstall everything from scratch, straightforward enough, but what can I do to make sure it doesn't happen again? Would hardening my iptables work? Has anyone else seen this? Nick Sheppard

6 7

tor-relays set on nokia n900
by Franklin 27 Oct '14

27 Oct '14

Hey all My issu not responds?

1 0

Tor 0.2.5.10 is released!
by Nick Mathewson 27 Oct '14

27 Oct '14

Hi, all! I just sent a release announcement to the tor-announce mailing list. If you're not on that mailing list, you should subscribe; it is very low-volume. https://lists.torproject.org/pipermail/tor-announce/2014-October/000096.html Synopsis: There is a new stable out. Some packages are up-to-date, more packages should be up-to-date over the next week. Usually I don't announce a stable till there are packages, but people have been asking me about this one, and I'd rather have an official release announcement than a series of weird rumors. yrs, -- Nick

8 9

Relays alongside firewall
by Jan Nielsen 26 Oct '14

26 Oct '14

Hello. I recently enabled UFW on my relays. I have allowed in all necessary ports that my relay uses. I was looking at the logs and there are plenty of blocked incoming TCP connections. These connections are being blocked because they are attempting connection on ports that I have not opened e.g. 9001. However, the traffic appears to be relay traffic. Is ufw interfering with my relay? Are there additional steps to take when running a relay alongside a firewall? Here is a redacted snippet from my ufw log: Oct 26 15:10:29 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:xx:8a:xx:64:xx:f0:xx:xx SRC=202.108.xxx.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=46331 DF PROTO=TCP SPT=49892 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 26 15:10:32 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:28:8a:1c:64:cb:xx:xx:xx SRC=202.108.xxx.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=46332 DF PROTO=TCP SPT=49892 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 26 15:15:12 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:28:8a:1c:64:cf:xx:xx:xx SRC=60.186.xx1.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=19751 DF PROTO=TCP SPT=52502 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0

1 0

Iptables dump
by Sebastian Urbach 26 Oct '14

26 Oct '14

Dear list members, I want to offer my iptables dump so that everybody who's interested can use it to fill up the firewall with the "usual suspects". My system basically runs just TOR and SSH, so it's not a big surprise that the file contains almost only ip's which attacked SSH. Iptables is fed by fail2ban and then dumped every hour iptables-save so that this collection is automatically loaded via iptables-persistent after a reboot. I will publish this file just once so that this list is not stressed too much. If there is a certain amount of interest i'm willing to offer the file for download permanently. Please contact me if you are interested in that. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running Tor
by Dan Hanley 26 Oct '14

26 Oct '14

Hi Matt I was in the unusual position where www.bbc.co.uk decided I was not UK resident (I am) and redirected me to www.bbc.com - where none of the links worked for me as that site decided I was UK resident. The BBC did make it clear that they understand Tor relays should not be an issue for them, but that they consider exits to violate their terms of service. It would seem they have stopped discriminating against relays, I doubt they'll ever be exit friendly :-( Dan > > ---------- Forwarded message ---------- > From: Matt Puckey <matt(a)puckey.org> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 25 Oct 2014 18:19:21 +0000 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > Tor > Dan Hanley: > > Looks like the BBC have changed their rules. I am still running a relay, > > but can now access www.bbc.co.uk in a normal fashion. > > > > Still blocked by national lottery, but I'm hopeful that they both use the > > same third party ip checker, and that the next lottery update will fix > the > > issue. > > Progress! > > I cried a little inside when I read, "We have asked our provider to give > us a way of differentiating Tor exit nodes from non-exit relays, to > allow us to block exit nodes only." > > Ugh. > > Did you have trouble reaching www.bbc.co.uk as well as iPlayer? That > would be strange. I haven't seen them block Tor relays & exits simply > getting to www.bbc.co.uk. > > --Matt > > > >

1 0