- tor-relays - lists.torproject.org

Tor Meetup in Hamburg, April 26th
by Alexander Dietrich 28 Apr '19

28 Apr '19

English: We would like to invite people interested in the Tor project and relay operators in the Hamburg area to meet at University of Hamburg, Department of Computer Science. There will be an introduction to Tor, a Q&A session and a brief announcement about a newly founded Hamburg-based Tor association. We would love for relay operators to meet and discuss ways of strengthening the network. Be seeing you! When: Friday, April 26th, 7:00 PM Where: Informatikum, Building F, Room F-027 University of Hamburg, Vogt-Kölln-Straße 30, 22527 Hamburg Public Transportation: https://www.hvv.de/(Destination: Informatikum) Deutsch: Wir möchten am Tor-Projekt interessierte Menschen und Relay-Betreiber aus Hamburg und Umgebung einladen, sich am Informatikum der Universität Hamburg zu treffen. Es wird eine Tor-Einführung, eine Frage-Antwort-Runde und eine kurze Ankündigung eines neugegründeten Hamburger Tor-Vereins geben. Wir würden uns freuen, wenn sich Relay-Betreiber treffen und Wege diskutieren, das Netzwerk zu stärken. Wir sehen uns! Wann: Freitag, 26. April 2019, 19:00 Uhr Wo: Informatikum, Gebäude F, Raum F-027 Universität Hamburg, Vogt-Kölln-Straße 30, 22527 Hamburg ÖPNV: https://www.hvv.de/(Ziel: Informatikum) Kind regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

1 1

relay unresponsive - relay resumed - stable-flag
by digitalist00 27 Apr '19

27 Apr '19

Hello! Maybe this is the cause why I've lost my stable-flag. Does anybody know how to fix this. The relay runs on a Raspberry. Need any further information? Yours digitalist [Unbenannt.JPG] Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

firewall ports needed to run a middle relay
by torix＠protonmail.com 27 Apr '19

27 Apr '19

I need to move to a new router, which, unlike the old Verizon home router, doesn't have a quick DMZ host to which I attach the tor telay's local ip address. So I think I need to do port forwarding, and for that what rules do I need? My torrc config has: ControlPort 9052 ORPort 8443 DirPort 8080 So I forwarded 8443 and just in case, 8080. But the number of my connexions kept dropping, so I put it back in the DMZ and it started getting new ones again. Trying to figure out if I screwed up the config gui, or if I need to add other ports. Did I miss a port? TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

5 6

Re: [tor-relays] Research on the live Tor Network and the Tor Research Safety Board
by nusenu 26 Apr '19

26 Apr '19

FYI nusenu wrote (2019-04-20): > Hi there, > > we noticed your tor relays and were wondering whether you > submitted your research to the Tor Research Safety Board > for review since your email address and amount of relays suggests > you are doing research. > > https://research.torproject.org/safetyboard.html > > https://nusenu.github.io/OrNetRadar/2019/04/17/a3 > > kind regards, > nusenu > > -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

ipv6 behaviour consensus
by Charly Ghislain 19 Apr '19

19 Apr '19

Hi list, Last reply from s7r on jake Visser' issue included a link to an open issue waiting for a consensus on a mailing list: https://trac.torproject.org/projects/tor/ticket/29570 Not sure if teor implied the dev mailing list or this one, but maybe gathering feedback from operators is a good idea. AFAIC, as avee stated on the ticket I don't find the current setup much confusing. The documentation on ipv6 setup was not as clear as one would expect, I came across what appeared to be outdated docs, and I think this is the area that could be improved to eases operator setup. I agree with Avee that any update on that matter should be backward compatible, allowing relays running behind custom natted networks to continue operating without any trouble. I feel there is an issue in case the operator advertises an unreachable ip6 address in the config. This seems like a configuration error that should be spotted by a self-reachability mechanism that is yet to come, like for ipv4. I can imagine however that directories could be able to flag the relay as reachable over ipv4 and not over ipv6, and that the relay would still be usable over ip4. I thought it was the case actually. Please provide your feedback. ip6 is around for so long, it is depressing to see how hard it is for so many software to provide a nice user experience with it. Regards, Charly

5 6

Debugging relays not showing online
by Jake Visser 19 Apr '19

19 Apr '19

Hi all, I am looking for some help in debugging a strange one.... EO runs ~30ish relays in our /24; but we currently have 4 relays that don't want to play nice and are reporting offline (although look to be online). The effected relay IPs are: 23.129.64.157 23.129.64.164 23.129.64.170 23.129.64.174 The first 3 do show on Metrics, and when they are restarted or rebuilt (we use relayor), metrics does pick it up.. in terms that its "uptime" is updated to reflect the restart, although still marked offline. The 4th - doesn't show at all... it is in the family members though. Looking more closely at: 23.129.64.157 (183C8C6727E2137AF278B3850AD5D9C2304B98C9); using nyx with debug messaging; 2 hours after a restart, I can still see active circuits, and I can see it doing "things" [logs bellow], and http://23.129.64.157 loads (we run the exit page). Is there anything I could be doing or look at to indicate what might be creating such a strange issue? All the other relays in the family seem to be working fine.. https://metrics.torproject.org/rs.html#search/family:183C8C6727E2137AF278B3… (and all built and managed with relayor using offline keys..). These have been online for about 10 days now. Help / guidance would be greatly appraised... Thanks, Jake Events (DEBUG-ERR, NYX NOTICE-ERR): x 10:48:54 [DEBUG] conn_read_callback: socket 18 wants to read. [181 duplicates hidden] x 10:48:50 [DEBUG] connection_or_process_cells_from_inbuf: 14: starting, inbuf_datalen 0 (0 pending in tls object). [83 duplicates hidden] x 10:48:50 [DEBUG] connection_or_process_cells_from_inbuf: 14: starting, inbuf_datalen 514 (0 pending in tls object). [83 duplicates hidden] x 10:48:50 [DEBUG] connection_buf_read_from_socket: After TLS read of 514: 543 read, 0 written [99 duplicates hidden] x 10:48:50 [DEBUG] connection_buf_read_from_socket: 14: starting, inbuf_datalen 0 (0 pending in tls object). at_most 16448. [105 duplicates hidden] x 10:48:50 [DEBUG] conn_read_callback: socket 14 wants to read. [83 duplicates hidden] x 10:48:43 [INFO] update_consensus_router_descriptor_downloads: 0 router descriptors downloadable. 0 delayed; 6722 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 0 in progress. [9 duplicates hidden] x 10:48:39 [DEBUG] connection_or_process_cells_from_inbuf: 25: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden] x 10:48:39 [DEBUG] connection_or_process_cells_from_inbuf: 25: starting, inbuf_datalen 514 (0 pending in tls object). [1 duplicate hidden] x 10:48:39 [DEBUG] conn_read_callback: socket 25 wants to read. [1 duplicate hidden] x 10:48:39 [DEBUG] connection_or_process_cells_from_inbuf: 17: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden] x 10:48:39 [DEBUG] connection_or_process_cells_from_inbuf: 17: starting, inbuf_datalen 514 (0 pending in tls object). [1 duplicate hidden] x 10:48:39 [DEBUG] conn_read_callback: socket 17 wants to read. [1 duplicate hidden] x 10:48:39 [DEBUG] connection_handle_write_impl: After TLS write of 514: 0 read, 543 written [17 duplicates hidden] x 10:48:39 [DEBUG] flush_chunk_tls: flushed 514 bytes, 0 ready to flush, 0 remain. [17 duplicates hidden] x 10:48:39 [DEBUG] conn_write_callback: socket 25 wants to write. [1 duplicate hidden] x 10:48:39 [DEBUG] conn_write_callback: socket 17 wants to write. [1 duplicate hidden] x 10:48:39 [DEBUG] run_connection_housekeeping: Sending keepalive to (199.58.81.140:443) [1 duplicate hidden] x 10:48:39 [DEBUG] run_connection_housekeeping: Sending keepalive to (154.35.175.225:443) [1 duplicate hidden] x 10:48:16 [INFO] routerlist_remove_old_routers: We have 6869 live routers and 820 old router descriptors. [8 duplicates hidden] x 10:48:16 [DEBUG] resolve_my_address: Resolved Address to '23.129.64.157'. [8 duplicates hidden] x 10:48:13 [DEBUG] connection_or_process_cells_from_inbuf: 23: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden] x 10:48:13 [DEBUG] connection_or_process_cells_from_inbuf: 23: starting, inbuf_datalen 514 (0 pending in tls object). [1 duplicate hidden] x 10:48:13 [DEBUG] conn_read_callback: socket 23 wants to read. [1 duplicate hidden] x 10:48:13 [DEBUG] conn_write_callback: socket 23 wants to write. [1 duplicate hidden] x 10:48:13 [DEBUG] run_connection_housekeeping: Sending keepalive to (128.31.0.34:9101) [1 duplicate hidden] x 10:48:09 [DEBUG] conn_write_callback: socket 14 wants to write. [1 duplicate hidden] x 10:48:09 [DEBUG] run_connection_housekeeping: Sending keepalive to (217.20.130.72:9001) [1 duplicate hidden] x 10:46:53 [DEBUG] connection_or_process_cells_from_inbuf: 21: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden] x 10:46:53 [DEBUG] connection_or_process_cells_from_inbuf: 21: starting, inbuf_datalen 514 (0 pending in tls object). [1 duplicate hidden] x 10:46:53 [DEBUG] conn_read_callback: socket 21 wants to read. [1 duplicate hidden] x 10:46:53 [DEBUG] conn_write_callback: socket 21 wants to write. [1 duplicate hidden] x 10:46:53 [DEBUG] run_connection_housekeeping: Sending keepalive to (194.109.206.212:443) [1 duplicate hidden] x 10:46:40 [DEBUG] connection_or_process_cells_from_inbuf: 20: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden] x 10:46:40 [DEBUG] connection_or_process_cells_from_inbuf: 20: starting, inbuf_datalen 514 (0 pending in tls object). [1 duplicate hidden] x 10:46:40 [DEBUG] conn_read_callback: socket 20 wants to read. [1 duplicate hidden] x 10:46:40 [DEBUG] conn_write_callback: socket 20 wants to write. [1 duplicate hidden] x 10:46:40 [DEBUG] run_connection_housekeeping: Sending keepalive to (171.25.193.9:80) [1 duplicate hidden] x 10:46:26 [DEBUG] connection_or_process_cells_from_inbuf: 19: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden] x 10:46:26 [DEBUG] connection_or_process_cells_from_inbuf: 19: starting, inbuf_datalen 514 (0 pending in tls object). [1 duplicate hidden] x 10:46:26 [DEBUG] conn_read_callback: socket 19 wants to read. [1 duplicate hidden] x 10:46:26 [DEBUG] conn_write_callback: socket 19 wants to write. [1 duplicate hidden] x 10:46:26 [DEBUG] run_connection_housekeeping: Sending keepalive to (204.13.164.118:443) [1 duplicate hidden] x 10:46:23 [DEBUG] connection_or_process_cells_from_inbuf: 22: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden] x 10:46:23 [DEBUG] connection_or_process_cells_from_inbuf: 22: starting, inbuf_datalen 514 (0 pending in tls object). [1 duplicate hidden] x 10:46:23 [DEBUG] conn_read_callback: socket 22 wants to read. [1 duplicate hidden] x 10:46:22 [DEBUG] conn_write_callback: socket 22 wants to write. [1 duplicate hidden] x 10:46:22 [DEBUG] run_connection_housekeeping: Sending keepalive to (86.59.21.38:443) [1 duplicate hidden] x 10:46:10 [DEBUG] consdiffmgr_cleanup: Looking for consdiffmgr entries to remove qj 10:45:58 [DEBUG] connection_or_process_cells_from_inbuf: 15: starting, inbuf_datalen 0 (0 pending in tls object). [1 duplicate hidden]

3 3

Quoting spam considered harmful
by Ralph Seichter 19 Apr '19

19 Apr '19

* Seby: > This dude just won't stop harassing us with masked advertising, > commercial offers and monetary asks. [...] My mail killfile is useful for discarding mail by specific senders, but quoting their posts negates that effect, so please don't. Thanks. -Ralph

2 5

Re: [tor-relays] [tor-talk] Anyone interested in running FreeBSD or Linux Exit Relays on AS19624?
by grarpamp 18 Apr '19

18 Apr '19

On 4/17/19, Seby <seby2kt14(a)gmail.com> wrote: > Here we go again... Not really different than all the quasi or non profit tor node groups posting their news now and then. Nos onions, torservers, emerald onions, noisebridge, etc. Hey look at me, join us, give us money, we're doing stuff, etc. So long as it supports the overlay networks, gets nodes running on them, etc... some diversity in approach to that isn't going to kill you, else hit your 'block' button. Maybe even some new operators-to-be like the offer of somehow working together with a hosters to get started funding and running their nodes that they would otherwise not be so confidant to do right away as a first step. Worry about MyFamily and good ops instead. > stop OMFG yes, please stop top posting, all of you.

1 0

Anyone interested in running FreeBSD or Linux Exit Relays on AS19624?
by Conrad Rockenhaus 17 Apr '19

17 Apr '19

For a small donation in relation to the number of physical CPUs (and x cores each) plus bandwidth you want, (mbp/s or gbp/s) I can provide you your own instance on my OpenStack cloud that I just built out on AS19624. No exit policy restrictions, I handle all abuse complaints, so you won’t have to worry about any abuse takedowns. This is the only time I’ll mention it here. If anyone is interested, please email me directly. Thanks, Conrad

4 3

Making use of new bandwidth
by Logforme 11 Apr '19

11 Apr '19

I run the non-exit relay: https://metrics.torproject.org/rs.html#details/855BC2DABE24C861CD887DB9B2E9… The relay run on a debian stretch machine with an i5-4670 at 3.8GHz with 4GB memory. CPU usage at 250Mbps traffic is around 40% of 1 core out of 4. On April 1st my ISP doubled my bandwidth, from 250Mbps to 500Mbps. So far the Tor bandwidth authorities seems to not have picked up on all the new bandwidth. The observed bandwidth number has changed twice, increasing with small amounts. How long does it take for the BW authorities to eventually observe a BW closer to 500Mbps. Weeks? Months? The reason I ask is that I wonder if I should run a second Tor instance or if the current one will be able to make use a a reasonable part of the 500Mps.

5 8