- tor-relays - lists.torproject.org

AccountingMax 48 GBytes is not working
by Artur Pędziwilk 20 Oct '17

20 Oct '17

Hi Tor operators, I have relay with AccountingMax 48 GBytes AccountingStart day 09:00 MaxMemInQueues 512 ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed The accounting seems stopped working since upgrade to tor-0.3.0.10 or enabling obfs4proxy. I am not fully sure, what do you think? https://atlas.torproject.org/#details/DFBF5EA4F70DC6639156BB71593F2A2E8FDA8… Oct 16 09:00:00 venator Tor[3519]: Configured hibernation. This interval began at 2017-10-16 09:00:00; the scheduled wake-up time was 2017-10-16 09:00:00; we expect to exhaust our quota for this interval around 2017-10-17 09:00:00; the next interval begins at 2017-10-17 09:00:00 (all times local) Oct 16 09:00:00 venator Tor[3519]: Hibernation period ended. Resuming normal activity. Oct 16 09:00:00 venator Tor[3519]: Opening Directory listener on 45.76.39.74:8080 Oct 16 09:00:00 venator Tor[3519]: Opening OR listener on 45.76.39.74:9090 Oct 16 09:00:00 venator Tor[3519]: Opening Extended OR listener on 45.76.39.74:46396 Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 0:46 hours, with 11 circuits open. I've sent 192.00 GB and received 192.01 GB. Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. Oct 16 09:46:11 venator Tor[3519]: Average packaged cell fullness: 12.851%. TLS write overhead: 2% Oct 16 09:46:11 venator Tor[3519]: Circuit handshake stats since last time: 12/12 TAP, 66/66 NTor. Oct 16 09:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 35405 v4 connections; and received 16 v1 connections, 17 v2 connections, 1 v3 connections, and 29675 v4 connections. Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Oct 16 14:45:07 venator Tor[3519]: Going dormant. Blowing away remaining connections. Oct 16 15:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 6:46 hours, with 0 circuits open. I've sent 239.99 GB and received 239.98 GB. We are currently hibernating. Oct 16 15:46:11 venator Tor[3519]: Circuit handshake stats since last time: 27077/27077 TAP, 747536/747536 NTor. Oct 16 15:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 44017 v4 connections; and received 17 v1 connections, 22 v2 connections, 2 v3 connections, and 37042 v4 connections.

5 7

my relay 'alnsn' died
by Alexander Nasonov 19 Oct '17

19 Oct '17

B9A41AD7AE8B2A4E6DE96EE77E3C8C04BADA8AC0 is currently down because harware died this morning. I will either reinstall it or move to a different AS. In any case, it won't happen tomorrow. I hope to have it up and running on the weekend. Master key is safe because it's on a different machine. Alex

2 1

atlas.cogentco.com Is blocking
by Paul Templeton 19 Oct '17

19 Oct '17

Has anyone come across a scenario where a carrier blocks IP traffic? atlas.cogentco.com is the point which drops any packet to 95.130.9.210 The server is up and running internal monitoring says its OK. The ISP doesn't provide an interface to the Server so I can not log on to do any other validating. Trace routes to any IP with the ISP (active or not)terminates in the ISP's network. Trace route from any point on the planet times out as soon as you hit atlas.cogentco.com Any thoughts... **IPonU could you ping from one of your servers at Digicube please and let me know. Paul

3 4

Is AboveClouds still active?
by Ralph Seichter 19 Oct '17

19 Oct '17

Does anybody here know if AboveClouds https://aboveclouds.co.uk is still in business? Emails sent to their support address have been unanswered for a month now. -Ralph

1 0

"Bug: Duplicate call to circuit_mark_for_close"
by tor 19 Oct '17

19 Oct '17

Hi, I'm troubleshooting a Linux relay where the Tor service is having problems. External monitoring alerts indicate both the ORPort and DirPort are unreachable (TCP connection timeout). I can ssh in and the Tor service is still running. The node seems to have increased memory usage at this point but there's no evidence of OOM. I restart the Tor service, monitoring says all is good again, and things seem fine for a bit, until the cycle repeats hours later. I'm still investigating, but one thing I immediately noticed was hundreds of these lines in the logs: [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/or/onion.c:238 (first at ../src/or/command.c:579) (on Tor 0.2.9.11 ) I found https://trac.torproject.org/projects/tor/ticket/20059 but it's marked as fixed with a backport to 0.2.9. Any thoughts?

4 9

vsif.ca relays: MyFamily configuration
by nusenu 18 Oct '17

18 Oct '17

Hello Vancouver Society for Internet Freedom, thanks for running tor relays. Unfortunately you are in a position that can potentially harm tor users if you do not set MyFamily (torrc) on all your relays. Please have a look at your MyFamily configuration. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#vsif-suppor… You are also running an outdated version of tor that is no longer recommended: https://atlas.torproject.org/#search/vsif%20version:0.2.9.10 some more background: https://hackernoon.com/some-tor-relays-you-might-want-to-avoid-5901597ad821 Let us know if you need help with configuring MyFamily. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Used TLS implementations by relays
by nusenu 15 Oct '17

15 Oct '17

Hi, are there any TLS libraries other than - openssl - libressl that are actively used by current tor relays? https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Overview thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

1 0

Hashed password behaviour
by Geoff Down 15 Oct '17

15 Oct '17

Hello all, what sort of crazy bug would make Tor give different hashes for the same password? $ tor --hash-password hello 16:735E6FA5355D4146606AFE25B61B411DF419878C99705164D038FC99BC $ tor --hash-password hello 16:8201E7D35BB8CACB60BF8947B49A3480BA1A17E77EDA8BE45790746884 $ tor --version Tor version 0.3.1.7 (git-6babd3d9ba9318b3). (on OSX 10.4). GD

3 5

Using ContactInfo to publish additional relay properties in a standardized way (opt-in)
by nusenu 15 Oct '17

15 Oct '17

Status: WIP please send your comments until 2017-10-27 I'm writing this with the following motivation: - make it easier for current and future relay operators to find (rarely used) hosters for tor relays by increasing the information sharing between relay operators. -> help the tor network grow - improve geo- and autonomous system diversity on the tor network (more diverse is better) - collect additional (self-reported) relay metrics (for things like atlas [1] and OrNetStats [2]) https://atlas.torproject.org https://nusenu.github.io/OrNetStats exmples: How many - use tor's Sandbox? - run in OfflineMasterMode? - make use of KIST? - do auto-updates? This data could provide tor developers with information on how well tested/how much used new features (like Sandboxes) are before changing defaults. - improve the ability to contact relay operators (automatically) - make provided information machine readable - provide the foundation for an automated contactInfo verification bot mutually verified email addresses (and other contact options) could be displayed differently on atlas.torproject.org - make t-shirt delivery easier since contact information is potentially already verified - increase the ability to detect undeclared relay groups / make hiding relay groups harder - make hosting costs visible - potentially detect relay operators impersonating other operators by using their email address Should 10% cw fraction and at least 50 operators use any of the defined fields I'll ask irl (atlas maintainer) to get that specific field added to atlas (separately from the contactinfo string). Example ContactInfo String -------------------------- email:user[]example-operator.com hoster:https://example-hoster.com uplinkbw:100 trafficacct:unmetered cost:10 virtualization:xen Considerations ---------------- - increases exposure of relay operators The machine readable information could be used by spammers and to target relay operators. Operators concerned about this can omit contact information but it should not be hard to create a new email address for the purpose. - more information makes targeted exploitation easier / more silent Attackers could use the additional information provided in these fields to specifically target only vulnerable systems. Operators concerned about sharing configuration information should omit this type of information, but can share other information. - increased descriptor size and directory traffic The contactinfo field size could potentially grow because of this specification. This should be mitigated with the use of directory data compression and diffs available since tor 0.3.1. - ContactInfo size constraints According to the manual [2] there is no explicit ContactInfo size limit but there is a descriptor size limit. The max. descriptor size is 20000 bytes [3]. The family size and exit policy are two other relevant inputs. [2] https://www.torproject.org/docs/tor-manual.html.en#ContactInfo [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364 List of information fields ---------------------------- I started to collect possible fields here: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification#de… looking forward to your feedback, nusenu Document location: https://github.com/nusenu/ContactInfo-Information-Shareing-Specification -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

Relay DDoS attack?
by Peter Rogers 14 Oct '17

14 Oct '17

Hi! I've been running a Tor non-exit node at my business for a few months now. So far it's been great! Except yesterday when I noticed my internet was at a crawl. I traced the problem back to a large number of inbound connections that completely overwhelmed my little router. (4096 connections, the configured limit) All the connections were being made to my tor relay from outside IPs. The tor log file was filling with this: Oct 13 14:21:29.000 [warn] assign_to_cpuworker failed. Ignoring. Oct 13 14:21:29.000 [warn] assign_to_cpuworker failed. Ignoring. Oct 13 14:21:30.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [1779 similar message(s) suppressed in last 60 seconds] I shutdown the relay, then eventually disconnected my internal network from the router hoping the traffic would slow. It continued for maybe another 2-3 hours until I finally unplugged the router and left for the weekend. I was able to capture some of the traffic and found most of it originated from other tor (non-exit) relay nodes. In a 5 minute sample there was some 170,000 syn packets sent by some 4000+ unique IPs. I used a script to check the collected IPs against the list of known tor nodes and they're almost all tor (non-exit) relays. Hopefully it auto-fixes itself when I'm back at work Monday morning. But mostly I'm curious to know what's going on. Anybody encounter a situation like this?

2 1