- tor-relays - lists.torproject.org

sum of consensus weight of 2 relays running at the same IP
by Toralf Förster 29 Oct '17

29 Oct '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I assumed that 2 Tor at the same ip address would get haöf of the consensus of the previously runnning only one Tor relay at the same hardware. But it semes, that both Tor relays get now the same value as the one before. Is this intended ? - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWfW5BRccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTse3AP9waxb9fe+ECq0QyR2PkS6Tw3j1 Lc+H7UafeeuUalHJngEAg9pg1jHzZnrEir03xCQEeP9HRrtfbKCUBo/AI/40KMo= =wt5I -----END PGP SIGNATURE-----

2 3

Testing Golang relay implementation
by Michael McLoughlin 28 Oct '17

28 Oct '17

All, I am working on a pure Golang relay implementation. https://github.com/mmcloughlin/pearl/ I have thus far been testing locally with chutney ( https://gitweb.torproject.org/chutney.git) The project is not complete by any stretch, but I believe I am close to the point where it can handle Tor network traffic. I expect I can learn *a lot* by running against real traffic rather than my sandboxed environment. I wanted to get in touch with the community before going live. Any advice gratefully received. The implementation identifies itself clearly in the server descriptor, both in the "platform" and "contact" items. If people notice any problems with the relay specifically they will be able to contact me. Thanks, Mike

9 17

Atlas / Onionoo ...
by Sebastian Urbach 27 Oct '17

27 Oct '17

Back on the road ;-) -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

2 1

decrease in traffic
by Trey Nolen 27 Oct '17

27 Oct '17

I'm new to running a Tor relay and started one about a month ago. I've got 50 Mbps dedicated to it and at first it climbed in traffic pretty steadily until it got to around 25-30 Mbps being used. Since then, it has declined steadily and is down to about 350 KBps now (yes, I'm keeping the units straight). My node is a single core VPS running 3.2GHz and with 1GB RAM. Currently, top shows tor as using about 15% of the memory. When it was churning out at the maximum rate it got to, the CPU was pretty hammered. I was considering allocating another core, but there is no need anymore as it is hovering around 7% usage. The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor. Am I doing something wrong to result in the decrease in traffic? Any advice is appreciated. Trey Nolen

6 14

"Onionoo seems to serve outdated data"
by tor 26 Oct '17

26 Oct '17

I see "Onionoo seems to serve outdated data :( Last update was: Tue Oct 24 2017" at the top of Atlas, and querying the Onionoo API directly results in the same outdated data. Anyone working on fixing it?

2 1

Balancing throughput versus getting Black-Holed
by Paul Templeton 25 Oct '17

25 Oct '17

Hi All, I have a question. I would like to know other peoples experiences for exit nodes and the methods of mitigating getting black holed. I have a node that gets black-holed all the time now - it runs at 18Mibt - 41781FDC57238DAB955DF6D6E8400CEC5ACBE706 I have noticed smaller relays/exits on the same AS don't seem to run into the same problem. I was thinking of running two to three smaller exits at around 4MiBt or just going for a larger faster middle. Thoughs/Comments. I have been emailing the provider and their carrier but know one ever responds/reply's. Paul

4 8

Re: [tor-relays] Troubleshooting rasptor4273 (was: Decline in relays)
by rasptor 4273 25 Oct '17

25 Oct '17

My IP/ORPORT is 24.132.17.230:9001. My relay is still running. arm shows traffic going through and several circuits on the connections page. And from my notices.log file: Oct 24 16:35:45.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Oct 24 16:35:45.000 [notice] Heartbeat: Tor's uptime is 6 days 0:00 hours, with 2 circuits open. I've sent 47.17 MB and received 237.75 MB. Oct 24 16:35:45.000 [notice] Average packaged cell fullness: 66.463% Oct 24 16:35:45.000 [notice] TLS write overhead: 8% Oct 24 16:35:45.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. However there's also a lot of this in that file: Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Oct 24 16:55:45.000 [warn] Your server (24.132.17.230:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. I added the log line to my torrc and sent a SIGHUP signal. Entries are being added to the log file, so that worked. Regards, Joep On Oct 23, 2017 22:59, "David Goulet" <dgoulet(a)torproject.org> wrote: On 23 Oct (22:49:55), rasptor 4273 wrote: > My relay has gone off the consensus. > Fingerprint: E7FFF8C3D5736AB87215C5DB05620103033E69C3 Interesting. And it is still running as of now without any problems? Can you give me the IP/ORPORT tuple? You think you can add this to your torrc and then HUP your relay (very importatnt to NOT restart it). Log info file <FULL_PATH_TO_LOG_FILE> And then after a some hours (maybe a day), we'll be looking for "Decided to publish new relay descriptor". If it appears, we know that your relay keeps uploading to the directory authorities so thus chances are that there is a problem on the dirauth side not finding you reachable. Thanks! David > Alias: rasptor4273 > Am running Tor 0.2.5.14 on Debian, Raspberry Pi 2B. I upgraded to that > version on September 3rd. > > I grepped through these: > https://collector.torproject.org/archive/relay-descriptors/consensuses/ and > the latest entry I found for my alias is in the file > ./17/2017-09-17-13-00-00-consensus. > > Not sure what other information I can provide. Do let me know if I can do > anything else to help troubleshoot. > > Best, > Joep > > On Mon, Oct 23, 2017 at 9:14 PM, George <george(a)queair.net> wrote: > > > David Goulet: > > > Hello everyone! > > > > > > Since July 2017, there has been a steady decline in relays from ~7k to > > now > > > ~6.5k. This is a bit unusual that is we don't see often such a steady > > behavior > > > of relays going offline (at least that I can remember...). > > > > > > It could certainly be something normal here. However, we shouldn't rule > > out a > > > bug in tor as well. The steadyness of the decline makes me a bit more > > worried > > > than usual. > > > > > > You can see the decline has started around July 2017: > > > > > > https://metrics.torproject.org/networksize.html?start= > > 2017-06-01&end=2017-10-23 > > > > > > What happened around July in terms of tor release: > > > > > > 2017-06-08 09:35:17 -0400 802d30d9b7 (tag: tor-0.3.0.8) > > > 2017-06-08 09:47:44 -0400 e14006a545 (tag: tor-0.2.5.14) > > > 2017-06-08 09:47:58 -0400 aa89500225 (tag: tor-0.2.9.11) > > > 2017-06-08 09:55:28 -0400 f833164576 (tag: tor-0.2.4.29) > > > 2017-06-08 09:55:58 -0400 21a9e5371d (tag: tor-0.2.6.12) > > > 2017-06-08 09:56:15 -0400 3db01d3b56 (tag: tor-0.2.7.8) > > > 2017-06-08 09:58:36 -0400 64ac28ef5d (tag: tor-0.2.8.14) > > > 2017-06-08 10:15:41 -0400 dc47d936d4 (tag: tor-0.3.1.3-alpha) > > > ... > > > 2017-06-29 16:56:13 -0400 fab91a290d (tag: tor-0.3.1.4-alpha) > > > 2017-06-29 17:03:23 -0400 22b3bf094e (tag: tor-0.3.0.9) > > > ... > > > 2017-08-01 11:33:36 -0400 83389502ee (tag: tor-0.3.1.5-alpha) > > > 2017-08-02 11:50:57 -0400 c33db290a9 (tag: tor-0.3.0.10) > > > > > > Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life. > > > > > > That being said, I don't have an easy way to list which relays went > > offline > > > during the decline (since July basically) to see if a common pattern > > emerges. > > > > > > So few things. First, if anyone on this list noticed that their relay > > went off > > > the consensus while still having tor running, it is a good time to > > inform this > > > thread :). > > > > > > Second, anyone could have an idea of what possibly is going on that is > > have > > > one or more theories. Even better, if you have some tooling to try to > > list > > > which relays went offline, that would be _awesome_. > > > > > > Third, knowing what was the state of packaging in > > Debian/Redhat/Ubuntu/... > > > around July could be useful. What if a package in distro X is broken and > > the > > > update have been killing the relays? Or something like that... > > > > > > Last, looking at the dirauth would be a good idea. Basically, when did > > the > > > majority switched to 030 and then 031. Starting in July, what was the > > state of > > > the dirauth version? > > > > > > Any help is very welcome! Again, this decline could be from natural > > cause but > > > for now I just don't want to rule out an issue in tor or packaging. > > > > (Replying to OP since it went OT) > > > > As some of you know, TDP did a little suite of shell scripts based on > > OONI data to look at diversity statistics: > > > > https://torbsd.github.io/oostats.html > > > > With the source here for further tinkering: > > > > https://github.com/torbsd/tdp-onion-stats/ > > > > Maybe something we could look at is "exception reports", which in some > > industries means regular reports that look at anomalies or "exceptions" > > which display out-of-the-ordinary statistics, generally prompting some > > sort of action. > > > > In other words, daily reports would be run on, say, bw consensus by > > country, and if there was some statistically significant change over N > > periods of time, it would be noted. Or if a particular OS drops or > > jumps. Or if a particular AS jumps or declines for relays, bridges, > > whatever. > > > > If done right, a bunch of these reports could point to particular > > changes to the network that need further investigation, and in some > > cases, might quickly point to the related issue. Eg, countryX shutdown > > ISP with a particular AS number, etc. > > > > The more reports coupled with careful optimization over time could > > become an alarm system for Tor network changes, instead of just "er, > > such-and-such distro didnt update their packages then, I just found out > > in git." > > > > Thoughts? > > > > g > > > > > > -- > > > > > > 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682 > > > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY= _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 2

Tor t-shirts
by Vasilis 24 Oct '17

24 Oct '17

Hello, During the last Tor meeting I asked some people about the Tor t-shirt situation and the big delays to processing and response and it seems that the situation has been resolved and person eligible for a t-shirt have either been notified or have already received them. Has everyone eligible for a Tor t-shirt got one already? Are there still people that are still waiting? Thank to everyone running/run Tor relays. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

11 17

Just got my first Abuse email :-)
by Paul Templeton 22 Oct '17

22 Oct '17

It makes me happy but alas it was forwarded to me by the provider and didn't include an email address... so now I can not reply, SIGH Question: this has come from port 22 usage - how important is this port to the general population? Thoughts... Regards, Paul

6 6

Tor 0.3.1.7 - bug report
by diffusae 21 Oct '17

21 Oct '17

This instance is running forward. Oct 21 00:44:20.989 [notice] Tor 0.3.1.7 (git-6babd3d9ba9318b3) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2j-freebsd, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.2. Oct 21 01:08:34.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Oct 21 01:08:47.000 [notice] Performing bandwidth self-test...done. Oct 21 01:09:10.000 [warn] tor_bug_occurred_: Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor 0.3.1.7 6babd3d9ba9318b3) Oct 21 01:09:10.000 [warn] Bug: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed in tor_compress_process at src/common/compress.c:576. Stack trace: (on Tor 0.3.1.7 6babd3d9ba9318b3) Oct 21 01:09:10.000 [warn] Bug: Unable to generate backtrace. (on Tor 0.3.1.7 6babd3d9ba9318b3) Regards, --

2 2

"Removed 1565259696 bytes by killing 1 circuits"
by tor 21 Oct '17

21 Oct '17

In a relay's logs: Oct 20 10:31:47 XXXXX Tor[YYYY]: We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Oct 20 10:32:11 XXXXX Tor[YYYY]: Removed 1565259696 bytes by killing 1 circuits; 40008 circuits remain alive. Also killed 0 non-linked directory connections. Tor removed ~ 1565 MB by killing 1 circuit? Seems like that can't be right? Earlier in the log I see "Based on detected system memory, MaxMemInQueues is set to 1500 MB." So either it's dumping the entire queue here, or the output is misleading. Or perhaps I don't understand how it works. It doesn't seem to be impactful; I'm just curious what's going on.

3 4

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

hi-jacking an onion address
by Toralf Förster 14 Oct '17

14 Oct '17

2 4

spurios warning about using the nickname instead of the key
by Toralf Förster 12 Oct '17

12 Oct '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm wondering why I suddenly got at both of my 2 Tor exit relays (0.3.2.2.-alpha, running at the same machine) the following message: /tmp/notice2.log:Oct 07 22:41:58.000 [warn] You specified a relay "zwiebeltoralf2" by name, but nicknames can be used by any relay, not just the one you meant. To make sure you get the same relay in the future, refer to it by key, as "$6EABEBF38CE7E3DF672C4DB01383606FE3EB2215". /tmp/notice.log:Oct 07 22:39:53.000 [warn] You specified a relay "zwiebeltoralf" by name, but nicknames can be used by any relay, not just the one you meant. To make sure you get the same relay in the future, refer to it by key, as "$1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA". when I queried the Tor status via a home-brewed Python script [1]. I do assume that the message is related to line 90 ot that script: flags = controller.get_network_status(relay=srv.nickname).flags Because I'm using the script few times per day I do wonder why this happens today for the first time at all (IIRC) and just only once. [1] https://github.com/toralf/torutils/blob/master/info.py - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdk/PxccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTpf8APwO30SS3Sbn1OhzOpFoJocdhj4k 7h/h6s5c0asDdwWkfwD/aaZpaP/ds9l4N9rivQSGW40Rv1Deqhuj/5fPtVizHeE= =8w5x -----END PGP SIGNATURE-----

8 11

Revert back to a stable build of Tor from an alpha
by Jacki M 12 Oct '17

12 Oct '17

How do I revert back to a stable build of Tor from an alpha? Im running Tor 0.3.2.2-alpha and need to revert back to Tor 0.3.1.7. Im running Ubuntu 16.04.3 LTS.

3 3

(no subject)
by Laty Luck 11 Oct '17

11 Oct '17

help

2 1