Outcome of a script to count # connections /24 range
11 188.214.30.* 20 37.48.104.* 22 37.48.86.* 33 5.79.72.* 48 212.32.226.* 97 212.32.239.* 197 149.202.66.* 294 5.79.103.* 303 198.7.59.* 358 207.244.110.* 380 162.210.192.* 394 207.244.70.* 395 199.115.112.* 499 54.36.51.*
And that on my lowly relay (consesus of 1k)
Other relays seeing this too?
On 4 Jan 2018, at 08:52, r1610091651 r1610091651@telenet.be wrote:
Outcome of a script to count # connections /24 range
11 188.214.30.* 20 37.48.104.* 22 37.48.86.* 33 5.79.72.* 48 212.32.226.* 97 212.32.239.* 197 149.202.66.* 294 5.79.103.* 303 198.7.59.* 358 207.244.110.* 380 162.210.192.* 394 207.244.70.* 395 199.115.112.* 499 54.36.51.*And that on my lowly relay (consesus of 1k)
Other relays seeing this too?
Yes, there are about a million extra clients on the network since December. See this email for details:
https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html
If this is causing your relay issues, here are the things you can try:
RAM:
Set MaxMemInQueues to half your available RAM per tor instance. (It doesn't track all of Tor's memory usage.)
If your machine has one relay, if you have this much RAM, try this setting: 4 GB -> MaxMemInQueues 512 MB 8 GB -> MaxMemInQueues 2 GB 16 GB -> MaxMemInQueues 4 GB 32 GB -> MaxMemInQueues 8 GB
(If you have more than one relay on the machine, divide MaxMemInQueues by the number of relays. If you still have RAM issues, take down one relay.)
File descriptors / sockets:
Increase file descriptors for your tor user, or set ConnLimit to the number of file descriptors available to tor.
CPU:
Set MaxAdvertisedBandwidth lower to shift client load to other relays.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Hi teor
Thanks for the reply. I'm not having issues with my relay, and I've seen the mail about extra users indeed. Just an observation, as I've just noticed few waves of these in last couple of hours. The start very abruptly and end just as well. Not an expert, but I find it statistically significant to receive so many connections (499 for one /24) form a single subnet to one specific middle node. Unless that can be explained.
Regards
On Wed, 3 Jan 2018 at 23:25 teor teor2345@gmail.com wrote:
On 4 Jan 2018, at 08:52, r1610091651 r1610091651@telenet.be wrote:
Outcome of a script to count # connections /24 range
11 188.214.30.* 20 37.48.104.* 22 37.48.86.* 33 5.79.72.* 48 212.32.226.* 97 212.32.239.* 197 149.202.66.* 294 5.79.103.* 303 198.7.59.* 358 207.244.110.* 380 162.210.192.* 394 207.244.70.* 395 199.115.112.* 499 54.36.51.*And that on my lowly relay (consesus of 1k)
Other relays seeing this too?
Yes, there are about a million extra clients on the network since December. See this email for details:
https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html
If this is causing your relay issues, here are the things you can try:
RAM:
Set MaxMemInQueues to half your available RAM per tor instance. (It doesn't track all of Tor's memory usage.)
If your machine has one relay, if you have this much RAM, try this setting: 4 GB -> MaxMemInQueues 512 MB 8 GB -> MaxMemInQueues 2 GB 16 GB -> MaxMemInQueues 4 GB 32 GB -> MaxMemInQueues 8 GB
(If you have more than one relay on the machine, divide MaxMemInQueues by the number of relays. If you still have RAM issues, take down one relay.)
File descriptors / sockets:
Increase file descriptors for your tor user, or set ConnLimit to the number of file descriptors available to tor.
CPU:
Set MaxAdvertisedBandwidth lower to shift client load to other relays.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 4 Jan 2018, at 09:52, r1610091651 r1610091651@telenet.be wrote:
Hi teor
Thanks for the reply. I'm not having issues with my relay, and I've seen the mail about extra users indeed. Just an observation, as I've just noticed few waves of these in last couple of hours. The start very abruptly and end just as well. Not an expert, but I find it statistically significant to receive so many connections (499 for one /24) form a single subnet to one specific middle node. Unless that can be explained.
If they are connecting to middle nodes directly, and handling consensus weights badly, they could be misconfigured or experimental Tor clients. Or there are bugs in some Tor versions that cause small guard weights, even for non-guards. (Or they could be Tor2web or Single Onion Service clients.)
A consensus weight of 1000 gets you a probability of about 0.003%. So if there are 1 million new clients, ignoring the Guard flag, we would expect 30*N of them to connect to your relay, where N is the number of entry nodes each client chooses.
Recent clients that have stable connections have 2 active guards. Older clients may have 3 active guards. A client that fails lots of connections has a large number of active guards. (Recent clients try to limit this number. Older clients do not.)
So having 17 active guards is not unreasonable. (It's a bug in Tor, but it's not unreasonable.) This would lead to you seeing ~500 connections at your relay.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Thx for the wisdom ;-)
On Thu, 4 Jan 2018 at 00:09 teor teor2345@gmail.com wrote:
On 4 Jan 2018, at 09:52, r1610091651 r1610091651@telenet.be wrote:
Hi teor
Thanks for the reply. I'm not having issues with my relay, and I've seen
the mail about extra users indeed. Just an observation, as I've just noticed few waves of these in last couple of hours. The start very abruptly and end just as well.
Not an expert, but I find it statistically significant to receive so
many connections (499 for one /24) form a single subnet to one specific middle node.
Unless that can be explained.
If they are connecting to middle nodes directly, and handling consensus weights badly, they could be misconfigured or experimental Tor clients. Or there are bugs in some Tor versions that cause small guard weights, even for non-guards. (Or they could be Tor2web or Single Onion Service clients.)
A consensus weight of 1000 gets you a probability of about 0.003%. So if there are 1 million new clients, ignoring the Guard flag, we would expect 30*N of them to connect to your relay, where N is the number of entry nodes each client chooses.
Recent clients that have stable connections have 2 active guards. Older clients may have 3 active guards. A client that fails lots of connections has a large number of active guards. (Recent clients try to limit this number. Older clients do not.)
So having 17 active guards is not unreasonable. (It's a bug in Tor, but it's not unreasonable.) This would lead to you seeing ~500 connections at your relay.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 4 Jan 2018, at 09:24, teor teor2345@gmail.com wrote:
there are about a million extra clients on the network since December. See this email for details:
https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html
If this is causing your relay issues, here are the things you can try:
RAM:
Set MaxMemInQueues to half your available RAM per tor instance. (It doesn't track all of Tor's memory usage.)
If your machine has one relay, if you have this much RAM, try this setting: 4 GB -> MaxMemInQueues 512 MB 8 GB -> MaxMemInQueues 2 GB 16 GB -> MaxMemInQueues 4 GB 32 GB -> MaxMemInQueues 8 GB
(If you have more than one relay on the machine, divide MaxMemInQueues by the number of relays. If you still have RAM issues, take down one relay.)
To decrease the risk of a Linux kernel oops, you might want to increase vm.min_free_kbytes. We recommend something like:
vm.min_free_kbytes=131072
(Check the existing value, and don't make it lower.) This gives the kernel extra RAM for large amounts of network traffic.
File descriptors / sockets:
Increase file descriptors for your tor user, or set ConnLimit to the number of file descriptors available to tor.
Sorry, this advice about file descriptors is wrong.
If Tor is running out of file descriptors, increase the file descriptors allocated to the user at the OS level.
If Tor is running out of CPU and has a lot of connections (over 10,0000), decrease the file descriptors allocated to the user.
You can do this on Debian Linux using a systemd drop-in: LimitNOFILE=10000
As a last resort, try setting:
DisableOOSCheck 1
But it's known to kill too many OR connections, so turn it off after the load passes.
T
-- Tim / teor
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
As a last resort, try setting:
DisableOOSCheck 1
Did you mean "DisableOOSCheck 0"?
"DisableOOSCheck 1" seems to be the default already (for Debian/Ubuntu and as mentioned here https://www.torproject.org/docs/tor-manual.html.en#DisableOOSCheck).
On 4 Jan 2018, at 18:14, tor tor@anondroid.com wrote:
As a last resort, try setting:
DisableOOSCheck 1
Did you mean "DisableOOSCheck 0"?
"DisableOOSCheck 1" seems to be the default already (for Debian/Ubuntu and as mentioned here https://www.torproject.org/docs/tor-manual.html.en#DisableOOSCheck).
Yes, you're right! It's DisableOOSCheck 0". I was confused, because most options are off by default.
T
Hi
This is new:
[image: image.png] Blue: to tor relay Green: from tor relay
My current rate config (lowered with recent on-slaughter) is RelayBandwidthRate 760 KBytes -> 6,5Mbit Yet, it is not respected.
I had to rate limit on firewall, as bandwidth configuration was flagrantly ignored. Tx = leaving firewall to tor Rx = leaving tor to firewall [image: image.png]
What I don't quite understand, is why I got such a stream of inflow data but much less outgoing (not even maxing out pipe) and yet it's only a middle relay. I would expect that it should be symmetric, or upload higher with directory related traffic.
How can that be? Thx
On Thu, 4 Jan 2018 at 09:15 teor teor2345@gmail.com wrote:
On 4 Jan 2018, at 18:14, tor tor@anondroid.com wrote:
As a last resort, try setting:
DisableOOSCheck 1
Did you mean "DisableOOSCheck 0"?
"DisableOOSCheck 1" seems to be the default already (for Debian/Ubuntu
and as mentioned here https://www.torproject.org/docs/tor-manual.html.en#DisableOOSCheck).
Yes, you're right! It's DisableOOSCheck 0". I was confused, because most options are off by default.
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sun, 7 Jan 2018 at 23:02 r1610091651 r1610091651@telenet.be wrote:
Hi
This is new:
[image: image.png]
Blue: to tor relay Green: from tor relay
(the later dropoffs is due to network shaping @firewall)
My current rate config (lowered with recent on-slaughter) is RelayBandwidthRate 760 KBytes -> 6,5Mbit Yet, it is not respected.
I had to rate limit on firewall, as bandwidth configuration was flagrantly ignored. Tx = leaving firewall to tor Rx = leaving tor to firewall
[image: image.png]
What I don't quite understand, is why I got such a stream of inflow data but much less outgoing (not even maxing out pipe) and yet it's only a middle relay. I would expect that it should be symmetric, or upload higher with directory related traffic.
How can that be? Thx
On Thu, 4 Jan 2018 at 09:15 teor teor2345@gmail.com wrote:
On 4 Jan 2018, at 18:14, tor tor@anondroid.com wrote:
As a last resort, try setting:
DisableOOSCheck 1
Did you mean "DisableOOSCheck 0"?
"DisableOOSCheck 1" seems to be the default already (for Debian/Ubuntu
and as mentioned here https://www.torproject.org/docs/tor-manual.html.en#DisableOOSCheck).
Yes, you're right! It's DisableOOSCheck 0". I was confused, because most options are off by default.
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
(with images)
Other relays seeing this too?
For sure. Here is some recent reading material:
https://lists.torproject.org/pipermail/tor-relays/2017-December/013669.html https://lists.torproject.org/pipermail/tor-relays/2017-December/013771.html https://lists.torproject.org/pipermail/tor-relays/2017-December/013839.html https://lists.torproject.org/pipermail/tor-relays/2017-December/013844.html https://lists.torproject.org/pipermail/tor-relays/2017-December/013881.html https://lists.torproject.org/pipermail/tor-relays/2017-December/013905.html
tor-relays@lists.torproject.org
-
r1610091651 -
teor -
tor