- tor-relays - lists.torproject.org

Nokia n900 relay
by Franklin 02 Oct '14

02 Oct '14

Hi How to setup relay address on nokia n900?

2 1

Scramblesuit
by Jan Nielsen 02 Oct '14

02 Oct '14

Hi. I am trying to enable Scramblesuit for my bridge. I am wondering if there is a method to verify that it is working, similar to how obfs3 shows "registered server transport". There is not much out there about scramblesuit but there is one mention that the log should show " registered server transport scramble suit". Tor version is 0.2.5.8-rc Obfsproxy version 0.2.12 ExtORPort auto ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed Oct 01 03:03:28.000 [notice] Registered server transport 'obfs3' at ' 0.0.0.0:39491' Is there something wrong with my config? Thank you.

3 4

Failed to load Scramblesuit
by Christian 01 Oct '14

01 Oct '14

Dear fellows, maybe you can help out. And maybe I missed some information on my Tor version. I run an obfuscated bridge (Tor 0.2.5.8-rc (git-eaa9ca1011e73a9d)) on Ubuntu 12.04 and wanted to enable the scramblesuit pluggable transport. When changing my line in torrc to ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed I get the following warning in the logs: [warn] The communication stream of managed proxy '/usr/bin/obfsproxy' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. [notice] Failed to terminate process with PID '18171' ('Success'). Obfs3-only works like a charm without complaints. (ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed) I set my ExtORPort to "auto", pyptlib is installed, packages from obfsproxy and pyptlib are in the right locations and I use the shipped apparmor profile for Tor for Ubuntus. Even if I stop apparmor service, I don't get better results. I thought it was a permissions problem somehow as --log-min-severity=debug --log-file=/home/me/obfs.log won't even create the logfile so that obfsproxy fails from the very beginning. But, as I said, obfs3-only works without problems. Any ideas? Thank you in advance. Kind regards christian

2 1

Bandwidth not being used by Tor on Gigabit dedicated server
by Jon Daniels 01 Oct '14

01 Oct '14

Hi, My Tor node is not utilizing the bandwidth available to it. I have tried setting RelayBandwidthRate to various values with no change whatsoever in bandwidth usage. Running for 5 months with 99.77% uptime: https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C806E6FDA4… My node has used a maximum of about 4MB/s or about 40Mbps. I've been expecting it to use 10MB/sec to 30 MB/sec. It dropped from 4MB/sec to around 1MB/sec now. OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL RAM: 8GB Network connection: 1000Mbps Bandwidth tests show the server can easily send or receive hundreds of Mbps. I have tweaked server settings trying to get the speed up to no avail. Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. Relevant config: DirPort 9030 # what port to advertise for directory connections RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s (1600Kbps) DisableDebuggerAttachment 0 ORPort 443 ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* In addition, there's another Tor node running at the same ISP (but by a different person), on completely different hardware and a different router, that exhibits the same issue: https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB0442E900FB… For background, I built and manage the network both servers are hosted on and have been doing so for 20 years. I also built both servers. The network is at less than 15% capacity, 99% of the time. CPU load is always at 0.00. Based in the USA, west coast. Ideas? Is there simply less demand for tor traffic in the US? Cheers, Jon

4 4

tor-relays mailing list submissions
by top mail 01 Oct '14

01 Oct '14

tor-relays mailing list submissions

1 0

tor-relays
by top mail 01 Oct '14

01 Oct '14

tor-relays

1 0

Loki1 and Loki2 closed
by jason＠icetor.is 30 Sep '14

30 Sep '14

Hey fellow ops, Just an FYI today that Icetor lost two of it's fastest two exits that were hosted with Greenqloud here in Iceland, obviously would not recommend them as an ISP in the future regarding exit hosting. About two weeks ago we got notification that abuse notices were breaking their EULA and would be the reason for the termination. Today they shut down the nodes about 5 hours earlier than indicated, no ability to do data migration or save keys. Needless to say I'm not very happy with the entire situation and how it was handled. We'll soldier on with our remaining two exits and ifanyone is thinking of spinning up an exit in the future Icetor is still able to handle abuse contact for the relay. -Jason

1 0

Oniontip
by justaguy 30 Sep '14

30 Sep '14

So, https://oniontip.com is a great help for tor-relay runners We do need more donations imho Whoever made it, thank you - Justaguy

10 15

[warn] No unused circIDs found on channel without wide circID support
by tor-admin 29 Sep '14

29 Sep '14

Hi, since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this something to worry about? Regards, torland -------------------------------------------------------------------------- Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs in use by circuits, and 64 with pending destroy cells. (0 of those were marked bogusly.) The ones with pending destroy cells have been marked unusable for an average of 7594 seconds and a maximum of 16137 seconds. This channel is 18469 seconds old. Failing a circuit. Sep 28 16:07:24.000 [warn] Circuitmux on this channel has 4 circuits, of which 4 are active. It says it has 29535 destroy cells queued. Sep 28 16:07:24.000 [warn] Channel 93320 (at 0x7fbff4579d90) with transport TLS channel (connection 3245390) is in state open (2) Sep 28 16:07:24.000 [warn] * Channel 93320 was created at 1411894775 (18469 seconds ago) and last active at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 says it is connected to an OR with digest 4C733BAC82CC609ACC58AD95BFBFF04D5D06188C and no known nickname Sep 28 16:07:24.000 [warn] * Channel 93320 says its remote address is [scrubbed], and gives a canonical description of "[scrubbed]" and an actual description of "[scrubbed]" Sep 28 16:07:24.000 [warn] * Channel 93320 has these marks: !bad_for_new_circs canonical is_canonical_is_reliable !client !local outgoing Sep 28 16:07:24.000 [warn] * Channel 93320 has 0 queued incoming cells and 0 queued outgoing cells Sep 28 16:07:24.000 [warn] * Channel 93320 has 4 active circuits out of 4 in total Sep 28 16:07:24.000 [warn] * Channel 93320 was last used by a client at 0 (1411913244 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 was last drained at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last received a cell at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last transmitted a cell at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 has received 234 cells and transmitted 2497 Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 78.927350 seconds between received cells Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 7.396476 seconds between transmitted cells Sep 28 16:07:24.000 [warn] failed to get unique circID

2 1

Oniontip
by Sebastian Urbach 28 Sep '14

28 Sep '14

Hi, Mike, your questions are all valid. Remember where this project is coming from. Donncha put this together at the Dublin Bitcoin Hackathon and it was designed to give back a little bit to the Relay Operators. I never expected anything in return for my relays but im glad that onintip exists and the approach seems to be to give everybody a little bit back based on the consensus. Exit operators can get a lot of legal trouble and i acknowledge that but without Middle Relays, Guards, Bridges etc. TOR would not be possible. It seems to be always about the Exit's. There are different organizations for Exit's and now they should be preferred on oniontip.com ? It is hard not to feel like a second class Relay operator when you don't run an Exit. Im happy that there is a possibility like oniontip and btw. there is nothing similar on the torproject website. You can donate to the torproject via bitcoin but there is no way to choose who should receive this donation like you can do on oniontip.com Im not sure if it is necessary for oniontip to provide the best possible distribution of the donations from the projects point of view (diversity etc.) It seems to be a different approach just to give back to everybody and it has a certain amount of charme. It is easy to use and it seems to be working and becoming more and more popular. I like it. -- 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! -----------------------------------------

3 2