Re: [tor-relays] Middle relay IP blocking

[Logforme]

On 2023-08-01 23:14, Eldalië via tor-relays wrote:

My guess is that some widely used black list started including middle relay
IPs, but I have no proofs.
Has anyone had similar experiences? Any thoughts on this?


I run a non-exit relay at home and have run into the same issue.
Some Swedish government sites use a third party for handling log ins. A 
few months ago this third party started blocking non-exit relays. I 
tried to contact the government sites and explain the issue (exit vs 
non-exit IP lists etc). None of them said it was their policy to block 
non-exits but naturally pointed at the third party. I tried to contact 
them but got nowhere, maybe they outsource in their turn.


Since sites these days outsource so much it is hopeless to get through 
to anyone able or willing to fix an issue. I gave up after many emails.


My "solution" for now is to use my phone's internet sharing when I have 
to contact these sites. Since it only is a few sites which I contact 
rarely this works, but as more and more sites outsource their security 
to third parties I expect this to be a growing problem. Eventually I 
might no longer be able to run a relay.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] List number of circuits per connection

[Logforme]

On 2022-10-20 03:35, Alex Xu (Hello71) via tor-relays wrote:


for these reasons, I haven't aggressively pursued this plan. I have some
more ideas based on intra-family correlation, but they also have similar
problems as well as more implementation problems. in the long term, our
best hope is the PoW scheme (note: not cryptocurrency) being somewhat
quietly worked on.


Good points and PoW will be great when available but I'm looking for 
something I as an operator can do to mitigate the circuit creation DoS 
until then. Oh well

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] List number of circuits per connection

[Logforme]

On 2022-10-19 17:10, Chris wrote:


You may want to check these links:

https://gitlab.torproject.org/tpo/community/support/-/issues/40093

https://github.com/Enkidu-6/tor-ddos

https://github.com/toralf/torutils



Thank you for the reply and the links.
From what I can understand those links concern "connections". I believe 
my firewall rules handles that fine (they're based on Toralf's example).


My concern is about circuits. As I understand it one connection can 
create many circuits. If the attacker keeps the connections down to 
avoid being blacklisted they can create lots of circuits. And one 
circuit created affects 3 relays.


So what I'm looking for is a way to get the IP of big circuit creators.
I understand that many circuits will come from other relays but on my 
guard relay I assume the attacker also connect directly. If I can 
blacklist non-relays that create too many circuits I can help my relay 
and those downstream.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] List number of circuits per connection

[Logforme]

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3

Like most relays mine has been targeted by the DoS attack. Hundreds of 
VPS IPs creating millions of IP connections. This I mitigated with rules 
in my firewall. Looking at the firewall counters it looks like that 
attack has now stopped.


However the relay is still overloaded from lots of circuit creations. 
Normally my little relay reports around 100K circuits open in the log 
file but since the overloading started it's closer to 1M circuits open. 
All these circuit creations put a strain on the CPU, sometime pegging it 
at 100% (4 core i5-4670K CPU @ 3.40GHz). Worse, it seems to eat memory. 
Normally the tor process uses about 3GB (out of 8GB) but I have seen it 
quickly shoot up to using all memory and all swap. I assume this is 
because of the circuit creation DoS (it's new behavior) and what causes 
the oom killer to kill the tor process at least once a day or so.


So, how do I mitigate the circuit creation DoS? My immediate thought is 
to identify if there are a few IPs responsible for the majority and add 
those to my firewall naughty list.


Is there a way to query the tor process about number of open circuits 
mapped to IP addresses?

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] a characteristic of recent attacks?

[Logforme]

On 2022-09-01 06:53, Scott Bennett wrote:

  My question is, do other relay operators whose relays are being
attacked see the same phenomenon?


My relay's (8F6A78B1EA917F2BF221E87D14361C050A70CCC3) heartbeat messages 
show a steady increase. This could be because I only get HB every 6 hours.



In addition, if someone knows of an
effective way to turn such things aside at less cost than be simply
leaving them to tor to deal with, I'd love to know about it, too, though
I suspect there may be no such method.


I use connection limits in my firewall. At the moment the counters show 
154M connections dropped from 595 IP addresses vs 13M connections let 
through.


This measure has helped the relay run smoother but it still gets flagged 
as overloaded.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Relays spamming my OR port

[Logforme]

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3

I have tried to mitigate the current DoS by implemented connection 
limits in my iptables using Toralf's template: More than 25 connection 
during 10 mins and you end up on my naughty list.
Lots of connection attempts from the naughty list dropped but still my 
relay gets "overloaded"


However, I have noticed that a few relays also end up on the naughty 
list, and I wonder how that can happen. My understanding is that a relay 
will only open 1 connection to another relay so should therefore never 
end up on the list. Correct?


D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent 
naughty boy.
Maybe these relays disconnect and reconnect to my relay frequently due 
to network issues (effect from the DoS?) or from not having enough 
connections available on the router?


I guess my real question is if these connections are legit and I'm 
hurting the Tor network by using connection limits?

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] We're trying out guard-n-primary-guards-to-use=2

[Logforme]

On 2022-07-06 21:19, Roger Dingledine wrote:

But it was replaced with a new overload (boo), from way too many Tor
clients running at a few cloud providers. The main result for relay
operators is greatly increased file descriptor use, with a few IP
addresses or /24's generating the majority of the new connections.

If your relay is bumping up against its file descriptor limits,
or otherwise suffering (e.g. more memory usage than desired), one
reasonable option for you might be to set some iptables-level connection
limiting. More details in this ticket:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40636#note_2818529



I'm running the small non-exit 8F6A78B1EA917F2BF221E87D14361C050A70CCC3.

Since mid-may the relay has been under heavy load. I had to limit my 
bandwidth using "RelayBandwidthRate" in torrc to about 90% of my real BW 
to be able to use internet for myself. This solved my laggy internet.


Since the 2nd of July the number of (non torrelay) tor connections to my 
relay skyrocketed from about 3500 to 2.

A week ago I implemented  connection limits per Toralf's post:
iptables -A INPUT -p tcp --destination-port  443 -m connlimit 
--connlimit-mask 32 --connlimit-above 30 -j DROP

This reduced the number of connections to about 1.

I just now noticed that the relay is flagged as overloaded. What to do?
Decrease the connection limit from 32 to .. what?
Decrease my RelayBandwidthRate even more? Seems like giving in to the DoSer.

Logfile:
Jul 10 02:58:39.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. [8169 similar message(s) suppressed in last 14820 seconds]
Jul 10 03:32:28.000 [notice] General overload -> Ntor dropped (220414) 
fraction 5.8677% is above threshold of 0.5000%


Metrics port:
tor_relay_load_onionskins_total{type="tap",action="processed"} 697956
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 503071860
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 323369
tor_relay_load_onionskins_total{type="ntor_v3",action="processed"} 503071860
tor_relay_load_onionskins_total{type="ntor_v3",action="dropped"} 323369
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unexpected classification with my guard relay

[Logforme]

I am contacting you because I don't understand why my relay is not 
considered as a guard relay (entry relay), since I already have the 
following flags: Fast, HSDir, Running, Stable, V2Dir, Valid.


The dir-spec.txt document 
(https://github.com/torproject/torspec/blob/main/dir-spec.txt) specifies 
what's needed for the different flags. For guard (line 2615) it says the 
following on bandwidth requirements:


- Its bandwidth is at least AuthDirGuardBWGuarantee (if set, 2 MB by
 default), OR its bandwidth is among the 25% fastest relays

So looks you need to have at least 2MB/s. Your relay is at 290KB/s

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Compression bomb from dizum

[Logforme]

Got the following in my log today:
Nov 06 18:19:01.000 [warn] Possible compression bomb; abandoning stream.
Nov 06 18:19:01.000 [warn] Unable to decompress HTTP body (tried 
Zstandard compressed, on Directory connection (client reading) with 
45.66.33.45:80).

45.66.33.45 is tor.dizum.com, a Tor directory authority.

False positive or a problem generating directory info at dizum?

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] current HSDir flag requirements

[Logforme]

On 2021-05-26 08:18:32, "Scott Bennett"  wrote:

I interpret that as meaning that one
or more criteria being used by one or more authorities has changed,
What I have noticed on my relay is that the "Consensus Weight" is 
fluctuating.
CW is too complicated for my tiny brain but I believe the measurements 
from the Bandwidth Authorities is involved. The BWAuths are spread 
around the world and depending on current internet conditions they get 
different speed values to your relay. But can it cause massive swings in 
CW?
Maybe the BWAuths have changed their measurement technique during the 
last couple of months?



 A further question I would like to raise is why do the Authority relays
use different criteria from one to another for the automatic assignment of
flags?  Should they not be consistent in using the same rules?

I agree that it is confusing that 2 auths don't assign the HSDir flag 
according to the spec.
I have no explanation apart from that AFAIK moria1 is run by Roger 
Dingledine and I guess he runs a lot of beta and test stuff.
moria1 publishes 2 HSDir "Flag Threshold" values (hsdir-wfu and 
hsdir-tk) that no other auth publishes which leads me to believe moria1 
runs another version of the auth software that handles the HSDir flag 
differently. That don't explain bastet though.


It's fun to speculate :)

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] current HSDir flag requirements

[Logforme]

On 2021-05-25 12:08:34, "John Csuti"  
wrote:


I second this. We are in 2021 and a relay is considered fast if it is 
above 100KB/s...? I don’t think a later dialup service should be 
considered a fast relay.


100KB/s is about 800Kb/s 
(https://en.wikipedia.org/wiki/Data-rate_units). I envy the dial up 
modems you had :)


I agree it is not fast, but is it "fast enough" for Tor's purpose? The 
Fast flag is (was?) also described as "the router is suitable for 
high-bandwidth circuits".
If I used Tor for high bandwidth stuff I'd hate to get a relay like that 
in my circuit. Especially if it also acts as a HSDir provider.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] current HSDir flag requirements

[Logforme]

On 2021-05-22 11:31:12, "Scott Bennett"  wrote:


 What are all the current requirements for a relay to get a
HSDir flag?  96 (97?) hours of uptime and what else?
 Can someone tell me what my relay, MYCROFTsOtherChild, is
missing for a HSDir flag?

From the spec: 

https://github.com/torproject/torspec/blob/master/dir-spec.txt

"HSDir" -- A router is a v2 hidden service directory if it stores and
   serves v2 hidden service descriptors, has the Stable and Fast flag, 
and the
   authority believes that it's been up for at least 96 hours (or the 
current

   value of MinUptimeHidServDirectoryV2).

"Fast" -- A router is 'Fast' if it is active, and its bandwidth is 
either in

   the top 7/8ths for known active routers or at least 100KB/s.

If you look at the concensus health 
(https://consensus-health.torproject.org/), go to the bottom and enter 
your relay nickname you will see what each of the authorities think 
about your relay.
moria1 and bastet are very stingy about handing out HSDir. I don't think 
any of my relays ever has gotten it from them.
Of the rest, the authorities that think your relay is "Fast" has also 
awarded it HSDir. Unfortunately 3 don't think the relay is "Fast" so no 
HSDir. And with only a 4/9 vote the relay don't get the HSDir flag.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Huge increase in bridge connections

[Logforme]

On 2021-02-12 07:20:02, "Eddie"  wrote:


Just trying to understand if this is normal or if something else is going on.
I have 2 bridges on a VPS.  One is designated as "moat", the other "email".  
Until earlier today, for over a year, both averaged under 10 unique clients, per 6-hour reporting 
period.
Today, the "moat" bridge, in a single period went from single digits to almost 
300 unique clients.  Is this normal/possible or what other explanation could there be.

Don't know if it's connected but my 2 guard relays jumped from the 
normal 2k clients to over 6k during a 24h period.

https://imgur.com/ATB2VNL

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH

[Logforme]

On 2020-09-21 11:19:20, "Андрей Гвоздев"  
wrote:



Hello
I'm running a TOR relay, every time I SSH to my server I see a message
that there were thousands of failed login attempts
Do you see this message too?

Exposing a SSH server to the internet will get you lots of login 
attempts.

Here are some things you SHOULD do to help the situation:
Change the SSH default port.
Disable the root login.
Use key-based authentication.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[Logforme]

The new list has been generated and can be found here:

https://gitlab.torproject.org/tpo/core/fallback-scripts/-/blob/master/fallback_offer_list



I don't understand this section:
# These fallbacks opted-in in previous releases, then changed their details,# 
and so we blacklisted them. Now we want to whitelist changes.# Assume details 
update is permanent85.230.184.93:9030 orport=443 
id=855BC2DABE24C861CD887DB9B2E950424B49FC34 # Logforme
Logforme is my relay. I've repeatedly asked for it to be blacklisted. Does "Now we 
want to whitelist changes" mean you want to whitelist the relay? Please don't.
Btw the ip listed is not the current one.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)

[Logforme]

My relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34) is 
currently flagged as fallback dir.
The relay runs on a dynamic ip address that will change rarely. I have 
over the years tried multiple times to get the relay excluded from the 
fallback dir list but it keeps popping back in there.
Currently the ip address does not match what is listed in your linked 
document.

Please remove the relay from the fallback dir list.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Recommended router for 200+ Mb/s relay

[Logforme]

On 2020-04-29 17:13:49, "Secure Node"  wrote:


I'm looking for new router for good price which can handle more connections and 
traffic ;-)
Can you recommend any specific models? Should I avoid some products lines or 
companies?

If you have an old PC with 2 ethernet ports laying around or you can get 
one cheap I suggest you build your own:

https://arstechnica.com/gadgets/2016/04/the-ars-guide-to-building-a-linux-router-from-scratch/

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Improving Relay IPv6 - RIPE Grant

[Logforme]

On 2019-12-12 17:49:22, "NOC"  wrote:

than lets drop all IPv4 only relays from consensus 2020 finally.


I would be sad to no longer be able to contribute to the Tor network.
My ISP, Telenor Sweden, does not provide IPv6 and have no (public) 
roadmap for supporting IPv6.
I can't switch ISP since they provide the fiber connection for the 
apartment building.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Assertion pol->magic failed

[Logforme]

Tonight my relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 restarted with 
the following in the log file:
Nov 20 19:08:07.000 [notice] Heartbeat: Tor's uptime is 20 days 12:00 
hours, with 29939 circuits open. I've sent 46193.23 GB and received 
45940.92 GB.
Nov 20 19:08:07.000 [notice] Circuit handshake stats since last time: 
36379/36379 TAP, 591207/591207 NTor.
Nov 20 19:08:07.000 [notice] Since startup we initiated 0 and received 
655 v1 connections; initiated 0 and received 191219 v2 connections; 
initiated 1 and received 191367 v3 connections; initiated 75189 and 
received 1351289 v4 connections; initiated 147903 and received 1783201 
v5 connections.
Nov 20 19:08:07.000 [notice] DoS mitigation since startup: 11 circuits 
killed with too many cells. 3810290 circuits rejected, 67 marked 
addresses. 349630 connections closed. 7988 single hop clients refused.
Nov 21 00:18:01.000 [err] tor_assertion_failed_(): Bug: 
../src/core/or/circuitmux_ewma.c:165: TO_EWMA_POL_CIRC_DATA: Assertion 
pol->magic == 0x761e7747U failed; aborting. (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: Assertion pol->magic == 0x761e7747U 
failed in TO_EWMA_POL_CIRC_DATA at ../src/core/or/circuitmux_ewma.c:165: 
. Stack trace: (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x47) 
[0x55d5e9f968e7] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: 
/usr/bin/tor(tor_assertion_failed_+0x147) [0x55d5e9f919c7] (on Tor 
0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0x8fe84) 
[0x55d5e9e14e84] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0xb839f) 
[0x55d5e9e3d39f] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: 
/usr/bin/tor(circuit_receive_relay_cell+0x29a) [0x55d5e9e419fa] (on Tor 
0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: 
/usr/bin/tor(command_process_cell+0x2fc) [0x55d5e9e23a1c] (on Tor 
0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: 
/usr/bin/tor(channel_tls_handle_cell+0x333) [0x55d5e9e030d3] (on Tor 
0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0xa773f) 
[0x55d5e9e2c73f] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: 
/usr/bin/tor(connection_handle_read+0x990) [0x55d5e9df0500] (on Tor 
0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(+0x707ee) 
[0x55d5e9df57ee] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: 
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) 
[0x7fb82bb5f5a0] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(do_main_loop+0x105) 
[0x55d5e9df6b25] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_run_main+0x1225) 
[0x55d5e9de4545] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(tor_main+0x3a) 
[0x55d5e9de193a] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(main+0x19) 
[0x55d5e9de14b9] (on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fb82a3b32e1] 
(on Tor 0.4.1.6 )
Nov 21 00:18:01.000 [err] Bug: /usr/bin/tor(_start+0x2a) 
[0x55d5e9de150a] (on Tor 0.4.1.6 )

Nov 21 00:18:02.000 [notice] Tor 0.4.1.6 opening log file.
Nov 21 00:18:02.605 [notice] We compiled with OpenSSL 101000bf: OpenSSL 
1.1.0k  28 May 2019 and we are running with OpenSSL 101000cf: OpenSSL 
1.1.0l  10 Sep 2019. These two versions should be binary compatible.
Nov 21 00:18:02.606 [notice] Tor 0.4.1.6 running on Linux with Libevent 
2.0.21-stable, OpenSSL 1.1.0l, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 
1.1.2.

<...>
Nov 21 00:18:03.000 [notice] Bootstrapped 0% (starting): Starting
Nov 21 00:18:07.000 [warn] Incorrect ed25519 signature(s)
Nov 21 00:18:10.000 [notice] Starting with guard context "default"
<...>

Should I open a ticket?___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths

[Logforme]

On 2019-08-06 23:31:39, "Rob Jansen"  wrote:


Today, I started running the speedtest on all relays in the network. So far, I 
have finished about 100 relays (and counting). I expect that the advertised 
bandwidths reported by metrics will increase over the next few days. For this 
to happen, the bandwidth histories observed by a relay during my speedtest are 
first committed to the bandwidth history table (within 24 hours), and then 
reported in the server descriptors (within 18-36 hours, depending on when the 
bandwidth history commit happens).


Looks like my relays got measured:
https://nerdin.se:12445/index.php/s/5LhwAzP61CHSJZ7
https://nerdin.se:12445/index.php/s/favR4ISXZKgICCa

My connection is 500 Mbit and the measurements got very close to that. 
Will be interesting to see if the observed BW increases.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dhcp lease question

[Logforme]

On 2019-05-05 14:32:52, to...@protonmail.com wrote:


Though I realize that my vision of the local "mom and pop" relays has gotten 
more and more outdated.
I think it's more important than ever. In my mind diversity is more 
important than throughput.
If everyone ran GBit relays at a few providers it would make Tor much 
less secure.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Making use of new bandwidth

[Logforme]

On 2019-04-07 23:57:58, "teor"  wrote:

It looks like your relay could be CPU-core-limited, or limited by some other
local resource, or limited by its location.
Currently the CPU is only using 40% of 1 core (out of 4). All of it from 
Tor when BW is close to 250Mbps
When routing from the LAN (iperf, downloading stuff etc) the machine 
easily pushes 500Mbps.
It can of course be other local resources that Tor needs. I have set a 
lot of networking parameters in sysctl.conf many years ago (from 
torservers,net I believe), but I don't really know what all of that 
stuff means.

As to limit by location (Sweden), not much to do about that :)


To work out where the limit is, run another Tor instance.

You could also wait another week to see if your relay picks up another 5-10%
traffic increase.
I'll wait a bit longer to see what happens and then run a second 
instance.


Thanks for an excellent reply___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Making use of new bandwidth

[Logforme]

I run the non-exit relay: 
https://metrics.torproject.org/rs.html#details/855BC2DABE24C861CD887DB9B2E950424B49FC34
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.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Circuit storms

[Logforme]

On 2019-01-31 14:19:31, "Felix"  wrote:

Hi everybody

Circuit storms observed of up to 100k and 250k per relay for over hours.
Consumed BW rises by about 10%. Number of stateful server connections is 
higher. Using Tor 356 to 401.

Anybody else observes that?
Only way I know to check circuits is in the heartbeat log entry. This is 
from my non-exit relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 (times 
are CET):


Jan 28 19:54:14.000 [notice] Heartbeat: Tor's uptime is 13 days 0:00 
hours, with 35896 circuits open. I've sent 14211.77 GB and received 
14106.51 GB.
Jan 29 01:54:14.000 [notice] Heartbeat: Tor's uptime is 13 days 6:00 
hours, with 29237 circuits open. I've sent 14539.93 GB and received 
14432.83 GB.
Jan 29 07:54:14.000 [notice] Heartbeat: Tor's uptime is 13 days 12:00 
hours, with 92728 circuits open. I've sent 14799.92 GB and received 
14690.98 GB.
Jan 29 13:54:14.000 [notice] Heartbeat: Tor's uptime is 13 days 18:00 
hours, with 30034 circuits open. I've sent 15101.99 GB and received 
14990.63 GB.
Jan 29 19:54:14.000 [notice] Heartbeat: Tor's uptime is 14 days 0:00 
hours, with 25523 circuits open. I've sent 15380.45 GB and received 
15266.78 GB.
Jan 30 01:54:14.000 [notice] Heartbeat: Tor's uptime is 14 days 6:00 
hours, with 29738 circuits open. I've sent 15647.01 GB and received 
15531.40 GB.
Jan 30 07:54:14.000 [notice] Heartbeat: Tor's uptime is 14 days 12:00 
hours, with 111604 circuits open. I've sent 15865.24 GB and received 
15747.97 GB.
Jan 30 13:54:14.000 [notice] Heartbeat: Tor's uptime is 14 days 18:00 
hours, with 241481 circuits open. I've sent 16141.80 GB and received 
16022.39 GB.
Jan 30 19:54:14.000 [notice] Heartbeat: Tor's uptime is 15 days 0:00 
hours, with 345729 circuits open. I've sent 16444.33 GB and received 
16322.55 GB.
Jan 31 01:54:14.000 [notice] Heartbeat: Tor's uptime is 15 days 6:00 
hours, with 78134 circuits open. I've sent 16727.10 GB and received 
16603.44 GB.
Jan 31 07:54:14.000 [notice] Heartbeat: Tor's uptime is 15 days 12:00 
hours, with 166024 circuits open. I've sent 16979.36 GB and received 
16853.91 GB.
Jan 31 13:54:14.000 [notice] Heartbeat: Tor's uptime is 15 days 18:00 
hours, with 32849 circuits open. I've sent 17283.65 GB and received 
17155.78 GB.


The last entries shows some peaks but it doesn't look like a sustained 
thing. "Normal" is around 30k as far as I can see.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] searching the tor-relays archives

[Logforme]

On 2018-10-30 16:51:42, to...@protonmail.com wrote:
Before I download months of gzipped archives and zgrep them myself, is 
there a way to search the messages themselves?  I'm looking at:

https://lists.torproject.org/pipermail/tor-relays/
but maybe there as another setup somewhere else.


I use Google
site:lists.torproject.org/pipermail/tor-relays "search words"

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] log "Is your outbound address the same as your relay address?"

[Logforme]

"Your relay has a very large number of connections to other relays. Is 
your outbound address the same as your relay address? Found 12
connections to 8 relays. Found 12 current canonical connections, in 0 
of which we were a non-canonical peer. 4 relays had more than 1 
connection, 0 had more than 2, and 0 had more

than 4 connections."
Quick google found this ticket: 
https://trac.torproject.org/projects/tor/ticket/24841

Looks like you can ignore this.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] torrelay on wan

[Logforme]

Hi to all, is it a god ide to setup torrelays directly on WAN port ?
Yes there are an firewall, but direkt in the torserver. So no extern 
firwall.



I run my relay on my firewall machine.
I have a headless debian server box set up to be firewall/router between 
the WAN and LAN NICs. It's also DHCP/DNS/NTP server for the LAN.
Since the machine have plenty of CPU and memory to spare I also run a 
Tor relay against the WAN NIC.


I guess putting too many eggs in one basket is a risk but it has worked 
well for many years now. So if you trust the Tor software enough to have 
it run on such a sensitive machine, go for it I say.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is Tor-network protected from using one hop?

[Logforme]

On 2018-06-26 16:16:46, "dave levi"  wrote:

I'm testing few things in Tor and I noticed that if im changing(from 
the source code) the number of hop's(nodes) to be more then 3 hop's it 
work's fine(slowly,  but still working) and if im sting only 2 hop's 
its still works great. but, when i'm setting only 1 hop, i can open the 
Tor-browser but i can't use it(Tor-browser) to visit site(regular site 
or onion site too). so im thinking maybe the Tor-network have protected 
from users who are using 1 hop?


I guess it's part of the DoS protection recently implemented. My guard 
relay DoS statistics in the heartbeat log entry:


[notice] DoS mitigation since startup: 0 circuits killed with too many 
cells. 232704 circuits rejected, 15 marked addresses. 2939 connections 
closed. 1534 single hop clients refused.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Refusing to apply consensus diff

[Logforme]

I run the non-exit relay 855BC2DABE24C861CD887DB9B2E950424B49FC34

Two days now I've seen this in my log file:

Jun 05 06:25:02.000 [warn] Refusing to apply consensus diff because the 
base consensus doesn't match the digest as found in the consensus diff 
header.
Jun 05 06:25:02.000 [warn] Expected: 
2E3DACFB12051F4A45F7F4DC062F6D47DC75DBA85EB72F8E5D43DF134940F2DA; found: 
1573CFF458492B70BFDD4E91A594521C4DDD801B11936B8C148BF27F67736713
Jun 05 06:25:02.000 [warn] Could not apply consensus diff received from 
server '128.31.0.34:9131'


(Repeated for 204.13.164.118, 131.188.40.189, 154.35.175.225, 
194.109.206.212, 171.25.193.9, 199.58.81.140)


First time I assumed it was just a glitch. Now I'm wondering if there is 
something I should do on my side?


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Number of connections on dir port

[Logforme]

After reading this post 
https://lists.torproject.org/pipermail/tor-relays/2018-May/015277.html I 
started looking into what is happening on the dir port on my relay 
(855BC2DABE24C861CD887DB9B2E950424B49FC34)


The bandwidth ratio of dir/or traffic is around 3% to 4%. Not excessive 
according to the linked post.


Looking at the conntrack table I see many IP addresses (usually from 
Ukraine or Russia) with 100+ connections. Atm there are around 10 IP 
addresses with 100+ connections and around 30 with 10+ connections. None 
of the IP addresses I've looked at are Tor relays.


Some questions:
Is this expected behaviour against on a fallbackdir flagged relay?
Does the DoS prevention implemented recently address abuse against the 
dir port?

I read that newer Tor clients don't use the dir port. Correct?
Do Tor relays use the dir port?
Can I remove the dir port from my relay without reducing my relays 
usability to the network?


Thank you for any answers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running A Bridge Alongside My Relay

[Logforme]

So I am considering running a bridge alongside my relay gotland

Would the bridge use the same public IP address as the relay?
Since you already run a relay, that IP address is public. The point of 
bridges is that they are not public so they are harder to block.
A government that censors the internet would surely block access to all 
Tor relay IP addresses.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DirPort DOS activity against Fallback Directories

[Logforme]

Just looked over a sample of FallBackDir relays in Relay Search and
it appears this excess-load abuse is directed at them in particular.
Some fall-back directories show more than a month of excess request
traffic, presumably on the DirPort.  Logs here indicate six weeks
of abuse escalating in increments.
How can I find this information on my relay? 
(855BC2DABE24C861CD887DB9B2E950424B49FC34)


The only weird stuff I've noticed is that memory usage have doubled. 
From 1.5GB to 3GB. Bandwidth is pegged at times, but not excessively so.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] New releases today: please consider upgrading.

[Logforme]

There are new security releases today.  The official announcement just
went to tor-announce, but I want to make sure that people on this list
see it too.

The debian package showed up today. I upgraded from 3.2.9 to 3.2.10 and 
removed my firewall connection limits.


My early first impressions are:

DDoS mitigation seems to be working.

CPU behavior has changed. Used to be around 100% (in htop) but the CPU 
frequencies was low (usually around 800MHz). With the new version the 
CPU usage is low, around 50%, but the CPU frequencies are around the 
maximum, 3800MHz, all the time (for all 4 cores). New code no longer 
allows the CPU to throttle down?


Was expecting the annoying "Channel padding timeout" log notifications 
to be gone, not so. Hopefully in the next version.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] scale_active_circuits assertion fail

[Logforme]

On 2018-02-20 22:37:42, "teor"  wrote:


Please open a ticket with the full stack trace, and your OS.
I opened a ticket: 
https://trac.torproject.org/projects/tor/ticket/25316#ticket

Please let me know if there is anything more you need to know

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] scale_active_circuits assertion fail

[Logforme]

My relay (855BC2DABE24C861CD887DB9B2E950424B49FC34) just crashed with 
the following error:
Feb 20 14:33:40.000 [err] tor_assertion_failed_(): Bug: 
../src/or/circuitmux_ewma.c:711: scale_active_circuits: Assertion 
e->last_adjusted_tick == pol->active_circuit_pqueue_last_recalibrated 
failed; aborting. (on Tor 0.3.2.9 )
Feb 20 14:33:40.000 [err] Bug: Assertion e->last_adjusted_tick == 
pol->active_circuit_pqueue_last_recalibrated failed in 
scale_active_circuits at ../src/or/circuitmux_ewma.c:711. Stack trace: 
(on Tor 0.3.2.9 )



The relay had been up for 23 days:
Feb 20 12:55:12.000 [notice] Heartbeat: Tor's uptime is 23 days 17:59 
hours, with 30352 circuits open. I've sent 20574.36 GB and received 
20125.28 GB.


When I checked htop earlier everything looked fine. Modest CPU and MEM 
usage.


What went wrong and what can I do to prevent this from happening again?

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Circuit padding timeouts

[Logforme]

No clue what it means and why it's necessary to spam the log file with 
it.
I did report my situation in the only ticket I could find that seems 
even vaguely appropriate: 
https://trac.torproject.org/projects/tor/ticket/22212


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard node suddenly sending twice what it receives

[Logforme]

Check the logs, but they won't tell you much, and that's deliberate.


So I checked the tor log.

First part is before the "weirdness":
Dec 20 16:00:08.000 [notice] Heartbeat: Tor's uptime is 4 days 23:59 
hours, with 36191 circuits open. I've sent 3686.92 GB and received 
3646.75 GB.
Dec 20 16:00:08.000 [notice] Circuit handshake stats since last time: 
160437/160437 TAP, 5003782/5003782 NTor.
Dec 20 16:00:08.000 [notice] Since startup, we have initiated 0 v1 
connections, 0 v2 connections, 1 v3 connections, and 102511 v4 
connections; and received 2151 v1 connections, 29819 v2 connections, 
46331 v3 connections, and 683484 v4 connections.


Next time during the weirdness:
Dec 20 22:00:08.000 [notice] Heartbeat: Tor's uptime is 5 days 5:59 
hours, with 233634 circuits open. I've sent 3908.13 GB and received 
3832.44 GB.
Dec 20 22:00:08.000 [notice] Circuit handshake stats since last time: 
564576/564576 TAP, 18285622/18285622 NTor.
Dec 20 22:00:08.000 [notice] Since startup, we have initiated 0 v1 
connections, 0 v2 connections, 1 v3 connections, and 107666 v4 
connections; and received 2309 v1 connections, 31585 v2 connections, 
49188 v3 connections, and 711324 v4 connections.


Note that the number of circuits have gone up from a relatively normal 
number, 36191, to a massive 233634. Definitely not normal.  And this is 
with my connection limits in place in the iptables.


The tor process now uses about twice as much CPU as normally.

I think the attacker has found a new way "in".

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Guard node suddenly sending twice what it receives

[Logforme]

My little guard node (855BC2DABE24C861CD887DB9B2E950424B49FC34) have 
suddenly started to behave strangely. iftop (my "bandwidth monitor"), 
shows twice as much sent traffic as received traffic. The traffic seems 
to be distributed to a lot of ip addresses. No ip address stands out as 
receiving very much traffic: https://imgur.com/a/dAUzc


Given the last few days of DDoS attacks (my node is still targeted by 
those) I naturally assume this is another attack.

First it is lots of connections (mitigated with connection limits)
Then it is massive amounts of memory per circuit (MaxMemInQueues fixes 
that)

And now this.

Could this be a third attack vector or am I seeing something "normal" 
(though I often check my bandwidth and I've never seen this before). My 
node recently got the HSDir flag after the last crash. Could the network 
be starved for HSDir machines and this is what I'm seeing?


Being a linux noob I don't know how to figure out exactly what kind of 
traffic this is. Suggestions gratefully accepted.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] botnet? abusing/attacking guard nodes

[Logforme]

My relay ran out of connections once and also crashed once so I followed 
the suggestions in the "DoS attacks are real (probably)" thread and 
implemented connection limits in my firewall. Everything have run 
smoothly since.


My only concern is how low I can set the number of connections per IP 
address. Someone wrote a legit client will only open max 2 tcp 
connections. I'd like this verified before I lower my limits further.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Too many connections warning

[Logforme]

I run the non-exit relay Logforme 
(855BC2DABE24C861CD887DB9B2E950424B49FC34).


Today I saw a new warning in my tor log file:
Dec 07 09:48:12.000 [warn] Failing because we have 32735 connections 
already. Please read doc/TUNING for guidance.


The relay runs on an old Debian Wheezy machine. Me being a Linux noob I 
tried to read the doc/TUNING document 
(https://gitweb.torproject.org/tor.git/tree/doc/TUNING) but the only 
information I deemed suitable for me was "Use ulimit -n", which I ran 
and it reported "1024". I guess that's not of interest for this warning.


Over the years I have added some stuff to my sysctl.conf file that I 
have picked up. Don't remember from where:

# Tor
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.core.rmem_default = 524287
net.core.wmem_default = 524287
net.core.optmem_max = 524287
net.core.netdev_max_backlog = 30
net.ipv4.tcp_mem = 33554432 33554432 33554432
net.ipv4.tcp_max_orphans = 30
net.ipv4.tcp_max_syn_backlog = 30
net.ipv4.tcp_fin_timeout = 4
vm.min_free_kbytes = 65536
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.ip_local_port_range = 1025 65530
net.core.somaxconn = 30720
net.ipv4.tcp_max_tw_buckets = 200
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_challenge_ack_limit = 9

None of the values seem to match the 32735 mentioned in the warning so 
I'm at a loss for what I am supposed to change.

Anyone knowledgeable of these things that can give me some pointers?


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] prop224 warning

[Logforme]

Saw a new thing in my tor log today:
Aug 01 11:07:27.000 [warn] Established prop224 intro point on circuit 
799774346


According to google, prop224 is a new hidden service protocol?
https://trac.torproject.org/projects/tor/ticket/12424

Which sounds like a great thing. But why do I get a warning about it?

My relay:
https://atlas.torproject.org/#details/855BC2DABE24C861CD887DB9B2E950424B49FC34

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit / Bad Gateway

[Logforme]

On 2017-06-27 12:35:21, "Sebastian Urbach"  wrote:

Dear list,

My Exit:

https://atlas.torproject.org/#details/4198BD138E5E11B15B05C826B427148CED7D99FE

My Consendus Weight dropped to 20 today and i found the following in 
notices.log:


Jun 27 12:03:35.000 [warn] http status 502 ("Bad Gateway") reason 
unexpected while uploading descriptor to server '154.35.175.225:80').
Jun 27 12:07:35.000 [warn] Received http status code 502 ("Bad 
Gateway") from server '154.35.175.225:80' while fetching 
"/tor/server/d/C8B7BA97808F42802FCC2DF231A85ACB5B8D848A.z". I'll try 
again soon.


Any ideas what to do or just sit it out ?
-- Sincerely yours / M.f.G. / Sincères salutations

Sebastian Urbach
Same for my non-exit: 
https://atlas.torproject.org/#details/855BC2DABE24C861CD887DB9B2E950424B49FC34


Looks like the drop in cw coincided with messages like these in the log:
Jun 27 04:35:48.000 [warn] Received http status code 502 ("Bad Gateway") 
from server '154.35.175.225:80' while fetching 
"/tor/server/d/44C3629D79C5366209DB976F1F1588A39B923123+C4716B2DA2AB2CAC2DA0256CD2484050B75371BF.z". 
I'll try again soon.



154.35.175.225 is the authority server faravahar which have had network 
issues in the past.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] 0.2.9.10 dir port warning

[Logforme]

Just upgraded my relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 to 
0.2.9.10 and now I get a new warning in the log file:


Mar 13 12:02:22.000 [notice] Bootstrapped 100%: Done
Mar 13 12:03:20.000 [warn] Cannot make an outgoing connection without a 
DirPort.
Mar 13 12:03:21.000 [notice] Self-testing indicates your DirPort is 
reachable from the outside. Excellent. Publishing server descriptor.


Everything is working fine, just curious about the warning. Is it an 
actual problem with my setup or a quirk of 0.2.9.10?


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] new warn message: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS.

[Logforme]

I had 3 today on my non-exit relay. Can't remember seeing them before. 
Maybe they are new in 0.2.8.8?

Times are UTC+2

Oct 06 09:14:03.000 [warn] Duplicate rendezvous cookie in 
ESTABLISH_RENDEZVOUS.
Oct 06 14:08:13.000 [warn] Duplicate rendezvous cookie in 
ESTABLISH_RENDEZVOUS.
Oct 06 14:08:14.000 [warn] Duplicate rendezvous cookie in 
ESTABLISH_RENDEZVOUS.


-- Originalmeddelande --
Från: "Toralf Förster" 
Till: tor-relays@lists.torproject.org
Skickat: 2016-10-06 10:45:49
Ämne: [tor-relays] new warn message: Duplicate rendezvous cookie in 
ESTABLISH_RENDEZVOUS.



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Today I got this for the first since I run exits:

 Oct 06 08:23:03.000 [warn] Duplicate rendezvous cookie in 
ESTABLISH_RENDEZVOUS.


Something I should worry about ?

- --
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlf2Dz0ACgkQxOrN3gB26U5LMAD+POAhOITGeYh5CFdOwFxgfzMf
510EN+mxt+3nTAFXgrIA/1BUXnr1DXh61y5ttIxSoVGJb95r8FTrnKiDTZ23yBkV
=vFhm
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Why can't I see more traffic? (is my banana too weak?)

[Logforme]

Looking at Atlas your relay advertises 2.45 MB/s which is quite low for 
a 100Mbit connection: 2.45 MByte x 8 = 19.6 MbitWhat value do you have 
in your torrc? For a 100mbit connection it should be at least: 
BandwidthRate 12 MB



-- Originalmeddelande --
Från: "Roman Mamedov" 
Till: "Aeris" 
Kopia: tor-relays@lists.torproject.org; "Farid Joubbi" 
Skickat: 2016-09-03 17:14:08
Ämne: Re: [tor-relays] Why can't I see more traffic? (is my banana too 
weak?)



On Sat, 03 Sep 2016 16:53:25 +0200
Aeris  wrote:

 > Could it be that it is due to the quite slow hardware, even though 
I know

 > that it is able to push more traffic?

 Yep, surely.

 You currently push 3Mbps of traffic, which is correct for this kind 
of hardware.
 All "cheap" hardware (raspi, banana, olimex, pine…) suffer of the 
fact they
 don’t have crypto hardware acceleration and do software encryption. 
And so is
 very slow (10-100× factor) even compared to low end amd64 CPU with 
AES-NI

 extension.


According to 'openssl speed aes-128-cbc' the Allwinner A20 CPU in 
Banana Pro is
capable of about 25 MBytes/sec in AES performance. While that won't 
translate
1:1 into Tor performance, as Farid noted in his case the CPU isn't 
being a

bottleneck, with only 10-20% CPU load observed.

@Farid,


 According to top the CPU hovers around 10-20% most of the time.


I wonder is it 20% across both cores, which could be 40% of one core 
(since
Tor is not multithreaded enough), and at least somewhat closer to not 
being

practically idle. Can you launch 'top' and press '1' there to check?

Also seems unclear why it didn't get the guard flag for so long, does 
your
public IP address change from time to time? Or do you turn the relay 
off and

on for whatever reason.

--
With respect,
Roman___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[Logforme]

My relay, Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34), is not on
the list even though it fits all the criteria, except the HSDir flag
which I lost when I upgraded to the latest version.
Hint, hint, Mr Roger "We should somehow teach everybody that losing
their flags for a few days is totally fine" Dingledine :)

Anyhow, I'm glad to opt in my relay if you'll have it

On 2015-12-17 15:07, Nick Mathewson wrote:
> TL;DR: Stable non-exit relays can help tor clients use the Tor
> network. Please opt-in!
>
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] uptime "algorithm"

[Logforme]

On 2015-12-14 19:12, Dr. Who wrote:
> Wouldn't it be better to monitor the reason for a drop in uptime? In
> case at the same time a restart occurs the version increases it might be
> given the HSdir flag again?
>
Can't see why, for example the Debian /etc/init.d/tor script, couldn't
send tor a flag telling it that this is a restart, causing tor to
save/restore its uptime information. Circuits auto-reconnect if the
downtime is short enough, right?

  restart)
check_config

$0 stop -saveuptimeinfo $UPTIMEFILE
sleep 1
$0 start -restoreuptimeinfo $UPTIMEFILE

Not losing my flags would at least make me upgrade tor more frequently.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Faravahar messing with my IP address

[Logforme]

Happened again tonight:

Nov 04 05:23:43.000 [notice] Our IP Address has changed from
84.219.173.60 to 185.99.185.61; rebuilding descriptor (source:
154.35.175.225).
Nov 04 05:23:43.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent. Publishing server descriptor.
Nov 04 05:23:43.000 [notice] Our IP Address has changed from
185.99.185.61 to 84.219.173.60; rebuilding descriptor (source:
154.35.175.225).
Nov 04 05:23:43.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent. Publishing server descriptor.

84.219.173.60 <- My real IP address
185.99.185.61 <- Holland?
154.35.175.225 <- faravahar.redteam.net

Not even a second between getting the wrong IP and then getting the
correct one back, but enough to restart the relay.
After seeing this I upgraded to the latest version 0.2.7.4-rc and on the
restart it again used Faravahar to (correctly) guess the IP:

Nov 04 07:47:49.000 [notice] Guessed our IP address as 84.219.173.60
(source: 154.35.175.225).


On 2015-10-22 20:38, SiNA Rabbani wrote:
> Dear Relay Operator,
>
> I am the operator of Faravahar, It has been having some network issues,
> specifically very long latency. But this is the first time I hear of an issue 
> like this.
>
> 154.35.32.5 is Faravahr's older IP addresses which was replaced with and 
> 154.35.175.225 is the new IP (current). 
>
> There are iptable rules forwarding the traffic from OLD IP to the new one
> for the clients that have not updated yet. 
>
> Are you running the latest version of tor software?
>
> I'll be sure to keep an eye on this email and open a ticket as needed.
>
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Faravahar messing with my IP address

[Logforme]

I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC34)

Saw this in yesterday's log file:
Oct 22 03:17:55.000 [notice] Our IP Address has changed from
84.219.173.60 to 154.35.32.5; rebuilding descriptor (source:
154.35.175.225).
Oct 22 03:17:55.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent. Publishing server descriptor.
Oct 22 03:17:56.000 [notice] Performing bandwidth self-test...done.
Oct 22 03:26:55.000 [notice] Our IP Address has changed from 154.35.32.5
to 84.219.173.60; rebuilding descriptor (source: 194.109.206.212).

84.219.173.60: <- My real IP address
154.35.32.5: faravahar.rabbani.jp <- No idea
154.35.175.225: faravahar.redteam.net <- Authority server
194.109.206.212: tor.dizum.com <- Better authority server

So if I read it right my relay asked the authority server Faravahar what
my IP address is and got the wrong answer. 9 minutes later my relay
asked another authority server and got the right answer. My relay show
an uptime starting from this time and if the relay did a full restart it
meant all the circuits got dropped? Inconvenient for users.

My relay have "restarted" like this a few times the last weeks (only Tor
daemon "restarting", not the machine). Don't know if Faravahar is behind
the other "restarts". This time I just caught it in the log file before
it got archived.

Is this a know issue with Faravahar? If so, should it be fixed?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] circuit_unlink_all_from_channel

[Logforme]

FYI
I run the relay 855BC2DABE24C861CD887DB9B2E950424B49FC34. Today I found
a message in the log file I have not seen before:

Jun 26 18:05:20.000 [warn] circuit_unlink_all_from_channel(): Bug:
Circuit on detached list which I had no reason to mark

Relay continues to run fine with 30 days uptime.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Out of memory message

[Logforme]

On 2014-12-15 19:43, Nick Mathewson wrote:
 On Wed, Dec 10, 2014 at 2:31 AM, Roger Dingledine a...@mit.edu wrote:
 On Sun, Dec 07, 2014 at 01:43:46PM +0100, Logforme wrote:
 To me it looks like an attacker that ramped up over a 6 hour period and
 then stopped building new circuits. Since the tor process still uses all
 available memory (more than 24 hours later) I guess the attacker still
 holds some circuits open.
 Careful with your conclusion there -- because of memory fragmentation, the
 process can still hold the memory even when Tor has freed the memory. That
 happens because some part of the memory page is in use and some is freed,
 but since not all of it is freed the allocator doesn't take it back.

 Some quick searches point to
 https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_native_memory_fragmentation_and_process_size_growth
 as what looks like a nice summary of the issue.

 --Roger
 If this *is* memory fragmentation, one possible reason why it would
 have started appearing recently might be that we turned the freelist
 code off by default in 0.2.5, on the theory that it should be safer to
 do that than not.

 https://trac.torproject.org/projects/tor/ticket/11476 has more
 background here.  I don't think it's the likeliest explanation, but
 it's worth examining.

 Are the people experiencing this issue using similar allocators?


I don't build Tor myself, I use the latest debian package:
0.2.5.10-1~d70. No idea how that is built.

I have not restarted Tor so it is still hogging all ram + swap (relay
works fine so no reason to restart). If there is anything I can run to
get more information about what has happened (code dump maybe?), I'm
happy to do so.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Out of memory message

[Logforme]

On 2014-12-10 08:31, Roger Dingledine wrote:
 Careful with your conclusion there -- because of memory fragmentation,
 the process can still hold the memory even when Tor has freed the memory.
htop currently shows 3622/3858 Mem used and 1545/3136 Swap used. (if I
remember correctly it's usually less than 1000 Mem and 0 Swap used).
So the attacker (intentional or accidental) actually managed to make Tor
take all free memory on the machine before the MaxMemInQueues function
stepped in. And now I have no way to release that memory short of
restarting tor. If I used the machine for something apart from tor it
would have been a successful attack.
Guess I need to set the MaxMemInQueues parameter to something other than
0, maybe 2GB? What's the reasonable default for MaxMemInQueues? Some
percentage of total RAM?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Out of memory message

[Logforme]

I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC3).
Yesterday I saw new messages in the log file:
Dec 06 09:28:13.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 06 09:28:16.000 [notice] Removed 1040388096 bytes by killing 1
circuits; 14631 circuits remain alive.

Do I read that correctly as one circuit using 1GB of memory?

Here's the first lines from the top command:
top - 09:40:41 up 31 days,  1:51,  1 user,  load average: 0.53, 0.62, 0.66
Tasks:  95 total,   3 running,  92 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10.2 us,  2.0 sy,  0.0 ni, 83.2 id,  0.0 wa,  0.0 hi,  4.5 si, 
0.0 st
KiB Mem:   3950828 total,  3833092 used,   117736 free,49696 buffers
KiB Swap:  3212284 total,  1296392 used,  1915892 free,99168 cached

  PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND
 2680 debian-t  20   0 4134m 2.8g  24m R  63.5 73.4  27199:00 tor

The relay is running on a dedicated debian box with 4GB of ram. It
usually only uses about 0.5GB but now it is maxed out. The relay and the
box is so far working fine, I just wonder if this is some kind of attack
or if anything is wrong and if there is anything I should do about it.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Out of memory message

[Logforme]

On 2014-12-07 12:20, Roger Dingledine wrote:
 Has anybody else here seen messages like this?

I looked through the old log files and found the following memory messages:
Dec 06 03:33:06.000 [notice] Removed 334229280 bytes by killing 1
circuits; 16401 circuits remain alive.
Dec 06 05:27:25.000 [notice] Removed 476998896 bytes by killing 1
circuits; 15628 circuits remain alive.
Dec 06 06:08:35.000 [notice] Removed 536296464 bytes by killing 1
circuits; 16215 circuits remain alive.
Dec 06 06:56:58.000 [notice] Removed 583650144 bytes by killing 1
circuits; 15617 circuits remain alive.
Dec 06 07:55:57.000 [notice] Removed 857511072 bytes by killing 1
circuits; 15423 circuits remain alive.
Dec 06 09:28:16.000 [notice] Removed 1040388096 bytes by killing 1
circuits; 14631 circuits remain alive.

To me it looks like an attacker that ramped up over a 6 hour period and
then stopped building new circuits. Since the tor process still uses all
available memory (more than 24 hours later) I guess the attacker still
holds some circuits open. To what end I can't understand. He failed to
crash the relay but wants to occupy my RAM? :)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Unexpected sendme cell from client. Closing circ (window 1000). error message.

[Logforme]

Update to the latest version of tor: 0.2.5.10
I believe that resolution was clearly stated here. And also mentioned in
the announcement of 0.2.5.10
https://blog.torproject.org/blog/tor-02510-released-and-tor-023x-deprecated
Downgrade the severity of the 'unexpected sendme cell from client' from
'warn' to 'protocol warning'. Closes ticket 8093. 

On 2014-11-06 18:38, K. Besig wrote:
 Thanks for all the informative responses, they were truly underwhelming...


 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bwauths Measures question, friends.

[Logforme]

The relay is reported as having Advertised Bandwidth: 60.55 kB/s
(about 480 kbits/s):
https://globe-node.herokuapp.com/relay/48ADFCC561402D7EBB1CDE233F206B01D8FA0765
What does your bandwidth rate values in torrc say?

On 2014-11-01 10:46, Rafael Rodriguez wrote:

 Anyone knows how often bwauths measures a relay? I don't understand
 why directory authorities have not lifted the 20KB cap for my older
 relay. Now I have doubts if it could be a problem with my server. This
 is a 2MB/s relay with burst of 4MB/s to start tuning it and increase
 it later if stable, which is not being used and has been running for
 over 3 days. Is it normal for Relays to take longer than three days to
 start getting at least some traffic and for directory authorities to
 lift the 20KB cap?

 Fingerprint 48ADFCC561402D7EBB1CDE233F206B01D8FA0765

  



 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Windows Tor Server Guide

[Logforme]

Click on the Download button on torproject.org. This brings you to the
easy download page with just the browser bundle. Click on the View
All Downloads link to get all available options:
https://www.torproject.org/download/download.html.en

On 2014-10-31 09:18, Rafael Rodriguez wrote:

 Hello fellows,

 Where can we contribute (post a guide) to deploy Tor in Windows
 without the extras unneeded stuff? I was looking for a Tor Server
 installation guide on Windows to run Tor as a service. I did not
 wanted to install all the extra browser stuff but a plain Tor server
 service and secure it by giving the service its own limited account
 and write permissions just to the datadir. Since I couldn't find
 information online to help me out, I ended up using the latest Tor
 Browser package and removing everything except Tor itself and deployed
 it in two Windows servers as services. I would like to post somewhere
 in the Top project about the process for others to benefit from it.



 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Hash of session info was not as expected

[Logforme]

My tor log file is usually quite boring but today it looks like this:
Jun 14 13:42:46.000 [warn] Hash of session info was not as expected.
Jun 14 13:57:56.000 [warn] Hash of session info was not as expected.
Jun 14 14:11:58.000 [warn] Hash of session info was not as expected.

A new line about every 10 minutes since  04:14:53 (CET)

Is it a user with problems, an attack on my relay or a sign that my
relay have some kind of hardware/software issues?

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Botnet issues and upgrading to 0.2.4.x

[Logforme]

On 2013-10-14 22:01, Chris Whittleston wrote:
 I see - so I'll probably still see the problem with a huge number of
 circuits being created after I've finished building 0.2.4. Is there
 any way to limit this, I'm guessing reducing the bandwidth wouldn't
 actually help? I guess I'll look into how much further I can overclock
 the CPU...
Only option that I know of is to reduce the bandwidth you advertise to
the network. The more bandwidth you advertise the more circuits the tor
network will throw at your relay. The following flags in the torrc file
can be used (with my current understanding of them):
BandwidthRate : The max bandwidth you provide over a long period of time
BandwidthBurst : The max bandwidth you provide over a short period of time
MaxAdvertisedBandwidth : The max bandwidth you tell the tor network about
So you can set BandwidthRate to the real max you want to provide and
then set MaxAdvertisedBandwidth to a number low enough to prevent
circuit overload.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Too little traffic on my #2 non-exit relay

[Logforme]

Weird that #1 has the stable flag and #2 don't then.
Stable -- A router is 'Stable' if it is active, and either its
Weighted MTBF is at least the median for known active routers or its
Weighted MTBF corresponds to at least 7 days.
The above suggests that #1 has been known to the dirauths for a while
(since it got stable) and #2 either restarts a lot or has not been
around for long.

On 2013-09-18 20:41, Christian Dietrich wrote:
 Thanks, but both relays have been started at the same time.
 Due to the fact that they also have the same configuration,
 both should offer up to 1 gigabit/s bandwidth.

 RelayBandwidthRate 125 MBytes
 RelayBandwidthBurst 125 MBytes

 Both relays are exactly the same, except for the IPv4 adress.

 Your #2 relay is only advertising 83.96 KB/s so it's no surprise it gets
 low traffic.
 Can it be that #1 is an old relay and #2 is relatively new? If #2 is new
 it needs time to ramp up traffic:
 https://blog.torproject.org/blog/lifecycle-of-a-new-relay

 On 2013-09-18 18:57, Christian Dietrich wrote:
 Hey there,

 I'm currently running two tor (non-exit) relays on one host machine.
 myTOR1 and myTOR2.
 Now my problem is that tor relay #2 generates almost no traffic.

 https://atlas.torproject.org/#search/myTOR

 Log Relay #1:
 Circuit handshake stats since last time: 1566234/14743525 TAP,
 10428/10433 NTor.
 Heartbeat: Tor's uptime is 7 days 6:00 hours, with 56008 circuits
 open. I've sent 2167.46 GB and received 1567.97 GB.

 Log Relay #2:
 Circuit handshake stats since last time: 63/63 TAP, 1/1 NTor.
 Heartbeat: Tor's uptime is 7 days 6:00 hours, with 4 circuits open.
 I've sent 1.58 GB and received 844.66 MB.

 Both have the same binary and configuration (except incoming/outgoing
 IPv4). I've also tried to switch from
 fully self compiled debian, with custom kernel, and own tor binary
 to Out of the Box Ubuntu LTS, with torproject tor package
 .. without any improvement. Both relays works as expected.

 OT: for my opinion avg 150 mbit/s (99% done by node #1) is too less
 for an Ivy-Bridge Based Xeon Quad Core (/w HT) on an unshared gigabit
 line.
 Apart from the fact that multithread support is really missing.

 Can anyone give me a hint, or am i just too stupid? Thanks ;)
 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?

[Logforme]

Don't know if it's of interest but here's my log for the first 24 hours
with 0.2.4.17-rc:

Sep 05 17:23:59.000 [notice] Circuit handshake stats since last time:
435758/1722581 TAP, 1503/1503 NTor.
Sep 05 18:23:59.000 [notice] Circuit handshake stats since last time:
167983/1616396 TAP, 1427/1427 NTor.
Sep 05 19:23:59.000 [notice] Circuit handshake stats since last time:
155229/1908153 TAP, 1460/1460 NTor.
Sep 05 20:23:59.000 [notice] Circuit handshake stats since last time:
149878/1098074 TAP, 892/893 NTor.
Sep 05 21:23:59.000 [notice] Circuit handshake stats since last time:
52844/53765 TAP, 163/163 NTor.
Sep 05 22:23:58.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with
41076 circuits open. I've sent 174.17 GB and received 173.63 GB.
Sep 05 22:23:58.000 [notice] Average packaged cell fullness: 99.124%
Sep 05 22:23:58.000 [notice] TLS write overhead: 8%
Sep 05 22:23:59.000 [notice] Circuit handshake stats since last time:
160430/610010 TAP, 636/636 NTor.
Sep 05 23:23:59.000 [notice] Circuit handshake stats since last time:
176536/1080440 TAP, 893/893 NTor.
Sep 06 00:23:59.000 [notice] Circuit handshake stats since last time:
227181/471650 TAP, 497/497 NTor.
Sep 06 01:23:59.000 [notice] Circuit handshake stats since last time:
13170/13170 TAP, 96/96 NTor.
Sep 06 02:23:59.000 [notice] Circuit handshake stats since last time:
8569/8569 TAP, 54/54 NTor.
Sep 06 03:23:59.000 [notice] Circuit handshake stats since last time:
9512/9512 TAP, 28/28 NTor.
Sep 06 04:23:58.000 [notice] Heartbeat: Tor's uptime is 12:00 hours,
with 29242 circuits open. I've sent 366.41 GB and received 367.47 GB.
Sep 06 04:23:58.000 [notice] Average packaged cell fullness: 99.172%
Sep 06 04:23:58.000 [notice] TLS write overhead: 7%
Sep 06 04:23:59.000 [notice] Circuit handshake stats since last time:
18198/18198 TAP, 36/36 NTor.
Sep 06 05:23:59.000 [notice] Circuit handshake stats since last time:
242477/242488 TAP, 211/211 NTor.
Sep 06 06:23:59.000 [notice] Circuit handshake stats since last time:
500718/515154 TAP, 414/414 NTor.
Sep 06 07:23:59.000 [notice] Circuit handshake stats since last time:
531879/710244 TAP, 493/493 NTor.
Sep 06 08:23:59.000 [notice] Circuit handshake stats since last time:
383965/671463 TAP, 493/493 NTor.
Sep 06 08:40:51.000 [notice] We stalled too much while trying to write
26 bytes to address [scrubbed].  If this happens a lot, either something
is wrong with your network connection, or something is wrong with
theirs. (fd 4456, type Control, state 1, marked at
../src/or/control.c:3199).
Sep 06 09:23:59.000 [notice] Circuit handshake stats since last time:
265395/1064314 TAP, 795/795 NTor.
Sep 06 10:23:58.000 [notice] Heartbeat: Tor's uptime is 18:00 hours,
with 36700 circuits open. I've sent 583.44 GB and received 581.96 GB.
Sep 06 10:23:58.000 [notice] Average packaged cell fullness: 99.056%
Sep 06 10:23:58.000 [notice] TLS write overhead: 7%
Sep 06 10:23:59.000 [notice] Circuit handshake stats since last time:
168102/1572079 TAP, 1122/1122 NTor.
Sep 06 11:23:59.000 [notice] Circuit handshake stats since last time:
178546/1670183 TAP, 1164/1164 NTor.
Sep 06 12:23:59.000 [notice] Circuit handshake stats since last time:
196819/1920708 TAP, 1075/1075 NTor.
Sep 06 13:23:59.000 [notice] Circuit handshake stats since last time:
167932/2339171 TAP, 1231/1232 NTor.
Sep 06 14:23:59.000 [notice] Circuit handshake stats since last time:
163987/2175009 TAP, 1317/1317 NTor.
Sep 06 15:23:59.000 [notice] Circuit handshake stats since last time:
150523/2308715 TAP, 1378/1378 NTor.
Sep 06 16:23:54.000 [notice] Circuit handshake stats since last time:
154256/2283175 TAP, 1316/1316 NTor.
Sep 06 16:23:58.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00
hours, with 39815 circuits open. I've sent 795.24 GB and received 787.22 GB.
Sep 06 16:23:58.000 [notice] Average packaged cell fullness: 99.051%
Sep 06 16:23:58.000 [notice] TLS write overhead: 7%

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?

[Logforme]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Upgraded to 0.2.4.17-rc and almost immediately got the following in my
syslog:
debian kernel: [5000394.949751] TCP: Possible SYN flooding on port 443.
Sending cookies.  Check SNMP counters.
No idea what it means. 443 is my or port. Tor is running fine and
bandwidth usage is growing. 50mbit/s atm.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (MingW32)
 
iQEcBAEBAgAGBQJSKJ5vAAoJEJ4b+e/7JJoUgnkIAJryAwVtekZMvwtFdfOTzO9c
sKE1gxcvxdWJxD44UGUrIv88s5G9ROwU0e37LCW+L5YNWCCA/k0KS4ueZh8CFVXL
DBK8b8XD5IXwSa5o2tex9P0BADj+pTl4ShqfIS/diOJukWEDfICgKh/Xa86GaDvo
dbvEtKd6WqT8HbiP7TtlkJonAYDgOIb6mNre7a1W7sNAmwb2GLDZFX2BoAM+0rQK
Sdb+oOtylO/12z0GK/YYVNvmxgJXf+GrGB24axCTZEwYAXPga3MAJkr0M3RcMNKx
27ViTkwQZxafjVR2+JXBWb8Bn7RnxO40GMI9ZE8F+Pa2jR2cVrUcEv84+aCDjgk=
=W3uU
-END PGP SIGNATURE-

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] huge increase in relay traffic

[Logforme]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
 I'm currently seeing more than a doubling of connections (from a mean of
 c. 2000 established connections to just over 5000) on my relay at
 0xbaddad. The log is full of the (expected) messages:
 Your computer is too slow to handle this many circuit creation
 requests!

 I guess this is related to the massive jump in connected clients
 in the past few days and I assume that everyone else is seeing
 something similar.
Same situation here.
My speculation is that someone read about the childporn site that got
busted, figured the tor network is evil and bought a botnet to try to
Ddos it.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (MingW32)
 
iQEcBAEBAgAGBQJSIMYVAAoJEJ4b+e/7JJoU6usIAM3+PtlKF7z5T8OnETAOIc+a
MV/KjdatONIx89J820a24VftbXAhP3FAjdzFhWWXdQOAue2Q8PCdDrXUde6n3wcI
/2Y6k5caQe7MwMIQnB29pgsLzbqeOoTdacQYsrVcbZCpSA7MhruPyJ7mVR/ToZHc
6oWF3U3NRYs4aZb5wiNfY1KuWA5qdh9VanObfpGTO9n3xx72YqMWvHGf1n5lDKzV
q4BX2cdEXgjPzfuYXil6ZeNhm3sYFgUXVWBcllNZjZbzIsDfl6fHoe1Z3n0OhNOt
nKnqtHxPQvveUgxmo+kcjmCYF2tzK5pgHaBNAS1JI08A+MnfeOChHL4VmBzB5ks=
=ZSDj
-END PGP SIGNATURE-

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Yet another underpowered relay?

[Logforme]

Thanks for all the input guys.

See some advice here: 
http://archives.seul.org/or/relays/Aug-2010/msg00034.html
Found that before and I have followed it to the letter when I set up the 
relay


Also are you running with a lot of iptables/ip6tables rules active (or 
any at
all)? If you do, consider rewriting them so that at least 'conntrack' 
is not
used (check that you can do rmmod ipt_conntrack cleanly, or it's not 
loaded

in the first place).

No iptables rules active, and conntrack is not loaded.


Make sure you have the most recent OpenSSL library, with the
ec_nistp_64_gcc_128 optimizations enabled.  (Tor will print a big
nasty warning on startup if the library is new enough but the
optimizations aren't available.)
I have the latest OpenSSL library installed (version 1.0.1e-2) and no 
complaints from tor when it starts up.



You may get better utilization out of your CPU by running multiple tor
daemons (try 4 to start) each with MaxCPUs=1 and bandwidth cap set to
1/N of the total available.  They each have to be configured to use a
distinct ORPort and state directory, and should all be tagged as the
same family.
I have been thinking about this but I'm reluctant to partition my 
bandwidth. I'm afraid it will end up like harddrive partitions: lots of 
wasted space. i.e. one daemon hitting the bandwidth cap while the other 
is under utilized.



That CPU is powerful enough to handle 80 Mbps assuming there's no
hardware performance problems; a similar Xeon handles around 140 Mbps
per core.
Since the CPU is supposed to be able to handle 80mbit bandwidth I would 
much prefer to find out what the current problem is and continue to run 
with one daemon.


More info about the system:
OS: debian 7.1. Only other thing running on the box is 2 GPU apps from 
Einstein@Home which use about 1/3 CPU core each.

NIC: RTL-8169 on the motherboard.

The messages only appear about 1 to 5 times a day even though the 
bandwidth usage is mostly at the 80mbit cap. My guess is that some users 
create enormous amounts of circuits and my CPU fails to handle them.

Any other tips for what I could look at?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How does CERT-FI know my SOCKS4 port?

[Logforme]

I assume the ISP did a port scan. Do you have port 9050 open in your 
firewall?


On 2013-07-10 15:57, Steve Snyder wrote:
My ISP recently sent to me a CERT-FI auto-report on malware-infected 
servers in my ISP's address space.  I was send this report because my 
IP address was among those flagged.  My entry looks like this:


51765|aa.bbb.ccc.dd|2013-07-08 02:39:23 
+|||Proxy|743230|Datasource: C, Type: SOCKS4 (9050)


I am wondering how CERT-FI knows about this port.  This is a snippet 
of my relay config:


OutboundBindAddress aa.bbb.ccc.dd
ORPort [aa.bbb.ccc.dd]:443
DirPort [aa.bbb.ccc.dd]:80
SocksPort [127.0.0.1]:9050

Given that my SOCKS port is bound to localhost, how does CERT-FI know 
about it?


(For more info on the auto-reporter, go to 
https://www.cert.fi/en/autoreporter/autoreporter.html and log into it 
with this username/password: auto/reporter)


Thanks.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays