tor-relays April 2019

tor-relays@lists.torproject.org

44 participants
34 discussions

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

18 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 18 Apr '19

18 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 17 Apr '19

17 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

Dirauth running new bandwidth scanner version
by juga 10 Apr '19

10 Apr '19

Hi!, >From this moment longclaw is using a new bandwidth scanner version [0]. If you detect any issues with longclaw's voted bandwidth, please email me or open a ticket in Tor project trac [1]. Thanks, juga. [0] sbws.rtfd.io [1] trac.torproject.org

1 0

Advertised Bandwidth/Consensus Weight Dropping: Is Verizon FiOS throttling Tor Relays?
by Neel Chauhan 10 Apr '19

10 Apr '19

Hi tor-relays@ mailing list, I run the following Tor middle relay on a 300 Mbps symmetrical Verizon FiOS connection: https://metrics.torproject.org/rs.html#details/2A65713649C1FD68764DBF43C463… My setup is as follows: * HPE MicroServer Gen10 (AMD X3421) running FreeBSD 12.0 * Tor relay in FreeBSD 12.0 jail, with "RelayBandwidthRate 0" * Linksys WRT1900AC running OpenWrt The Linksys is connected directly to Verizon's ONT (which converts fiber/GPON to Ethernet) and no Verizon-branded router is used in my setup. The problem is that after setting up my relay, I had my Tor Advertised Bandwidth and Consensus Weight values trend downwards for the past week. Sometimes, I have occasional spikes in consensus weight. This relay has a new fingerprint, but used this server with another fingerprint as well. On the previous fingerprint, I reached a peak of 19.5 MB/s (~160 Mbps) for the Advertised Bandwidth but has dropped to ~10 MB/s (~80 Mbps). The previous fingerprint also had the same server and router. I am thinking the issue is one of the two: 1. Tor bandwidth authority nodes are overloaded or have bad connectivity to Verizon 2. Verizon is intentionally throttling Tor on FiOS 3. The relay ramp-up phase is still in action for my relay and I need to wait I am suspecting reason 2, as I had seen my bandwidth values drop, and unable to reach higher values. For some reason, other relays on AS701 (Verizon's AS Number) have higher Advertised Bandwidth/Consensus Weight values than me (around ~18.7MB/s on the fastest relay): https://metrics.torproject.org/rs.html#search/as:AS701 Sometimes, the other FiOS relays can go up to ~23 MB/s (~184 Mbps). Is Verizon throttling Tor or are Tor bandwidth authority nodes just overloaded (or have bad peering with Verizon)? Or is it just the relay ramp-up phase in action? Thank You, Neel Chauhan

1 0

Another Slow Relay
by Ben Riley 09 Apr '19

09 Apr '19

Hi everyone, I've read over a couple of other threads regarding relays being slow, however, I can't figure out why mine is running as slow as it is. I used to have a FAST flag and was getting a throughput of several hundred KB/sec on my relay. Now I can't remember if I upgraded TOR or just updated the OS, but I lost the flag. I figured that I'd changed something and would have to 'earn' it again after a few days, week and now months? According to NYX, my average is 6.4KB/sec. I did have the limit set to 1MB and 2MB burst for the last few months thinking that would be more than enough. This morning I changed those (via NYX) to 0 (default) 1GB/s and it looks like it's starting to climb. My internet connection is on a home set up with a connection speed of about 97Mb, so plenty of speed available. If you look at my previous reports on: https://metrics.torproject.org/rs.html#details/9F19251CEE17B1E05084898D164F… there appears to be a massive drop off in speed during Feb 2019. I'm open to suggestion. Additionally, I'm considering opening an exit port, but everyone seems to say that is a REALLY bad idea on a home set up. Plus I don't really know what I'm doing :)

3 5

Please help, my relay is unresponsive
by digitalist00 08 Apr '19

08 Apr '19

Dear helpers! Nyx says that my relay is unresponsive and that it was resumed. As I write this mail I have already 334 duplicates hidden. What's my problem and how can I solve this? The relay runs on a Raspberry Pi and is connected via LAN. Yours Digitalist [Unbenannt.JPG] Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 16

IPv6 not provided, guard relay
by digitalist00 08 Apr '19

08 Apr '19

Hello! I have read that it's recommended to enable IPv6 for a tor middle relay. But my provider doesn't offer IPv6. Is IPv6 required to become a guard middle relay? Yours Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays April 2019