- tor-relays - lists.torproject.org

#2667 [Core Tor/Tor]: Exits should block reentry into the tor network
by nusenu 31 Jan '18

31 Jan '18

> Comment (by arma): > > I continue to think that teaching exit relays to avoid allowing exit > connections to known relays (IP:ORPort) is a good and useful step. > > We keep running across messy situations where letting somebody connect to > a relay from an exit relay's IP address turns into a security surprise. Does that mean that exits will no longer be able to run tor clients (ie. to run apt updates via tor)? -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

Attack or issue? 4 / 11 M of traffic
by Stijn Jonker 30 Jan '18

30 Jan '18

Hi All, Since around midnight CET, my relay who was happily running almost the same amount of traffic in and outbound, has dropped to 4 Meg in, 11 Meg out according to SNMP on the host. (Cap: 10M/peak 12.5M). Lots of messages like: - Channel padding timeout scheduled 304317ms in the past. - 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. [45685 similar message(s) suppressed in last 60 seconds] Any suggestions what to check / verify for this? 328E54981C6DDD7D89B89E418724A4A7881E3192 Thx, Stijn

2 1

How to post to this list
by grarpamp 30 Jan '18

30 Jan '18

1) DO NOT Top Post, backwards it's because that's, reply below what you're replying to. 2) DO NOT Bulk Quote, trim what you're replying to down to the minimum size needed to convey the relavant context. 3) DO NOT Block Reply, piecewise interleave your replies below each piece of context to which you are replying. 4) DO NOT send HTML, set you rmailer to compose and send plain text emails. Far too many breaking basic "email netiquette" lately. Learn more by searching that quote.

4 5

tor on arm vps
by Quintin 29 Jan '18

29 Jan '18

I see online.net has a lot of ARM VPSes. Does tor run fine on these? Q -- 0101100101000001010010000101011101000101010010000010000001000010 0100110001000101010100110101001100100000010110010100111101010101

3 11

A lot of Warn messages when bootstrapping Tor 0.3.2.9 (stable)
by Dark Matter 29 Jan '18

29 Jan '18

Hello, I'm running a tor-relay with Tor version 0.3.2.9 (stable). I had to do some daemon restarts, because of connection limit issues. Since the last two restarts the Tor process issues a lot of warnings while bootstrapping, because it could not create a (client) circuit. Relay functionality is working without problems. Before these restarts I had no problems connecting to the tor network and creating circuits. Tor usually booted within less than a minute without warnings. I found a ticket describing the same problem (although for a different Tor version) here: https://trac.torproject.org/projects/tor/ticket/24639. Are there any known workarounds yet? For more detail, I'll post the last warning messages: Jan 25 18:31:54.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection timed out; TIMEOUT; count 1503; recommendation warn; host B7047FBDE9C53C39011CA84E5CB2A8E3543066D0 at 199.249.223.60:443) Jan 25 18:31:54.000 [warn] 1503 connections have failed: Jan 25 18:31:54.000 [warn] 1026 connections died in state connect()ing with SSL state (No SSL object) Jan 25 18:31:54.000 [warn] 392 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE Jan 25 18:31:54.000 [warn] 84 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN Jan 25 18:31:54.000 [warn] 1 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE Tor had to try to open a circuit for more than half an hour before finally succeeding... Regards, Dark

3 2

The Onion Box: Connections
by Ralph Wetzel 28 Jan '18

28 Jan '18

3 2

Upgraded relay non show in ATLAS
by MLTor Node 27 Jan '18

27 Jan '18

6 11

>30% of the Tor network runs outdated version: Consider enabling auto-updates
by nusenu 27 Jan '18

27 Jan '18

Hi, when writing the content for the Tor Relay Guide we also collected steps to enable auto updates for various Linux distributions. The motivation for this is that there are a lot of relays (>3000) running outdated tor releases. If more operators enable auto-updates the number of outdated tor relays hopefully decreases. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#AutomaticSoftwa… Debian: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpd… RPM Distros: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/RPMUpdates thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

7 11

debugging unbound on 'torexit' failing DNS queries
by nusenu 26 Jan '18

26 Jan '18

<tor-admin(a)portaltodark.world> wrote: > Resent under the correct alias. > > I'm having high amounts of failures on this VPS (PulseServers). I run a > local unbound instance, and see an incredible amount of: > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 198.97.190.53 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 192.42.93.30 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > Jan 17 19:27:33 torexit unbound: [559:0] notice: remote address is > 192.35.51.30 port 53 > Jan 17 19:27:33 torexit unbound: [559:0] notice: sendto failed: Operation > not permitted > > To give proportion to "incredible amount", > Jan 17 19:21:32 torexit rsyslogd: imjournal: 9897 messages lost due to > rate-limiting > Jan 17 19:22:02 torexit journal: Suppressed 1216 messages from > /system.slice/unbound.service > Jan 17 19:22:32 torexit journal: Suppressed 1209 messages from > /system.slice/unbound.service > Jan 17 19:23:02 torexit journal: Suppressed 1827 messages from > /system.slice/unbound.service > Jan 17 19:23:32 torexit journal: Suppressed 2333 messages from > /system.slice/unbound.service > Jan 17 19:24:02 torexit journal: Suppressed 3029 messages from > /system.slice/unbound.service > Jan 17 19:24:32 torexit journal: Suppressed 2822 messages from > /system.slice/unbound.service > Jan 17 19:25:02 torexit journal: Suppressed 2715 messages from > /system.slice/unbound.service > Jan 17 19:25:32 torexit journal: Suppressed 3166 messages from > /system.slice/unbound.service > Jan 17 19:26:02 torexit journal: Suppressed 4093 messages from > /system.slice/unbound.service > Jan 17 19:26:32 torexit journal: Suppressed 45878 messages from > /system.slice/unbound.service > Jan 17 19:27:02 torexit journal: Suppressed 30125 messages from > /system.slice/unbound.service > Jan 17 19:27:32 torexit journal: Suppressed 31764 messages from > /system.slice/unbound.service > Jan 17 19:28:02 torexit journal: Suppressed 31229 messages from > /system.slice/unbound.service > > Could it be limits from the VPS provider on the amount of outbound udp/53 > connections? To me this looks more like a local problem? Are you doing any packet filtering on the host (outbound)? Does DNS work on that host if you try manual queries? From the IPs in your logs I assume your unbound is configured to query recursively itself (no upstream forwarding) that is good, can you confirm that and provide your unbound config + iptalbes -vnL? -- https://mastodon.social/@nusenu twitter: @nusenu_

4 13

Re: [tor-relays] A lot of Warn messages when bootstrapping
by Dark Matter 26 Jan '18

26 Jan '18

Thanks for the fast reply! > Your relay has probably chosen some overloaded guards. > The problem comes from the extra load on those machines, not your relay. > Your relay will eventually try other guards. > > Are you sure it's not overloaded? > It might be worth checking the logs, inbound connections, RAM, and CPU > after it has been running for a few days. Yes, the relay is working fine - the only problem was the connection limit due to some OS-level limits.which is why I had to restart the relay in the first place. > Ignore the warning messages unless your relay is having problems. Ok, I'll do :) Once one successful circuit was established, there were no warnings any more. It just took some time - but I cannot tell if the relay switched guards or if the guard nodes finally managed to accept a connection request, since I didn't check the guard node set prior to restarting. Regards, Dark

1 0