[tor-relays] Choosing to run vanilla or obfuscated bridge
I know that vanilla bridges cannot carry obfsproxy traffic. But can obfsproxied bridges carry vanilla traffic? If not, are there criteria to help me decide which bridge configuration is useful at any particular time? - eliaz ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] exit relay not utilising full capacity (even after months)
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 r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@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 pgpGOs4mGIpVy.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit relay not utilising full capacity (even after months)
On 2014-10-29 09:41, Rejo Zenger wrote: [..] - 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. Note that LXC likely does not give you the security properties that you expect. issue this in your container to shutdown the host: echo b /proc/sysrq-trigger There is a bug open on this: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/645625 - 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. There are some weird properties in trying to do full-bandwidth. Deterministic it for sure is not. The IP is not mentioned in atlas: https://atlas.torproject.org/#search/94.142.240.243 Nor in: https://torstatus.blutmagie.de/ Though there is: https://torstatus.blutmagie.de/router_detail.php?FP=aa0d167e03e298f9a8cd50f448b81fbd7fa80d56 https://atlas.torproject.org/#details/AA0D167E03E298F9A8CD50F448B81FBD7FA80D56 Is Tor 0.2.5.9-rc not outdated? You might be missing some features there. I see similar issues with other nodes btw, eg: https://atlas.torproject.org/#details/BDB26EF60A419089CA3AA0891AF1681455285D48 Though that is not an exit, which gives it a completely different metric. Are you also sure that coloclue likes you playing exit? (I can only assume so ;) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] minimal specifications for a non-exit relay?
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.la...@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é ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit relay not utilising full capacity (even after months)
++ 29/10/14 10:15 +0100 - Jeroen Massar: There are some weird properties in trying to do full-bandwidth. Deterministic it for sure is not. The IP is not mentioned in atlas: https://atlas.torproject.org/#search/94.142.240.243 Nope. That is the IP-address of the switch in front of the node. The IP-address of the node is 94.142.245.231. The fingerprint is, as you have figured out already, AA0D167E03E298F9A8CD50F448B81FBD7FA80D56. Is Tor 0.2.5.9-rc not outdated? You might be missing some features there. Fixed. It's now running 0.2.5.10. Are you also sure that coloclue likes you playing exit? (I can only assume so ;) Yes. Anyway, I can't explain i) why the node was picking up speed so fast during April, both before and after Heartbleed and why it is so slow picking up speed in mid-July and 2) why there is a sudden drop in traffic since Friday. As said before, I don't have the time (and lacking expertise to do this efficiently) to investigate these issues. If anyone else is interested, I am more than happy to help - of course. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@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 pgplcMEtZhCgs.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How many IOERRORs are common ?
On 10/28/2014 08:56 PM, Mike Patton wrote: My exit isn't the size of yours but at times has supported quite a bit of traffic and I haven't ever seen one of these errors. Well, I'm running 0.2.5.10 at a 64 bit Gentoo hardened Linux in the meanwhile - unfortunately I did not looked before at these thing when I upgraded Tor and hardened Gentoo - so I do not have nothing to compare. -- Toralf pgp key: 0076 E94E ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How many IOERRORs are common ?
On 10/29/2014 05:09 PM, eric gisse wrote: I have never seen such errors and I'm running on 64 bit gentoo hardened as well. Are you running with special debug options or something? No, I just switched from an amd64 Gentoo to a hardened by switching the Gentoo profile and compiling current kernel with Grsec-Automatic-Security. -- Toralf pgp key: 0076 E94E ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
On Freitag, 24. Oktober 2014, 09:16:49 Tom van der Woerdt wrote: Manuel Gebauer schreef op 19/10/14 15:29: Hi, Tom and Rejo. Same with me. Half of the abuse complaints I get are from Valuehost Ru. Because I run on a cheap VPS I don't get a reassigned IP. Therefore I always fear that my provider might lose patience and shut down my server. That's why I decided to block Valuehost's range 217.112.34.0/24 completely. I also wrote to Valuehost Ru and asked them politely to consider that their own customers might like to use tor and to reconsider their policy for abuse complaints. No answer yet. I think they have an automated abuse complaint system and don't care much for replies. Cheers, M. So I tried getting in contact with them again in an attempt to reduce the amount of abuse mails they send us. This time they replied : - Hello, We make abuse notices not only for TOR exit node operators, we make it to their uplinks too. If we will stop to do it, it will lead for: - TOR exit node operators will cease to think to solve this serious problem (with all due respect to noble purposes of TOR, like censorship resistance for Chinese dissidents etc., we see that a large part of of TOR traffic is malicious) - TOR exit node uplinks will not notified about malicious activity in their networks Also, if we'll except over 1000 IP's of Tor exit nodes from the security system, it will be spent too many resources. So we suggest to ignore abuse messages if you don't care about the safety of Internet. - Tom Sounds quite nice to me :) -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN
Re: [tor-relays] Choosing to run vanilla or obfuscated bridge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hey, as far as i know a bridge can carry both, normal vanilla traffic and obfsproxied traffic. you specify your normal ORPort to listen e.g. on port 443 and specify a different port for obfsproxy traffic. if you specify your obfsproxy as ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed the port for obfs3 is randomly chosen at first start. Regards Andreas Am 29.10.2014 um 09:20 schrieb eliaz: I know that vanilla bridges cannot carry obfsproxy traffic. But can obfsproxied bridges carry vanilla traffic? If not, are there criteria to help me decide which bridge configuration is useful at any particular time? - eliaz ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUUWKjAAoJEIQyuRD08qdahvAP/12X+V9myaIBYbSPRQrbfWYC q2Bx2p3QmWa4Gzapy5Be+OYfNS/6VnzwiizQLgz5lgU9DrCZ2jzWX7WFxyjFRUkh w0+akvYu5pSLpq0/tJAH38m2VlXgqxNVOOWCdGs7/a93btVe2nhL/9BAweEhq4vi T2cIyUH60ptwZvsABaH0zvfHcCfRJPiESvnWqjEIX2sM9sswXyTmTOdjfwe50SEl P8+K1HGNQmBiaeq5cBxNYtSWWzWFOFeRHYuGlc4yEjEyLhQLoDXGR306HD6lntJy rG5ao68rb+4WhxJBuv2gyMxRjIweagHZzuxsfKbZce1XfGM8vgewWhE2huWxlrUy MC77OgVVuuy3B4aPAO/vszGRH09IDcXGWO8vAsrsRegn+gW2R5qowCpSDA2XI7F2 ZMu/mGN2+Jk6eZ+JJdqaLcc18mpHK9DTEQYTxOkBjV4iRIjb4AZpx+L8nZIOGmL9 f6MYJ+lp4znHksjn2BL/8nSc6Yz+QGIRQ6Cw0HwvAmUFSP8B+k1+PeIz9CJJS4NO ANdmDIdGc95ir2tdP0ng+iKJuwnE9kMDltHwv8dfRabqyz0Xq1cixyP4+EDZcqxF siZBvfUy5KM+rFEz97eJqOI09r+0Ak4hEip9lFcBJ8JeA3tWoLOaPhKjOOEQeCvq mA80zUMmzc0y3dMm7Fes =SG5C -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Choosing to run vanilla or obfuscated bridge
On Wed, Oct 29, 2014 at 08:20:15AM +, eliaz wrote: I know that vanilla bridges cannot carry obfsproxy traffic. But can obfsproxied bridges carry vanilla traffic? If not, are there criteria to help me decide which bridge configuration is useful at any particular time? - eliaz Hi eliaz, As a followup to Andreas message, vanilla bridges (only setting the torrc Bridge line) will only speak and look like the Tor protocol on the wire. Pluggable transports usually sit directly in front of Tor and transform the Tor-protocol-looking-data into whatever the pluggable transport creates. At this point, Tor only speaks the Tor protocol and each pluggable transport only speak their specific protocols. Each component does what it does best. So, to answer your question, only Obfsproxy understands the obfuscated protocols (obfs2, obfs3, scramblesuit) and Tor understands Tor. If you are thinking about running a bridge then it would be awesome if you can run a bridge and run the pluggable transports[0]. And, if your brave, you can also try running the new Obfs4proxy[1] pluggable transport. Does this make sense? Let us know if you have any more questions. - Matt [0] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#instructions [1] https://lists.torproject.org/pipermail/tor-relays/2014-September/005372.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
