[tor-relays] Failed upgrade

[r1610091651]

Hi

FYI

So I've upgraded tor package from 0.4.4.6 to 0.4.5.7-1~xenial+1. No other
changes.
Yet on startup tor is complaining about mis-configuration:

Mar 23 20:55:02.928 [notice] Read configuration file
"/usr/share/tor/tor-service-defaults-torrc".
Mar 23 20:55:02.929 [notice] Read configuration file "/etc/tor/torrc".
Mar 23 20:55:02.932 [warn] Configuration port ORPort 9443 superseded by
ORPort :9443
Mar 23 20:55:02.932 [warn] We are listening on an ORPort, but not
advertising any ORPorts. This will keep us from building a router
descriptor, and make us impossible to use.
Mar 23 20:55:02.932 [warn] Failed to parse/validate config: Misconfigured
server ports
Mar 23 20:55:02.932 [err] Reading config failed--see warnings above.

config:
ORPort :9443 NoAdvertise
ORPort 9443 NoListen IPv4Only
AddressDisableIPv6 1
OutboundBindAddress 

This config is according to spec and worked with 4.4.6.

Seems to be related to thes issues, except for me it's blocking: tor fails
to start.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40300
https://gitlab.torproject.org/tpo/core/tor/-/issues/40302

I had to add 0.0.0.0 as ip to make tor start, although that's not
documented...
ORPort :9443 NoAdvertise
ORPort 0.0.0.0:9443 NoListen IPv4Only

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

[tor-relays] Config question

[r1610091651]

Hi

Recently upgraded to 4.4.6 and noticed new (for me) entry in tor logs:
Jan 11 09:24:28.000 [notice] While bootstrapping, fetched this many bytes:

This message gets repeated every 6 hours, while there is little extra info
added, as it relates to bootstrap / start-up process. I already have
"AvoidDiskWrites 1" active in torrc.

Is there a way to disable this extra logging?

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

Re: [tor-relays] "/var/tor/diff-cache" full!

[r1610091651]

Try this in config file:

MaxConsensusAgeForDiffs 4 hours

Kind regards

On Thu, 18 Jun 2020 at 17:57, Salvatore Cuzzilla 
wrote:

> Hi Folks,
>
> I'm running a non-exit relay (v0.4.2.7) on OpenBSD 6.7.
> The amount of files within "/var/tor/diff-cache" is steadily increasing.
> Up to almost 6G fulfilling the /var partition to the max.
>
> Is this an expected behavior? I there any solution to overcome it?
>
>
> ---
> :wq,
> Salvatore.
> ___
> 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] Consensus Weight Dropping/Authority Issues?

[r1610091651]

Consensus & usage are independent
consensus: based on available bandwidth
load: based on usage by tor clients.

if total available bw increases but load doesn't, observed load on a node
will drop.

On Tue, 7 Jan 2020 at 17:27, John Ricketts  wrote:

> I also would like to add to this - if it were just the Tor network
> increasing in size I could see my consensus weight dropping and my
> bandwidth staying the same.  I'm simply not getting the 7-8gbit/sec traffic
> I was.  Truly odd.
>
> -Original Message-
> From: tor-relays  On Behalf Of
> Toralf Förster
> Sent: Tuesday, January 7, 2020 7:30 AM
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] Consensus Weight Dropping/Authority Issues?
>
> On 1/7/20 1:57 PM, John Ricketts wrote:
> > I have been watching the consensus weight and bandwidth of all of my 50
> exit nodes drop consistently over the past few months. I have not made any
> hardware changes in my data center
>
>
> Which correlates to https://metrics.torproject.org/bandwidth.html - your
> fraction just decreases if more and more relays join the party.
>
> --
> Toralf
>
> ___
> 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] Consensus Weight Dropping/Authority Issues?

[r1610091651]

consensus means what fraction of traffic will pass over your nodes,
statistically speaking.
Hence a steady drop of consensus value, with no infra changes on your end,
could also be explained by a stead rise of total bandwidth available: since
your part is fixed and total grows, your fraction reduces.


Regards

On Tue, 7 Jan 2020 at 14:04, John Ricketts  wrote:

> Hello,
>
> I have been watching the consensus weight and bandwidth of all of my 50
> exit nodes drop consistently over the past few months. I have not made any
> hardware changes in my data center and actual customers have not complained
> about any performance issues.
>
> Operating systems and Tor version are up to date. I'm dedicating a
> significant portion of bandwidth to these nodes - 10gbit/sec.
>
> Am I having issues with the bandwidth authorities?
>
> I'm growing frustrated with my performance to resources ratio, I should be
> doing far better than this.
>
> Please throw ideas at me - open to any ideas.
>
> Thanks!
> John
> Quintex Alliance Consulting
> ___
> 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] Tor 0.4.2.5 - Unable to Run Tor Relay on Ubuntu 18.04 LTS VPS

[r1610091651]

Have a look in the log fie: /var/log/tor/notices.log
What is in there?

On Mon, 23 Dec 2019 at 05:23, David Croft <8pjp...@pm.me> wrote:

> Hi,
>
> I'm unable to start newly setup/configured guard/middle relay Tor version
> 0.4.2.5 after setup & configuration of Tor on an Ubuntu 18.04 VPS server.
>
> I'm already running a couple of Guard relays on Ubuntu 18.04 with the same
> VPS provider who allows for Tor Guard/Middle relays.
>
> I've followed a blueprint for setting up the Tor relay on Tor 0.4.2.5
> which worked no problem on 6 other relays I've configured & operated
> without issue in the last month on Ubuntu 18.04 Tor version 0.4.1.6.
>
> I've carefully reviewed the steps I've taken to ensure I haven't made any
> errors during the setup/configuration process.
>
> The issue described here is accompanied by the arrival of 0.4.2.5 & this
> is, in fact, the first time I've tried to set up a Tor relay on 0.4.2.5.
> I've also included a screenshot that highlights the issues.
>
> I realize there might very well be other possible reasons for these
> errors, so I keep an open mind & will be grateful for any support or advice.
>
> Regards,
>
> Toni
>
> output from:
>
> systemctl status tor@default.service
>
> ● tor@default.service - Anonymizing overlay network for TCP
>Loaded: loaded (/lib/systemd/system/tor@default.service;
> enabled-runtime; vendor preset: enabled)
>Active: failed (Result: exit-code) since Sun 2019-12-22 16:33:12 CET;
> 40min ago
>   Process: 3707 ExecStart=/usr/bin/tor --defaults-torrc
> /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
> (code=exited, status=0/SUCCESS)
>   Process: 4643 ExecStartPre=/usr/bin/tor --defaults-torrc
> /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
> --verify-config (code=exited, status=1/FAILURE)
>   Process: 4642 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g
> debian-tor -d /run/tor (code=exited, status=0/SUCCESS)
> Main PID: 3707 (code=exited, status=0/SUCCESS)
>
>
> ___
> 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] DSL Router

[r1610091651]

On Fri, 12 Oct 2018, 00:22 onion,  wrote:

> Apparently it looks like the usual router consumer products cant stand the
> number of connections on a DSL Line with 40Mbit/s upload capability.
>
> Could somebody help and share experience or a recommendation for a small,
> cheap, useful, up to date router, possibly with two WAN channels to get a
> consumer product combined on one side behind that router with all the DECT
> and other functionality for a private household and to have the Tor stuff
> on the second WAN channel.
>
> Thank you.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Hi

Have a look at mikrotik, they have a few soho options in different
pricepoints, and carrier grade toolset and quality.

Regards
Seb

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

[tor-relays] Memory leak in 0.3.4.8?

[r1610091651]

Hi

I've noticed following after upgrading to latest stable version (0.3.4.8):

Memory usage
[image: image.png]

Connection count
[image: image.png]

Cpu usage
[image: image.png]

You'll notice the upgrade happened around Saturday midnight.

Known issue? Any work-around?

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

Re: [tor-relays] Home router keeps failing.

[r1610091651]

Hi Gary

Does it fail as well if you disable tor? Also 600/900 connections is not
that high, and I would argue that you could get to that level even without
Tor client, especially with internet-of-things, where all devices gain IP
connectivity.

It might be a software stability issue. Have you verified with your isp if
there are any software updates available?
I could also be a hardware issue. As second option, try to get a
replacement.

Kind regards
Seb

On Mon, 16 Jul 2018 at 11:52 Gary  wrote:

> Hi,
>
> I keep having issues with my home router - it keeps failing due to the
> number of connections and I would be grateful for some advice.
>
> I have been running a (non-exit) middle relay for some time and up until
> now my router has mostly coped. It is what is what I got from my ISP, I
> can't afford to get a new one. At the minute I had to reset it on a daily
> basis which not only breaks tor circuits, but I am finding it increasingly
> hard to convince other people I live with that we need the relay when it
> causes them browsing issues.
>
> My relay connects via wire Ethernet.
> When I get to (approx) 900 incoming / 600 outgoing tor connections the
> router goes TITSUP.
> ACCOUNTING MAX is set to 8GBytes, I think the actual daily usage is about
> 4 GB though.
> RelayBandwidthRate is 250 KBytes, RelayBandwitdthBurst is 500KBytes.
> Although there are a few other devices / phones also connected, however I
> would estimate not more than a combined 2 GB daily HTTP / HTTPS traffic for
> all devices. No file sharing / P2P other than tor.
> My DSL speed is approx 50 mbits download / 15 mbits upload
>
> I dont want to keep resetting my router every day, I would be grateful for
> any advice.
>
> Many 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

Re: [tor-relays] Trying to set up a relay at home, but get no connections

[r1610091651]

On Mon, 11 Jun 2018 at 20:30 Gunnar Wolf  wrote:

> Graeme Neilson dijo [Sat, Jun 09, 2018 at 11:53:20AM +1200]:
> > See if you can route to all the authorities.
> > Tor requires that all relays are able to contact all directory
> authorities.
> >
> > In my case tcptraceroute would not get to all the authorities. For some
> > authorities my ISP was not routing to them.
>
> This seems to be the issue - I'm attaching a screenshot of «mtr»
> trying to reach all of the directory authorities from said server.
>
> So, it seems my ISP does not want us to run relays ☹ Can you think of
> any way my connection (oversized for my regular uses) can be put to
> use for Tor? I guess it would not work as a bridge either, would it?
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Hi

Traceroute requires support by all hops on the way, and that's not a given.
Try pinging the DA's instead or connecting to their tor ports.

Only Dizum doesn't respond to ping requests, but it has a "welcome" page on
80.

dannenberg dannenberg.torauth.de 193.23.244.244 80 443
tor26 86.59.21.38 86.59.21.38 80 443
longclaw 199.58.81.140 199.58.81.140 80 443
bastet 204.13.164.118 204.13.164.118 80 443
maatuska 171.25.193.9 171.25.193.9 443 80
moria1 128.31.0.34 128.31.0.34 9131 9101
dizum 194.109.206.212 194.109.206.212 80 443
gabelmoo 131.188.40.189 131.188.40.189 80 443
Faravahar 154.35.175.225 154.35.175.225 80 443

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

Re: [tor-relays] Inbound-outbound connexion ratio in tor

[r1610091651]

On Tue, 5 Jun 2018 at 20:07  wrote:

> Dear List,
>
> Since I started running Tor 0.3.2.10 a few months ago, I tend to have 2 to
> 3 times the number of inbound connexions as outbound, as reported by nyx.
> I am running a middle relay on Debian, no special anything.  Right now, for
> instance my inbound connexions are 2345, outbound are 861.
>
> The numbers never quite used to match, which made sense, because of tor
> overhead, but in a middle relay wouldn't they generally be about the same?
>
> Just wondering,
>
> --Torix
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Hi

I'm guessing these are connections the relay had ever association with.
When you restart a relay, it will equalise but then wander off with time
again. I see same thing:

[image: image.png]
(blue: out, green: in)
notice the restart mid week 21

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

[tor-relays] Unusual load returning?

[r1610091651]

Hi

I've noticed unusual load on the relay. Notice the huge change in load
between 3-8 am (CET).

Unusual logs:
May 14 03:49:44.000 [notice] Circuit handshake stats since last time:
5592/5592 TAP, 40516/40516 NTor.
May 14 09:49:44.000 [notice] Circuit handshake stats since last time:
5864/5864 TAP, 58290/58290 NTor.
May 14 15:49:44.000 [notice] Circuit handshake stats since last time:
35313/35313 TAP, 72399/72399 NTor.
May 14 21:49:44.000 [notice] Circuit handshake stats since last time:
98315/98315 TAP, 77724/77724 NTor.
May 15 03:49:44.000 [notice] Circuit handshake stats since last time:
*420868*/423426 TAP, 89627/89627 NTor.
May 15 09:49:44.000 [notice] Circuit handshake stats since last time:
*1362584*/1364077 TAP, 81196/81197 NTor.
May 15 15:49:44.000 [notice] Circuit handshake stats since last time:
5488/5488 TAP, 78317/78317 NTor.

For info: middle relay (no exit/guard), no directory, running 3.2.10

[image: image.png]

Wondering if others experienced it recently?

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

Re: [tor-relays] running relay excluded from votes

[r1610091651]

It happens from time to time (don't know why), usually waiting a bit helps.
looks like it's back:

https://consensus-health.torproject.org/consensus-health-2018-03-10-10-00.html#69D9FF1BE14B9AE77701A6BCBC075FF837F5AFF9

Regards

On Sat, 10 Mar 2018 at 10:49 Dark Matter  wrote:

> Hello,
>
> my relay 69D9FF1BE14B9AE77701A6BCBC075FF837F5AFF9 (darkmatter) disappeared
> from all votes (and hence from the consensus) starting today at the voting
> for valid after 07:00:00. Any explanation for this behavior? There is
> nothing unusual in the relay's logs and there was no reboot today. In my
> opinion it's strange that a relay suddenly disappears from the votes. If I
> got it right, usually an authority votes for "not running" if a relay can't
> be reached for some reason. But ALL votes excluded my relay starting today
> at seven am.
> Would like to understand what happened...
>
> Bye, Dark
> ___
> 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] Limiting connection count

[r1610091651]

On Sat, 3 Feb 2018 at 12:50 Moritz Kammerer 
wrote:

> Thanks for clarification. I will try LimitNOFILE = 6000. If that crashes
> my NAT box, I'm going to run a bridge.
>
> You could also consider getting a production class router (not some
consumer oriented thing), these don't have to be expensive though, ex 60$
for https://mikrotik.com/product/RB750Gr3
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] measure rate of initiated HTTPs connnections

[r1610091651]

That's because this rule matches on connection count >2000 with mask 0 =>
so results in: more than 2000 connections to anywhere

the second limit is for log action only.

On Fri, 2 Feb 2018 at 22:12 Toralf Förster  wrote:

> I do wonder why the follwoing iptables rule does fire more often than
> expected althought there're much less (<100) new outgoing Tor exit
> connections within 1 second at my Tor exit relay:
>
>  /sbin/iptables -A OUTPUT -p tcp --destination-port 443 --syn --match
> connlimit --connlimit-above 2000 --connlimit-mask 0 --connlimit-daddr
> --match limit --limit 1/second --limit-burst 1 -j LOG
>
> --
> Toralf
> PGP C4EACDDE 0076E94E
>
> ___
> 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] Tor uses up all available memory and eventually quits

[r1610091651]

On Sun, 28 Jan 2018 at 11:06 teor  wrote:

>
>
> Try to make sure MaxMemInQueues allows 10-20s of traffic.
>
>
> Hi teor

That advice is quite sensible in my opinion and should be incorporated into
tor mainline. With the recent load spikes, I've always wanders why is there
a need for that may MB or even GB of queue memory. If it can't be
retransmitted in few seconds, it will be retransmitted by source and will
increase the queues further...

The current setting for maxmeminqueue is 256MB and will correct itself if
lowered. I would suggest to make that value rate dependent, either
configured or measured.

 To your knowledge, was there any thought put into such a dynamic config,
instead of fixed percentage of free memory, independent of the actual
throughput?

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

Re: [tor-relays] Tor uses up all available memory and eventually quits

[r1610091651]

I think the advice to create swap will get George kicked of VPS, as it goes
right against the wishes of hosting company, and directly affects their
hardware.

A better advice is to tune tor process to work within memory boundaries.
The "MaxMemInQueues 512 MB" is right direction, but from personal
experience, I don't think it goes "far" enough. Will need to be limited
further I think, but you could adjust further based on your observations.

Seb

On Sun, 28 Jan 2018 at 07:14 tor  wrote:

> I think running on 1 GB of RAM with no swap is going to be difficult,
> especially if you have decent bandwidth and your node is busy.
>
> You can create a small swap file on the existing file-system like so:
>
>   sudo fallocate -l 1G /swapfile
>   sudo chmod 600 /swapfile
>   sudo mkswap /swapfile
>   sudo swapon /swapfile
>
> and to make permanent:
>
>   echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
>
> The swap file won't get used often, but will prevent your relay from going
> OOM and crashing. You can further reduce the likelihood of the swap getting
> used by setting something like "vm.swappiness = 10" in /etc/sysctl.conf.
>
> Also these two entries in your torrc might help:
>
>   DisableOOSCheck 0
>   MaxMemInQueues 512 MB
>
> ​The first line will enable the "out of sockets" check, and although it
> aggressively drops connections, tends to prevent the node from falling over
> instead. The second reduces the amount of memory used.
>
> ___
> 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] Middle relays stopping because of "SYN flood"?

[r1610091651]

I'm wondering if increasing the backlog is not going to make the problem
worse for you. You're machines can't cope already, and with that setting
the load is going to be increased even more.
Currently what doesn't fit in backlog doesn't get processed.

On Thu, 25 Jan 2018 at 20:54 Christian Krbusek  wrote:

> On 25-01-2018 20:33, Conrad Rockenhaus wrote:
> > Have you checked your kernel socket backlog limit? (net.core.somaxconn)
>
> Thanks for the hint. This is set to 128, a quick google revealed
> settings
> from torservers.net where it´s set to 20480 for a fast connection. I´ll
> give
> that a try and see how it works out.
>
> Cheers,
> Christian
> ___
> 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] Middle relays stopping because of "SYN flood"?

[r1610091651]

Probably to do with the lately regular spikes in load on nodes. You should
configure tor to protect itself and the machine it is running on:

Limit its maxmeminqueue to <= 1gb (in torrc)
limit virtual mem adressable by tor to <=2gb (limits on process)
limit number open files to your usual load (limits on process)
in firewall limit number of connections / ip
in firewall limit new connection rate limit / ip

This might not be enough for tor to survive, but your system should.

There have been quite a few mails about that recently.

Regards

On Thu, 25 Jan 2018 at 20:30 Conrad Rockenhaus 
wrote:

> Have you checked your kernel socket backlog limit? (net.core.somaxconn)
>
> > On Jan 25, 2018, at 1:19 PM, Christian Krbusek 
> wrote:
> >
> > Dear list,
> >
> > recently I´m facing issues with my 4 middle relays:
> >
> > B1E889E8EA604D81326F5071E0ABF1B2B16D5DAB
> > FC9AC8EA0160D88BCCFDE066940D7DD9FA45495B
> > BDB9EBCB1C2A424973A240C91EEC082C3EB61626
> > ACD889D86E02EDDAB1AFD81F598C0936238DC6D0
> >
> > All of them running v0.3.2.9 on Debian stretch (kvm, 2 cores, 2GB RAM)
> and stopping with the
> > log entries below. I can´t remember when this started but I´m quite sure
> it did not happen
> > a few month ago.
> >
> > There have not been any recent changes on the hardwarenode or on the VMs.
> >
> > All of them running the "same" configuration created by ansible-relayor
> - one example below.
> >
> > The VMs are running at the time the relays go offline and even a network
> restart doesn´t fix
> > the issue so I have to restart the VM to get the relays up and running
> again.
> >
> > Any hints would be much appreciated, if any more infos are needed just
> ask.
> >
> > Cheers,
> > Christian
> >
> >> CONFIG START <
> >
> > # ansible-relayor generated torrc configuration file
> > # Note: manual changes will be OVERWRITTEN on the next ansible-playbook
> run
> >
> > OfflineMasterKey 1
> > RunAsDaemon 0
> > Log notice syslog
> > OutboundBindAddress 188.118.198.244
> > SocksPort 0
> > User _tor-188.118.198.244_443
> > DataDirectory /var/lib/tor-instances/188.118.198.244_443
> > ORPort 188.118.198.244:443
> >
> >
> > DirPort 188.118.198.244:80
> >
> > SyslogIdentityTag 188.118.198.244_443
> >
> > ControlSocket /var/lib/tor-instances/188.118.198.244_443/controlsocket
> >
> > Nickname ph3x
> >
> > Sandbox 1
> > ExitRelay 0
> > ExitPolicy reject *:*
> >
> > ContactInfo 4096R/0x73538126032AD297 Christian Krbusek  DOT at> - 1NtneNxb8awwH8woJ7oL7UVj1SJDpAn8Kc
> > RelayBandwidthRate 15 MB
> > RelayBandwidthBurst 30 MB
> > NumCPUs 2
> >
> > MyFamily
> acd889d86e02eddab1afd81f598c0936238dc6d0,b1e889e8ea604d81326f5071e0abf1b2b16d5dab,bdb9ebcb1c2a424973a240c91eec082c3eb61626,fc9ac8ea0160d88bccfde066940d7dd9fa45495b
> > # end of torrc
> >
> >> CONFIG END <
> >
> >> LOGS START <
> >
> > at-vie01a-tor01.ph3x.at:
> >
> > Jan 25 17:58:24 at-vie01a-tor01 Tor-86.59.119.83_443[540]: Since
> startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3
> connections, and 8629 v4 connections; and receiv
> > ed 60 v1 connections, 4568 v2 connections, 9249 v3 connections, and
> 403685 v4 connections.
> > Jan 25 18:00:17 at-vie01a-tor01 kernel: [64938.876706] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.773119] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.774838] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786154] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786189] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786235] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786250] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786315] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786333] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786391] TCP: too many
> orphaned sockets
> > Jan 25 18:01:06 at-vie01a-tor01 kernel: [64987.786411] TCP: too many
> orphaned sockets
> > Jan 25 18:01:15 at-vie01a-tor01 kernel: [64997.053055] net_ratelimit: 2
> callbacks suppressed
> > Jan 25 18:01:15 at-vie01a-tor01 kernel: [64997.053056] TCP: too many
> orphaned sockets
> > Jan 25 18:01:16 at-vie01a-tor01 kernel: [64998.301030] TCP: too many
> orphaned sockets
> > Jan 25 18:01:16 at-vie01a-tor01 kernel: [64998.365099] TCP: too many
> orphaned sockets
> > Jan 25 18:01:17 at-vie01a-tor01 kernel: [64998.557033] TCP: too many
> orphaned sockets
> > Jan 25 18:01:18 at-vie01a-tor01 kernel: [64999.805082] TCP: too many
> orphaned sockets
> > Jan 25 18:01:27 at-vie01a-tor01 kernel: [65009.277179] TCP: too many
> orphaned sockets
> > Jan 25 18:01:28 at-vie01a-tor01 kernel: [65009.533307] TCP: too many
> orphaned sockets
> > Jan 25 18:01:28 at-vie01a-tor01 kernel: 

Re: [tor-relays] Upgraded relay non show in ATLAS

[r1610091651]

I've noticed the port typo, but results are same...

On Thu, 25 Jan 2018 at 20:31 r1610091651 <r1610091...@telenet.be> wrote:

> Are the ips still valid?
>
> https://atlas.torproject.org/#details/FE4033D750831C32A957174ADD11E40F558A14A9
>
> Is the port forward working?
>
> IPv4
> Starting Nmap 7.60 ( https://nmap.org ) at 2018-01-25 20:20 Romance
> Standard Time
> Nmap scan report for host28-237-dynamic.239-95-r.retail.telecomitalia.it
> (95.239.237.28)
> Host is up.
>
> PORTSTATESERVICE
> 433/tcp filtered nnsp
>
> Nmap done: 1 IP address (1 host up) scanned in 3.50 seconds
>
> IPv6
> Starting Nmap 7.60 ( https://nmap.org ) at 2018-01-25 20:23 Romance
> Standard Time
> Nmap scan report for 2001:470:1f12:62c::2:51
> Host is up.
>
> PORTSTATESERVICE
> 433/tcp filtered nnsp
>
> Nmap done: 1 IP address (1 host up) scanned in 3.22 seconds
>
> On Thu, 25 Jan 2018 at 17:43 niftybunny <ab...@to-surf-and-protect.net>
> wrote:
>
>>
>> On 25. Jan 2018, at 15:12, MLTor Node <ml.tor.n...@gmail.com> wrote:
>>
>> Hi to all!
>> i have a little relay running in my home LAN on Windows 2016 server
>> (MLTorNode, FE4033D750831C32A957174ADD11E40F558A14A9). A few days ago, i
>> create two VLan on my home network, one dedicated for my Tor relay. Today i
>> updated service to 3.2.9 release.
>>
>> After starting tor service, log say that Orport and DIRport are reachable
>> from outside, so it seems to be working without problems. But if i query
>> Atlas, my node seems to be down from 5 days. The IP showed in Atlas is old
>> (i have dynamic IP and dynamic DNS). I stop and start several times service
>> with no luck.
>>
>> Anyone can help me? My node is small, but i like very much Tor and i want
>> to continue contributing to the project. :-)
>>
>> --
>> Marlenio (MLTorNode)
>>
>> FE4033D750831C32A957174ADD11E40F558A14A9
>> ___
>> 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] Upgraded relay non show in ATLAS

[r1610091651]

Are the ips still valid?
https://atlas.torproject.org/#details/FE4033D750831C32A957174ADD11E40F558A14A9

Is the port forward working?

IPv4
Starting Nmap 7.60 ( https://nmap.org ) at 2018-01-25 20:20 Romance
Standard Time
Nmap scan report for host28-237-dynamic.239-95-r.retail.telecomitalia.it
(95.239.237.28)
Host is up.

PORTSTATESERVICE
433/tcp filtered nnsp

Nmap done: 1 IP address (1 host up) scanned in 3.50 seconds

IPv6
Starting Nmap 7.60 ( https://nmap.org ) at 2018-01-25 20:23 Romance
Standard Time
Nmap scan report for 2001:470:1f12:62c::2:51
Host is up.

PORTSTATESERVICE
433/tcp filtered nnsp

Nmap done: 1 IP address (1 host up) scanned in 3.22 seconds

On Thu, 25 Jan 2018 at 17:43 niftybunny 
wrote:

>
> On 25. Jan 2018, at 15:12, MLTor Node  wrote:
>
> Hi to all!
> i have a little relay running in my home LAN on Windows 2016 server
> (MLTorNode, FE4033D750831C32A957174ADD11E40F558A14A9). A few days ago, i
> create two VLan on my home network, one dedicated for my Tor relay. Today i
> updated service to 3.2.9 release.
>
> After starting tor service, log say that Orport and DIRport are reachable
> from outside, so it seems to be working without problems. But if i query
> Atlas, my node seems to be down from 5 days. The IP showed in Atlas is old
> (i have dynamic IP and dynamic DNS). I stop and start several times service
> with no luck.
>
> Anyone can help me? My node is small, but i like very much Tor and i want
> to continue contributing to the project. :-)
>
> --
> Marlenio (MLTorNode)
>
> FE4033D750831C32A957174ADD11E40F558A14A9
> ___
> 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] Increased cpu usage

[r1610091651]

Hi

AFter upgrade from 3.1.9 to 3.2.9, I've noticed that the cpu usage doubled
for same throughput / conditions. Is anyone else seeing that too?

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

Re: [tor-relays] Fwd: [tor-announce] Tor 0.3.2.9 is released (new stable series)

[r1610091651]

On Mon, 15 Jan 2018 at 01:27 teor <teor2...@gmail.com> wrote:

>
> On 15 Jan 2018, at 11:19, r1610091651 <r1610091...@telenet.be> wrote:
>
> Hi
>
> I was wondering if anyone knows when this release would become available
> as a Ubuntu package?
>
> I'm using the repository below but it's not there yet.
> deb-src http://deb.torproject.org/torproject.org xenial main
>
>
> Here is how you can get notifications of package updates:
>
> https://lists.torproject.org/pipermail/tor-relays/2018-January/014146.html
>
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


I already have a notification schema in place. It's just that the package
isn't available...
Are you saying: just wait and see?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Fwd: [tor-announce] Tor 0.3.2.9 is released (new stable series)

[r1610091651]

Hi

I was wondering if anyone knows when this release would become available as
a Ubuntu package?

I'm using the repository below but it's not there yet.
deb-src http://deb.torproject.org/torproject.org xenial main

(I did try to ask Nick)

Thx

On Tue, 9 Jan 2018 at 16:31 Nick Mathewson  wrote:

> On Tue, Jan 9, 2018 at 9:49 AM, Nick Mathewson 
> wrote:
> > (If you are about to reply saying "please take me off this list",
> > instead please follow these instructions:
> >  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce/
> > .  If you have trouble, it is probably because you subscribed using a
> > different address than the one you are trying to unsubscribe with.
> > You will have to enter the actual email address you used to
> > subscribe.)
> >
> > After months of work, Tor 0.3.1.7 is now available!  This is the first
> > stable release in the 0.3.2.x series, and we hope you find it useful.
>
> By which I mean, of course, that 0.3.2.9 is now available.
>
> Thanks to the 12 people who have already told me about this in the
> last 30 minutes, and my apologies for the extra email.
> ___
> tor-announce mailing list
> tor-annou...@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Options for Managing Relay Load (was: Re: Really strange)

[r1610091651]

On Sun, 7 Jan 2018 at 23:02 r1610091651 <r1610091...@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 <teor2...@gmail.com> wrote:
>
>>
>> On 4 Jan 2018, at 18:14, tor <t...@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)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Options for Managing Relay Load (was: Re: Really strange)

[r1610091651]

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  wrote:

>
> On 4 Jan 2018, at 18:14, tor  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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Options for Managing Relay Load (was: Re: Really strange)

[r1610091651]

Thx for the wisdom ;-)

On Thu, 4 Jan 2018 at 00:09 teor <teor2...@gmail.com> wrote:

>
> > On 4 Jan 2018, at 09:52, r1610091651 <r1610091...@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
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Options for Managing Relay Load (was: Re: Really strange)

[r1610091651]

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 <teor2...@gmail.com> wrote:

>
> > On 4 Jan 2018, at 08:52, r1610091651 <r1610091...@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
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Really strange

[r1610091651]

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?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Recent wave of abuse on Tor guards

[r1610091651]

Hi

I've implemented following mitigations:
* limit memory in queues. For my system that's a safe yet large enough
setting (2gb system mem, current usage around 320mb).
MaxMemInQueues 768 MB

* connlimit: both count & rate. Although, based on observations, only the
rate limit is actually being hit, and then only for the reported suspect
networks (see below on counts per /24).

-A INPUT -p tcp -m multiport --dports 9080,9443 -m connlimit
--connlimit-upto 360 --connlimit-mask 24 -m hashlimit --hashlimit-upto
20/second --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-name
mask24 -j ACCEPT

With these settings, there are no stability issues.

Regards


Frequent offenders of rate limit are (to name a few):
37.48.86.*
51.15.161.*
95.211.95.*
212.32.226.*
199.115.112.*
213.227.137.*
54.36.51.*


On Thu, 21 Dec 2017 at 21:21 mick  wrote:

> On Wed, 20 Dec 2017 17:22:54 +0100
> fco...@wardsback.org allegedly wrote:
>
> > Hi
> >
> > I'm the happy maintainer of wardsback :
> > B143D439B72D239A419F8DCE07B8A8EB1B486FA7
>
> And I run 0xbaddad - EA8637EA746451C0680559FDFF34ABA54DDAE831 a guard
> (though whether it stays a guard depends. It keeps falling over.)
> >
> > As many of us have noticed, many guard nodes are beeing abused by
> > extremely high numbers of connection attempts.
> > Thanks to some of you guys, I manged to put some mitigation in place
> > [0] and I assume many of us did as well.
>
> I'm still looking at mitigation. I'd rather not add iptables filter
> rules because it feels like the wrong thing to do (I might hurt
> legitimate connections) and at the wrong end of the stack. I'd prefer
> there to be mitigations available at the application end (Tor itself).
> But realistically I know that that is difficult and the Tor developer
> team are still working hard at this problem. (As an aside, I'd be very
> grateful for any feedback from other relay operators who /have/ added
> iptables "connlimit" rules. What is your view either way?)
>
> I'm only sticking my head above the parapet now to note what I am
> seeing.
>
> So: My logs show Tor staying up for around 10 minutes at a time before
> rebooting with the following sort of entries:
>
> Dec 21 16:25:44.000 [notice] Performing bandwidth self-test...done.
> Dec 21 16:35:20.000 [notice] Tor 0.3.1.9 (git-df96a13e9155c7bf) opening
> log file. Dec 21 16:35:20.946 [notice] Tor 0.3.1.9
> (git-df96a13e9155c7bf) running on Linux with Libevent 2.0.21-stable,
> OpenSSL 1.1.0f, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2. Dec 21
> 16:35:20.947 [notice] Tor can't help you if you use it wrong! Learn how
> to be safe at https://www.torproject.org/download/download#warning Dec
> 21 16:35:20.947 [notice] Read configuration file
> "/usr/share/tor/tor-service-defaults-torrc". Dec 21 16:35:20.947
> [notice] Read configuration file "/etc/tor/torrc". Dec 21 16:35:20.951
> [notice] Based on detected system memory, MaxMemInQueues is set to 369
> MB. You can override this by setting MaxMemInQueues by hand. Dec 21
> 16:35:20.952 [notice] Opening Control listener on 127.0.0.1:9051 Dec 21
> 16:35:20.953 [notice] Opening OR listener on 0.0.0.0:9001 Dec 21
> 16:35:20.000 [notice] Not disabling debugger attaching for unprivileged
> users. Dec 21 16:35:21.000 [notice] Parsing GEOIP IPv4
> file /usr/share/tor/geoip. Dec 21 16:35:21.000 [notice] Parsing GEOIP
> IPv6 file /usr/share/tor/geoip6. Dec 21 16:35:22.000 [notice]
> Configured to measure statistics. Look for the *-stats files that will
> first be written to the data directory in 24 hours from now. Dec 21
> 16:35:22.000 [notice] Your Tor server's identity key fingerprint is
> '0xbaddad EA8637EA746451C0680559FDFF34ABA54DDAE831' Dec 21 16:35:22.000
> [notice] Bootstrapped 0%: Starting Dec 21 16:35:31.000 [notice]
> Starting with guard context "default" Dec 21 16:35:31.000 [notice]
> Bootstrapped 80%: Connecting to the Tor network Dec 21 16:35:31.000
> [notice] Signaled readiness to systemd Dec 21 16:35:31.000 [notice]
> Opening Control listener on /var/run/tor/control Dec 21 16:35:31.000
> [notice] Bootstrapped 85%: Finishing handshake with first hop Dec 21
> 16:35:32.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing
> handshake with first hop. (Connection refused; CONNECTREFUSED; count
> 10; recommendation warn; host CD14AE63A02686BAE838A8079449B480801A8A5F
> at 195.181.208.180:443) Dec 21 16:35:32.000 [warn] 9 connections have
> failed: Dec 21 16:35:32.000 [warn]  9 connections died in state
> connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
> Problem bootstrapping. Stuck at 85%: Finishing handshake with first
> hop. (Connection refused; CONNECTREFUSED; count 11; recommendation
> warn; host 500FE4D6B529855A2F95A0CB34F2A10D5889E8C1 at
> 134.19.177.109:443) Dec 21 16:35:32.000 [warn] 10 connections have
> failed: Dec 21 16:35:32.000 [warn]  10 connections died in state
> connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
> Problem bootstrapping. Stuck 

Re: [tor-relays] MaxMemInQueues - per host, or per instance?

[r1610091651]

So
it will hurt Tor if we have too little buffers -> killing circuits ->
unstable connections
it will hurt Tor if we have too much buffers -> process out of control ->
unstable instance

Would it be possible to guestimate typical circuit buffer size?

One could then estimate value not too big / small based on the number of
circuit running through relay.

If we where to say that a circuit would typically need 128k, one could
estimate the setting for a 5K circuit relay to be ~600MB.

Regards

On Fri, 22 Dec 2017 at 22:55 David Goulet <dgou...@torproject.org> wrote:

> On 22 Dec (20:37:37), r1610091651 wrote:
> > I'm wondering if it is necessary to have a lot of ram assigned to queues?
> > Is there some rule of thumb to determine the proper sizing? Based on
> number
> > of circuits maybe?
>
> So there are probably many different answers to this or ways to look at
> it but I can speak on how "tor" is built and why it is important to have
> this memory limit assigned to queues.
>
> A tor relay gets cells in and most of the time will relay them so send
> them outbound. But for every cell that comes in, we need to do some
> processing on them that is mostly decryption work.
>
> So we get them, process then put them on a circuit queue. Then tor does
> its best to dequeue a "not too big amount of cells" from a circuit and
> puts them on the outbound connection buffers which, when the socket is
> writable, will be flushed onto the network (write to the socket).
>
> The MaxMemInQueues parameter basically tells the tor OOM handler when it
> is time to start cleaning up allocated memories. But here is the catch,
> it only handles cells on circuit queues, not connection's buffer (it
> actually handles other things but the majority of allocated data is in
> cells usually).
>
> For that reason, we are better off for now to keep relays with a sane
> value for MaxMemInQueues so the OOM is actually triggered before the
> load goes out of control.
>
> If that MaxMemInQueues value is not set in your torrc, tor will pick 3/4
> of the total memory of your system. Usually, this is fine for most use
> cases but if you machine has 16GB of RAM but only 4GB are available,
> problem. So when setting it, it is not that easy to come up with a good
> value but a rule of thumb for now is look at how much memory you have
> available normally and estimate around it. It is also important to not
> go to low, a fast relay limited to 1GB for instance will start to
> degrade performance by killing cicuits more often if it sees 20MB/s
> (imperically speaking).
>
> I think we could do a better job at estimating it when not set, we could
> do a better job with the OOM, we could do lot more but unfortunately for
> now, this is the state of thing we need to deal with. We'll be trying to
> work on more DoS resistance feature hopefully in the near future.
>
> Hope this help!
>
> Cheers!
> David
>
> >
> > Do the wise-minds have a guidance on this one?
> >
> > On Fri, 22 Dec 2017 at 21:08 Igor Mitrofanov <
> igor.n.mitrofa...@gmail.com>
> > wrote:
> >
> > > Thanks. I do have the IP space.
> > >
> > > It is a pity multiple instances cannot watch the overall RAM
> > > remaining. I have quite a bit of RAM left, but there are large
> > > discrepancies in terms of how much RAM different relays are using (>3
> > > GB for some, <1 GB for others), so it will be tricky to set
> > > MaxMemInQueues without making it too conservative.
> > >
> > > On Fri, Dec 22, 2017 at 11:46 AM, r1610091651 <r1610091...@telenet.be>
> > > wrote:
> > > > It would expect it to be per instance. Instances are independent of
> each
> > > > other. Further one can only run 2 instances max / ip.
> > > >
> > > > On Fri, 22 Dec 2017 at 20:40 Igor Mitrofanov <
> > > igor.n.mitrofa...@gmail.com>
> > > > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> Is MaxMemInQueues parameter per-host (global) or per-instance?
> > > >> Say, there are 10 relays on the same 24 GB host. Should I set
> > > >> MaxMemInQueues to 20 GB, or 2 GB in each torrc?
> > > >>
> > > >> Thanks,
> > > >> Igor
> > > >> ___
> > > >> tor-relays mailing list
> > > >> tor-relays@lists.torproject.org
> > > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> > > >
> > > >
> > > > ___
> &g

Re: [tor-relays] MaxMemInQueues - per host, or per instance?

[r1610091651]

I'm wondering if it is necessary to have a lot of ram assigned to queues?
Is there some rule of thumb to determine the proper sizing? Based on number
of circuits maybe?

Do the wise-minds have a guidance on this one?

On Fri, 22 Dec 2017 at 21:08 Igor Mitrofanov <igor.n.mitrofa...@gmail.com>
wrote:

> Thanks. I do have the IP space.
>
> It is a pity multiple instances cannot watch the overall RAM
> remaining. I have quite a bit of RAM left, but there are large
> discrepancies in terms of how much RAM different relays are using (>3
> GB for some, <1 GB for others), so it will be tricky to set
> MaxMemInQueues without making it too conservative.
>
> On Fri, Dec 22, 2017 at 11:46 AM, r1610091651 <r1610091...@telenet.be>
> wrote:
> > It would expect it to be per instance. Instances are independent of each
> > other. Further one can only run 2 instances max / ip.
> >
> > On Fri, 22 Dec 2017 at 20:40 Igor Mitrofanov <
> igor.n.mitrofa...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> Is MaxMemInQueues parameter per-host (global) or per-instance?
> >> Say, there are 10 relays on the same 24 GB host. Should I set
> >> MaxMemInQueues to 20 GB, or 2 GB in each torrc?
> >>
> >> Thanks,
> >> Igor
> >> ___
> >> 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] MaxMemInQueues - per host, or per instance?

[r1610091651]

It would expect it to be per instance. Instances are independent of each
other. Further one can only run 2 instances max / ip.

On Fri, 22 Dec 2017 at 20:40 Igor Mitrofanov 
wrote:

> Hi,
>
> Is MaxMemInQueues parameter per-host (global) or per-instance?
> Say, there are 10 relays on the same 24 GB host. Should I set
> MaxMemInQueues to 20 GB, or 2 GB in each torrc?
>
> Thanks,
> Igor
> ___
> 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] botnet? abusing/attacking guard nodes

[r1610091651]

I don't quite understand the last calculation.

"if all 65535 connections on an IP were open" => I'm guessing you mean ports
"the biggest Tor Guard has 0.91% Guard probability" => percentage of all
entries into the network handled by this guard

=> 0.91% of all user connections
but how many user connections are there at a time?

and then don't understand how probability and ports availability can be
combined?

Please elaborate.
Thanks

On Mon, 18 Dec 2017 at 23:11 teor  wrote:

>
> > On 19 Dec 2017, at 08:38, Toralf Förster  wrote:
> >
> > On 12/17/2017 10:24 PM, teor wrote:
> >> Using 256 per IP is probably reasonable.
> >
> > Is this a rather arbitrary limit or does this limit fit the use of NATed
> addresses entirely ?
>
> That's an arbitrary safe upper bound.
>
> The number of active connections that can be NATed per IP address is
> limited by the number of ports: 65535. (Technically, it's 65535 per
> remote IP address and port, but most NATs don't have that much RAM
> or bandwidth.)
>
> Also, genuine users behind a NAT would likely have multiple Tor and
> non-Tor connections open. And spare ports are needed for NAT to manage
> port churn and the TCP delay wait state on connection close.
>
> To be more precise:
> * if all 65535 connections on an IP were open to the Tor network, and
> * the biggest Tor Guard has 0.91% Guard probability[0], then
> * it would expect to see 597 connections.
>
> Feel free to do the sums for your own guard's probability.
>
> (We are aware of the issue, and we are working on a more permanent fix.)
>
> [0]:
> https://atlas.torproject.org/#details/9844B981A80B3E4B50897098E2D65167E6AEF127
>
>
> 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
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Failing because we have 4063 connections already // Number of file descriptors

[r1610091651]

On Fri, 15 Dec 2017, 11:13 r1610091651, <r1610091...@telenet.be> wrote:

> That depends on how tor is started and have different origins. What i know:
> * if started by systemd: the limit can be specified in the service
> descripton file /lib/systemd/system/tor@default.service: =>
> LimitNOFILE=
> * if started by init: usually pam/security will be applied => using
> limits.conf and propagated by pam: /etc/pam.d/common-*
>
> There are probably also other paths.
>
> Regards
>
> On Fri, 15 Dec 2017 at 11:03 Ralph Seichter <m16+...@monksofcool.net>
> wrote:
>
>> On 15.12.2017 10:45, r1610091651 wrote:
>>
>> > could be that your tuning is not being picked up by the distro.
>>
>> Looks like you are right:
>>
>>   # cat /proc/3534/limits
>>   Limit  Soft Limit Hard Limit  Units
>>   Max cpu time   unlimited  unlimited   seconds
>>   Max file size  unlimited  unlimited   bytes
>>   Max data size  unlimited  unlimited   bytes
>>   Max stack size 8388608unlimited   bytes
>>   Max core file size 0  unlimited   bytes
>>   Max resident set   unlimited  unlimited   bytes
>>   Max processes  3969   3969processes
>>   Max open files 4096   4096files
>>   Max locked memory  65536  65536   bytes
>>   Max address space  unlimited  unlimited   bytes
>>   Max file locks unlimited  unlimited   locks
>>   Max pending signals3969   3969signals
>>   Max msgqueue size  819200 819200  bytes
>>   Max nice priority  0  0
>>   Max realtime priority  0  0
>>   Max realtime timeout   unlimited  unlimited   us
>>
>> Only 4096 open files max. I did not expect that, because of
>>
>>   tor $ ulimit -n
>>   65535
>>   tor $ cat /proc/sys/fs/file-max
>>   101300
>>
>> What part of the system's configuration could cause the 4096 open files
>> limit, overriding the 65535 I specified in limits.conf?
>>
>> -Ralph
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
Short term you can modify limits on running process with prlimit
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Failing because we have 4063 connections already // Number of file descriptors

[r1610091651]

That depends on how tor is started and have different origins. What i know:
* if started by systemd: the limit can be specified in the service
descripton file /lib/systemd/system/tor@default.service: => LimitNOFILE=
* if started by init: usually pam/security will be applied => using
limits.conf and propagated by pam: /etc/pam.d/common-*

There are probably also other paths.

Regards

On Fri, 15 Dec 2017 at 11:03 Ralph Seichter <m16+...@monksofcool.net> wrote:

> On 15.12.2017 10:45, r1610091651 wrote:
>
> > could be that your tuning is not being picked up by the distro.
>
> Looks like you are right:
>
>   # cat /proc/3534/limits
>   Limit  Soft Limit Hard Limit  Units
>   Max cpu time   unlimited  unlimited   seconds
>   Max file size  unlimited  unlimited   bytes
>   Max data size  unlimited  unlimited   bytes
>   Max stack size 8388608unlimited   bytes
>   Max core file size 0  unlimited   bytes
>   Max resident set   unlimited  unlimited   bytes
>   Max processes  3969   3969processes
>   Max open files 4096   4096files
>   Max locked memory  65536  65536   bytes
>   Max address space  unlimited  unlimited   bytes
>   Max file locks unlimited  unlimited   locks
>   Max pending signals3969   3969signals
>   Max msgqueue size  819200 819200  bytes
>   Max nice priority  0  0
>   Max realtime priority  0  0
>   Max realtime timeout   unlimited  unlimited   us
>
> Only 4096 open files max. I did not expect that, because of
>
>   tor $ ulimit -n
>   65535
>   tor $ cat /proc/sys/fs/file-max
>   101300
>
> What part of the system's configuration could cause the 4096 open files
> limit, overriding the 65535 I specified in limits.conf?
>
> -Ralph
> ___
> 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] Failing because we have 4063 connections already // Number of file descriptors

[r1610091651]

Hi

Please verify the effective limit used for your tor process:

cat /proc//limits

with  process id of the tor process. could be that your tuning is not
being picked up by the distro.

Regards

On Fri, 15 Dec 2017 at 10:39 Ralph Seichter  wrote:

> Since a couple of days ago, one of my relay nodes keeps logging messages
> like this:
>
>   Tor[3534]: Failing because we have 4063 connections already. Please
>   read doc/TUNING for guidance. [over 1601 similar message(s)
>   suppressed in last 21600 seconds]
>
> I found https://trac.torproject.org/projects/tor/ticket/16929 and an
> older mailing list thread (and doc/TUNING) that suggest increasing the
> maximum number of open file descriptors. I now use
>
>   # /etc/security/limits.conf
>   *  -  nofile  65535
>
> to raise 'nofile' from 1024 to 65535, which does not seem to make any
> difference (the logged error message does not change).
>
> My relay uses Gentoo Linux kernel version 4.14.5 and Tor 0.3.2.6 alpha.
> I also tried older versions of the kernel and Tor 0.3.1.9, in several
> combinations, without success. I also other relays running just fine
> with the default number of file descriptors (1024).
>
> As I mentioned, the problems started a few days ago, around the time I
> upgraded from Gentoo system profile default/linux/amd64/13.0 to
> default/linux/amd64/17.0, rebuilding many system packages in the
> process. Unfortunately I cannot tell what exactly changed. Since the
> profile upgrade was deliberate and I cannot roll back, I wonder if
> I can overcome Tor's problems via configuration options only?
>
> -Ralph
> ___
> 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] DoS attacks are real (probably)

[r1610091651]

On Mon, 11 Dec 2017 at 18:07 Felix  wrote:

> Hi Alex
>
> Great points.
>
> > conntrack -L -p tcp --dport 9001 | awk '{print $5}' | sort | uniq -c
> | sort -n
>
> On FreeBSD one can do:
>
> In packetfilter:
>
> # play with the numbers but more than 64k per ip if possible
> set limit { frags 7, src-nodes 7, states 7, table-entries
> 10 }
>
> table  persist
>
> # 2000 is super high. Rate limit 50 new connects per 5 secs
> # overload but not flush
> pass in on $if_ext inet proto tcp from any to $relay_ip port $or_port
> flags S/SA modulate state (max-src-conn 2000,max-src-conn-rate
> 50/5,overload )
>
> As cronjob:
>
> # release block after 10 minutes
> pfctl -t blockOR -T expire 600
>
> These measures protect your system. IMO for other or future cases we
> should keep the clients degree of freedom (researchers / fancy doers) as
> high as possible, being not too restrictive.
>
>
> > 1. Open many OR connections (hundreds to thousands)
> > 2. Leave open until tor runs out of sockets
>
> If the ip is saturated for like 2 hours the relay might loose the hsdir
> flag. But today there are not enough resources in the game to generate
> an issue for the network.
>
>
> > I recommend against
> > the blanket approach suggested previously of limiting whole sets of
> > /24s, since that may inadvertently block mobile clients and is not
> > effective against the current attack.
>
> Right. In future one could put such loud clients besides useful ips a
> let the relays block the usefull.
>
>
> > 2. the connections do not taper off if they are rejected. I banned these
> > addresses from accessing Tor, and they continue to make dozens of
> > connection attempts every second from each IP address. this means that
> > this is probably not a good faith "test" or a misconfigured set of real
> > Tor clients, but is instead malicious and using a modified or custom
> > client.
>
> The above rule limits the useless attempts to a certain limit and
> recovers after 10 minutes. This protects but gives the 'offender' the
> chance to tune his client to a better behaviour (in case he wants it).
>
>
> > 3c. it is almost certainly not real clients using NAT; as far as I know,
> > LeaseWeb does not use NAT, and Online.net only uses one-to-one NAT.
>
> Good point. A general blocking rule should be smart enough to enable NAT
> clients anyway ?
>
>
> --
> Cheers, Felix
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Hi

For the ones interested in Linux version, this translates to:

 -A INPUT -p tcp -m multiport --dports $or_port,$dir_port -m connlimit
--connlimit-upto 2000 --connlimit-mask 24 -m hashlimit --hashlimit-upto
10/second --hashlimit-mode srcip --hashlimit-srcmask 16 --hashlimit-name
mask24 -j ACCEPT
 -A INPUT -p tcp -m multiport --dports $or_port,$dir_port -j REJECT
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Issues with faravahar?

[r1610091651]

Hi

I'm seeing regular issues with faravahar in logs lately. Is somebody
working on this?

Logs:
Dec 12 10:32:56.000 [warn] HTTP status 502 ("Bad Gateway") was unexpected
while uploading descriptor to server '154.35.175.225:80'. Possibly the
server is misconfigured?
Dec 12 10:33:56.000 [warn] Received http status code 502 ("Bad Gateway")
from server '154.35.175.225:80' while fetching
"/tor/server/d/706E3C29265BD073DF77DC457A3CD8B1BC16C6E6+E223A1B036E3F7315DCADE32F6A4428F15148987.z".
I'll try again soon.

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

Re: [tor-relays] Too many connections warning

[r1610091651]

Hi

I think tor already has 32k open files limit, hence the error. Just to make
sure, try this:

cat /proc/`cat /run/tor/tor.pid`/limits

Notice the line with "Max open files"

Depending on how tor is started, you might need to change the config:
with systemd
  /lib/systemd/system/tor@default.service:
  LimitNOFILE=x <= change this
with init
  /etc/security/limits.conf:
  *softnofile  8192
  *hardnofile  32768
  that one can be change /user (username), /group, ... or for all users
(*)

Bye

On Thu, 7 Dec 2017 at 16:25 Tyler Johnson  wrote:

> I believe this warning describes a lack of available file descriptors,
> limiting the amount of connections your tor relay is able to make.
>
> ulimit -n is exactly the command you want to use to raise that limit from
> your current 1024.
>
> What exactly that number should be, I couldn't say, but you could start at
> 1 and raise / lower based on your needs and resources.
>
> Raising a similar limit on OpenBSD from the default to 2 helped
> eliminate the error for me.
>
>
>
> On Dec 7, 2017 7:28 AM, "Logforme"  wrote:
>
>> 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 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] So long and thanks for all the abuse complaints

[r1610091651]

I think it is relevant.

There are two sides to creating a connection and traffic can be filtered on
both ends.
On the initiator: any invalid outgoing packets can be filtered
On the receiver: any not expected / invalid packets can be filtered

Just a question: how can the hoster determine whether a packet is part of a
port scan or valid connection request?
Unless the packet is mangled/invalid (ex: out of sequence like fin / syn
scan) it can't as it is unaware what services are running at the other end.
Effectively what the hoster is also doing, is imposing a rate limit on rate
and number of connections.

On Tue, 5 Dec 2017 at 19:51 Ralph Seichter <m16+...@monksofcool.net> wrote:

> On 05.12.17 19:24, r1610091651 wrote:
>
> > Having servers on-line and complaining about such things is just
> > unreasonable and laziness on the operator side: don't want scans,
> > then setup proper firewall rules. Done.
>
> Your comment is not applicable in this particular case; please read my
> other messages in this thread to see why.
>
> -Ralph
> ___
> 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] So long and thanks for all the abuse complaints

[r1610091651]

Port scans are part of internet life in my opinion. One cannot have
internet access and no (occasional) port scan, spam mails, worms, ...
Having servers on-line and complaining about such things is just
unreasonable and laziness on the operator side: don't want scans, then
setup proper firewall rules. Done.

Just a "food for thought": how does one distinguishes between slow port
scan (as is possible with for example nmap) and actual connection attempts?

Regards


On Tue, 5 Dec 2017 at 17:38 Ralph Seichter  wrote:

> Quoting myself:
>
> > I've had an ongoing debate with a hosting service over a fresh exit
> > node being abused for network scans (ports 80 and 443) almost hourly
> > for the last few days.
>
> I had the former exit node unlocked an ran it in relay mode for a day.
> Today I switched back to exit mode, and a few hours after the exit flag
> was reassigned, I already received the next complaint about an outgoing
> network scan. The logs sent to me clearly confirm scans taking place,
> this is not about the hoster being obstinate.
>
> Looks like I will have to shut down this particular exit for good if
> I cannot find a way to prevent it from being abused as network scan
> central. :-(
>
> -Ralph
> ___
> 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] Atlas is now Relay Search!

[r1610091651]

On Thu, 16 Nov 2017 at 11:46 Iain R. Learmonth  wrote:

> Hi,
>
> On 16/11/17 02:36, teor wrote:
> > No, I can't, because iOS ad blockers do not provide this information.
> > Did you add many resources in the transition?
>
> Short of buying me an iPad I have no idea how to debug this.
>
> The following resources are loaded by Relay Search, and the new ones are
> those on metrics.torproject.org. Note that the entire application is
> loaded when you access the site, so it either works or it doesn't. If
> there is a single JavaScript or template missing, it will just not work.
>
> https://atlas.torproject.org/
> https://metrics.torproject.org/js/jquery-3.2.1.min.js
> https://atlas.torproject.org/js/jquery.cookieBar.js
> https://atlas.torproject.org/css/bootstrap.min.css
> https://metrics.torproject.org/js/bootstrap.min.js
> https://atlas.torproject.org/css/font-awesome.min.css
> https://atlas.torproject.org/fonts/source-sans-pro.css
> https://atlas.torproject.org/css/prism.css
> https://metrics.torproject.org/js/prism.js
> https://atlas.torproject.org/css/style.css
> https://metrics.torproject.org/js/script.js
> https://atlas.torproject.org/css/atlas.css?v1
> https://atlas.torproject.org/js/libs/require/require.js
> https://atlas.torproject.org/images/tor-metrics-white.png
> https://atlas.torproject.org/images/tor-metrics-wh...@2x.png
> https://atlas.torproject.org/js/main.js?v1
> https://atlas.torproject.org/js/app.js?v1
> https://atlas.torproject.org/js/libs/underscore/underscore-min.js?v1
> https://atlas.torproject.org/js/libs/backbone/backbone-optamd3-min.js?v1
> https://atlas.torproject.org/js/router.js?v1
> https://atlas.torproject.org/js/views/details/main.js?v1
> https://atlas.torproject.org/js/views/search/main.js?v1
> https://atlas.torproject.org/js/views/search/do.js?v1
> https://atlas.torproject.org/js/libs/jssha/sha1.js?v1
> https://atlas.torproject.org/js/models/relay.js?v1
> https://atlas.torproject.org/js/models/graph.js?v1
> https://atlas.torproject.org/js/libs/require/text.js?v1
> https://atlas.torproject.org/js/libs/bootstrap/bootstrap-tooltip.js?v1
> https://atlas.torproject.org/js/libs/d3js/d3.v3.min.js?v1
> https://atlas.torproject.org/js/helpers.js?v1
> https://atlas.torproject.org/js/collections/results.js?v1
> https://atlas.torproject.org/js/libs/datatables/jquery.dataTables.min.js?v1
> https://atlas.torproject.org/js/libs/datatables/dataTables.Sorting.js?v1
>
> https://atlas.torproject.org/js/libs/bootstrap/bootstrap3-typeahead.min.js?v1
> https://atlas.torproject.org/templates/details/router.html?v1
> https://atlas.torproject.org/templates/details/bridge.html?v1
> https://atlas.torproject.org/templates/details/error.html?v1
> https://atlas.torproject.org/templates/search/do.html?v1
> https://atlas.torproject.org/templates/search/main.html?v1
>
> Thanks,
> Iain.
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Hi
I seem to have a similar problem in Opera v49 as teor in iOS. Only see the
spinning ajax-loader.gif.

Went into debugger and seems like the page is loaded, but the style is set
to display=none.


Once overridden, page displays fine and functions => I can search.

So the question is why isn't the loader overlay disabled?

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

Re: [tor-relays] New on relays and Tor

[r1610091651]

Have a look at Nyx (successor to Arm).

On Sun, 12 Nov 2017 at 17:01 Matt Traudt  wrote:

>
>
> On 11/12/2017 10:37 AM, Alfredo Bollati wrote:
> > Hi all I just started investigating and getting involved with Tor
> > project. I have configured my router to port forwarding on one of its
> > ports. Is there a way or some steps to follow in order to confirm that
> > my bandwidth is being used by the relay?
> >
>
> First thing to do would be configure Tor to log to a file and to read
> that file. You can check it to see if Tor logs any issues, and every 6
> hours Tor will log bandwidth usage information.
>
> Matt
> ___
> 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] AccountingMax 48 GBytes is not working

[r1610091651]

On Mon, 16 Oct 2017 at 21:52 Artur Pędziwilk <
cb86eb08b7299219c1af5dbcaddd4...@protonmail.ch> wrote:

> Hi Tor operators,
> I have relay with
>   AccountingMax 48 GBytes
>   AccountingStart day 09:00
>   MaxMemInQueues 512
>   ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed
>
> The accounting seems stopped working since upgrade to tor-0.3.0.10 or
> enabling obfs4proxy.
> I am not fully sure, what do you think?
>
>
> https://atlas.torproject.org/#details/DFBF5EA4F70DC6639156BB71593F2A2E8FDA8F1A
>
>
> Oct 16 09:00:00 venator Tor[3519]: Configured hibernation.  This interval
> began at 2017-10-16 09:00:00; the scheduled wake-up time was 2017-10-16
> 09:00:00; we expect to exhaust our quota for this interval around
> 2017-10-17 09:00:00; the next interval begins at 2017-10-17 09:00:00 (all
> times local)
> Oct 16 09:00:00 venator Tor[3519]: Hibernation period ended. Resuming
> normal activity.
> Oct 16 09:00:00 venator Tor[3519]: Opening Directory listener on
> 45.76.39.74:8080
> Oct 16 09:00:00 venator Tor[3519]: Opening OR listener on 45.76.39.74:9090
> Oct 16 09:00:00 venator Tor[3519]: Opening Extended OR listener on
> 45.76.39.74:46396
> *Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 0:46 hours,
> with 11 circuits open. I've sent 192.00 GB and received 192.01 GB.*
> Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent:
> 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The
> current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours.
> Oct 16 09:46:11 venator Tor[3519]: Average packaged cell fullness:
> 12.851%. TLS write overhead: 2%
> Oct 16 09:46:11 venator Tor[3519]: Circuit handshake stats since last
> time: 12/12 TAP, 66/66 NTor.
> Oct 16 09:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1
> connections, 0 v2 connections, 0 v3 connections, and 35405 v4 connections;
> and received 16 v1 connections, 17 v2 connections, 1 v3 connections, and
> 29675 v4 connections.
> Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached;
> commencing hibernation. No new connections will be accepted
> Oct 16 14:45:07 venator Tor[3519]: Going dormant. Blowing away remaining
> connections.
> *Oct 16 15:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 6:46 hours,
> with 0 circuits open. I've sent 239.99 GB and received 239.98 GB. We are
> currently hibernating.*
> Oct 16 15:46:11 venator Tor[3519]: Circuit handshake stats since last
> time: 27077/27077 TAP, 747536/747536 NTor.
> Oct 16 15:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1
> connections, 0 v2 connections, 0 v3 connections, and 44017 v4 connections;
> and received 17 v1 connections, 22 v2 connections, 2 v3 connections, and
> 37042 v4 connections.
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Hi

Your log also states:
Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent:
5.42 MB, Received: 6.82 MB, *Used: 6.90 MB / 48.00 GB, Rule: max*. The
current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours.
...
Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing
hibernation. No new connections will be accepted

Also notice that 192 + 48 = 240, which coinsides with your observed
increase.

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

Re: [tor-relays] No Gaurd

[r1610091651]

Stable flag is missing and it's required for Guard.

https://consensus-health.torproject.org/consensus-health-2017-09-27-12-00.html#E65D300F11E1DB12C534B0146BDAB6972F1A8A48




On Wed, 27 Sep 2017 at 15:30 Kurt Besig  wrote:

>
> https://atlas.torproject.org/#details/E65D300F11E1DB12C534B0146BDAB6972F1A8A48
>
> Relay looks pretty stable to me, I'm re-visiting the lack of guard
> status... ideas?
>
> ___
> 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] Accounting logic

[r1610091651]

Thanks nusenu for the pointer.

Looks like it's a real "undocumented feature" ;-), and matches the
behaviour I'm seeing.

On a related note, is there a way to search the archives on specific
keywords?

Thanks
Seb

On Sun, 24 Sep 2017 at 23:44 nusenu  wrote:

> Teor (tor developer) explained it in the past, you can find it here:
> https://lists.torproject.org/pipermail/tor-relays/2015-May/006956.html
>
> ticket to improve documentation:
> https://trac.torproject.org/projects/tor/ticket/23635
>
> --
> https://mastodon.social/@nusenu
> https://twitter.com/nusenu_
>
> ___
> 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] Accounting logic

[r1610091651]

Hi

I'm on version 0.3.1.7 on Linux.

I've following config entries:
AccountingMax 1639 GBytes
AccountingStart month 24 00:00


Today I've discovered following log entries:
Sep 24 00:00:00.000 [notice] Configured hibernation.  This interval began
at 2017-09-24 00:00:00; the scheduled wake-up time is 2017
-09-28 16:44:28; we expect to exhaust our quota for this interval around
2017-10-21 20:52:28; the next interval begins at 2017-10-24
 00:00:00 (all times local)
Sep 24 00:00:01.000 [notice] Commencing hibernation. We will wake up at
2017-09-28 16:44:28 local time.
Sep 24 00:00:01.000 [notice] Going dormant. Blowing away remaining
connections.

For context, Tor did not exceed previous quota and was operating normally
before 24 september 00:00.

To me this is not what I would have expected as behaviour given the config.
My exception is that the tor would reset counters at month end/beginning
and continue operation.

Is it a bug?

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

Re: [tor-relays] Rate setting in tor

[r1610091651]

On Fri, 8 Sep 2017 at 07:19 Roger Dingledine <a...@mit.edu> wrote:

> On Fri, Sep 08, 2017 at 07:14:58AM +0200, Andreas Krey wrote:
> > On Thu, 07 Sep 2017 22:56:17 +0000, r1610091651 wrote:
> > > RelayBandwidthRate 2048 KBytes
> > > RelayBandwidthBurst 2048 KBytes
> > >
> > > But using arm, I'm seeing that tor is not honoring these settings, with
> > > bursts frequently exceeding the value.
> >
> > That's the point of the Burst - there is a bucket that is
> > filled up with unused bandwidth, up to the Burst value,
> > and before the relay throttles down to RB-Rate it also
> > lets as many byte pass as the bucket currently has.
> >
> > Means that with your setting your relay can pass up to
> > 4 MByte in any given second (but not in every second).
>
> No, with these values the relay will push up to 2MBytes in each direction
> each second. When the Burst is the same as the Rate, it's essentially
> just like you're using the Rate. It doesn't add them.
>
> My guess is that the original poster is confused because they wrote
> "KBytes" in their torrc, but arm defaults to bits.
>
> --Roger
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Thanks all for the feedback.

To provide some more info and evidence.

I indeed intend to limit both up & down traffic, through the relay. There
is no local / client traffic, only relayed.
I'm aware that the rate is in kilobytes. Also note that latest arm also
reports in kilobytes/s.
I was also able to verify rates reported by arm, by other network
monitoring means.
Just grabbed arm view:
[image: image.png]
And associated network view:
[image: image.png]

Basically what I'm seeing is that tor ignores relay burst rate setting for
relayed traffic.

Based on your comments, what I'm doing is correct way of rate
configuration. Right?
So it's a bug then?

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

[tor-relays] Rate setting in tor

[r1610091651]

Hi

I've a question regarding the rate setting in torrc and tor honoring it.
I've set up a tor relay with following rate settings:
RelayBandwidthRate 2048 KBytes
RelayBandwidthBurst 2048 KBytes

But using arm, I'm seeing that tor is not honoring these settings, with
bursts frequently exceeding the value.
The average rate control seems to be working fine though.

[image: image.png]

What am I missing?

I'm running 0.3.0.10 on Linux.

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

Re: [tor-relays] Doing the english [Was: Kitten1 and kitten2 compromised (guard/hs/fallback directory)]

[r1610091651]

Also explained by British dictionary:
https://www.merriam-webster.com/words-at-play/flammable-or-inflammable

Cheers

On Wed, 24 May 2017 at 02:03 Torix  wrote:

> I was told in 1955 that "flammable" was invented to put on trucks because
> so many people - including many truck drivers - thought that inflammable
> meant "not flammable".  Like independent vs. dependent, indivisble vs.
> divisible etc.
>
>
> Sent with ProtonMail  Secure Email.
>
>  Original Message 
> Subject: Re: [tor-relays] Doing the english [Was: Kitten1 and kitten2
> compromised (guard/hs/fallback directory)]
> Local Time: May 21, 2017 11:22 AM
> UTC Time: May 21, 2017 3:22 PM
> From: pipat...@gmail.com
> To: tor-relays@lists.torproject.org
>
> On Sun, May 21, 2017 at 5:16 PM, Ian Zimmerman  wrote:
> > On 2017-05-20 18:07, Chris Kerr wrote:
> >
> >> Yes, 'sensible', like 'actually' and 'eventually', is a "false friend"
> >> whose meaning in English is different from that in just about every
> >> other European language (but the other languages are consistent with
> >> each other e.g. 'sensible' in French and 'sensibel' in German have
> >> the same meaning), which sometimes leads to confusion. Even more
> >> confusingly, 'insensible' is not the opposite of 'sensible' but rather
> >> means either 'imperceptible' or 'unconscious'.
> >
> > I have mused about this myself. The most curious thing is that English
> > is not even consistent with itself here. Think about the title of a
> > famous enlightenment era novel. The meaning of the nouns is precisely
> > inverted from the adjectives.
>
> Inflammable means flammable? What a country!
> ___
> 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] Unwarranted discrimination of relays with dynamic IP

[r1610091651]

Hi all

Just to add some perspective...

I'm running a relay on dynamic ip. My ISP will usually not change my IP
assignment as long as it's in use.
The platform in use is not Rasberry Pi, but Odroid C2. Also an ARM, but a
bit more powerful one.

Kind regards

On Mon, 5 Dec 2016 at 16:36 Rana  wrote:

>
> -Original Message-
> >From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On
> Behalf Of Duncan Guthrie
> >
> >Keep in mind also that the Raspberry Pi (at least the first one anyway)
> can only push around 1MB/s tops. The ethernet port is basically held on by
> the equivalent of a piece of string! >They're suitable for a small mail or
> web server, or some sort of network probe, but not really for any large
> application.
> >
> >Duncan
>
> I am pretty sure your info is out of date. The $35 Raspi3 has four 1.2 GHz
> cores and 1GB RAM. On my Raspi (that admittedly does not see much traffic)
> CPU utilization hovers somewhere around 1% and total memory utilization by
> Tor and the rest of Linux together is 11%. Which is irrelevant since Tor
> network will not let it even near 1 mbit/s because - I believe - of its
> dynamic IP
>
> I would like to hear about ONE Raspi Tor operator who was allowed by
> DirAuths (or bwauths or whatever)  to come even near 1 mbit/s bandwidth
> utilization
>
> Rana
>
> ___
> 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] Tor Fails to Start on Ubuntu 16.04

[r1610091651]

On Sun, 13 Nov 2016, 04:43 teor,  wrote:

>
> > On 13 Nov. 2016, at 12:17, heartsucker 
> wrote:
> >
> > Hey everyone
> >
> > I have a fresh install of Ubuntu 16.04 that is unable to start Tor.
> >
> > Some useful output:
> >
> > root@tor-1 ~ # uname -a
> > Linux tor-1 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016
> > x86_64 x86_64 x86_64 GNU/Linux
> > root@tor-1 ~ # apt-cache policy tor
> > tor:
> >  Installed: 0.2.8.9-1~xenial+1
> >  Candidate: 0.2.8.9-1~xenial+1
> >  Version table:
> > *** 0.2.8.9-1~xenial+1 500
> >500 http://deb.torproject.org/torproject.org xenial/main amd64
> > Packages
> >100 /var/lib/dpkg/status
> > root@tor-1 ~ # journalctl -u tor
> > ...
> > Nov 13 00:52:39 tor-1 systemd[1]: Starting Anonymizing overlay network
> > for TCP (multi-instance-master)...
> > Nov 13 00:52:39 tor-1 systemd[1]: Started Anonymizing overlay network
> > for TCP (multi-instance-master).
> > 
> >
> > Tor fails to get beyond this message for any config I have tried
> > (including the default). I tried replacing the systemd unit file with
> > one of my own and was able to start Tor, however it would crash every 5
> > minutes (though the logs. The commands used in the systemd file and the
> > command init.d script are both able to start Tor correctly if I run them
> > in a TTY as I can see from a second terminal.
> >
> > Is anyone else running Tor on Xenial, and if so, have they run into this
> > problem?
>
> Do you have apparmor installed?
> If so, what are the logs?
>
> In any case, what does Tor try to do every 5 minutes?
> (Look at the info or debug logs.)
>
> 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
>

After having installed tor on 16.04, i had to disable & re-enable te
service manually to make it start. Then i also had to disable apparmor,
override profile to none

Then it worked

Seb

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

Re: [tor-relays] Questions regarding arm on Debian

[r1610091651]

On Sat, 12 Nov 2016 at 12:41 Dennis Christ  wrote:

> Yes that is what i tried to do. But it does not work in my case.
>
> $ arm
> [Errno 13] Permission denied: '/var/lib/tor/control_auth_cookie'
>
> Even if my user is in the group debian-tor the user has no right to
> access /var/lib/tor.
>
> $ ls -l /var/lib | grep tor
> drwx--S--- 4 debian-tordebian-tor4096 Nov 12 12:38 tor
>
>
> Am 12.11.2016 um 10:33 schrieb Louie Cardone-Noott:
> > On Fri, 11 Nov 2016, at 07:16 PM, diffusae wrote:
> >> Yes, you are right. But CookieAuthentication should work. You cannot
> >> query all of the connections without access to /var/lib/tor. You only
> >> will see circuits. I suggest to use "sudo -u debian-tor arm", if you
> >> like to use all of the arm pages. Otherwise you have to change the
> >> permissions. In my case, there is also the setgid flags on the
> >> directories (2700 drwx--S---).
> > Sorry not fully read the correspondence here but perhaps a tidier option
> > might be the one recommended on the tor website[1] of doing
> >
> > sudo adduser $USER debian-tor
> >
> > The alternative of running as the debian-tor user is a 'bad idea', see
> > [2] from last July
> >
> > [1] https://www.torproject.org/docs/tor-relay-debian.html.en#after
> > [2]
> > https://lists.torproject.org/pipermail/tor-relays/2016-July/009608.html
>

Hi

You could just modify the systemd service file for tor, with something like
ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d
/var/run/tor
ExecStartPre=/usr/bin/install -Z -m 02750 -o debian-tor -g debian-tor -d
/var/log/tor

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

Re: [tor-relays] Drop in consensus weight

[r1610091651]

Based on found numbers, some thoughts:
* shouldn't there be more authority servers? DNS system has 13 root servers
spread over the globe...
* not all authority servers are equal:
** reported data varies greatly between servers
https://consensus-health.torproject.org/consensus-health-2016-11-08-19-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE
: maatuska=1400 <> gabelmoo=4060
** some authorities vary greatly in reported data:
https://consensus-health.torproject.org/consensus-health-2016-11-08-19-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE:
gabelmoo=4060
https://consensus-health.torproject.org/consensus-health-2016-11-08-18-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE:
gabelmoo=2110
* authority participating in consensus change, and with only few active
(4-5) at a time, impact of a single authority on network is amplified

By having more servers
* consensus would be more stable (low-median)
* leading to more accurate assessment of nodes
* and wider utilisation of the available nodes
* leading to higher network throughput

Does that sound plausible?

Cheers
Seb

On Tue, 8 Nov 2016 at 17:37 r1610091651 <r1610091...@telenet.be> wrote:

> Thanks for the link to consensus-health, based data available:
>
> 05/11 17:00
> longclaw=4540
> gabelmoo=4170
> moria1=4410
> faravahar=2520
> => cons: 4170
>
> 05/11 18:00
> longclaw=4550
> gabelmoo=*2170*
> moria1=4410
> faravahar=2520
> => cons: *2520*
>
> So that explains the drop.
>
> Seb
>
> On Tue, 8 Nov 2016 at 13:40 teor <teor2...@gmail.com> wrote:
>
>
> > On 8 Nov. 2016, at 23:32, r1610091651 <r1610091...@telenet.be> wrote:
> >
> > The previous drops, i know why they happened (related to server
> unavailability) so I know the cause. For 5th however I have no clue.
>
> As far as I can tell, the relay is accurately measured.
>
> Sometimes, this means that you get a lower measurement than you might have
> had before.
>
> Accurate bandwidth measurements are a good thing for tor users, even if the
> changes in the measurement are sometimes (temporarily) disappointing to
> relay
> operators.
>
> If you want to improve the measurements, try adding more bandwidth.
> For your relay, this means increasing BandwidthRate and BandwidthBurst.
>
> 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
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Drop in consensus weight

[r1610091651]

Thanks for the link to consensus-health, based data available:

05/11 17:00
longclaw=4540
gabelmoo=4170
moria1=4410
faravahar=2520
=> cons: 4170

05/11 18:00
longclaw=4550
gabelmoo=*2170*
moria1=4410
faravahar=2520
=> cons: *2520*

So that explains the drop.

Seb

On Tue, 8 Nov 2016 at 13:40 teor <teor2...@gmail.com> wrote:

>
> > On 8 Nov. 2016, at 23:32, r1610091651 <r1610091...@telenet.be> wrote:
> >
> > The previous drops, i know why they happened (related to server
> unavailability) so I know the cause. For 5th however I have no clue.
>
> As far as I can tell, the relay is accurately measured.
>
> Sometimes, this means that you get a lower measurement than you might have
> had before.
>
> Accurate bandwidth measurements are a good thing for tor users, even if the
> changes in the measurement are sometimes (temporarily) disappointing to
> relay
> operators.
>
> If you want to improve the measurements, try adding more bandwidth.
> For your relay, this means increasing BandwidthRate and BandwidthBurst.
>
> 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
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Drop in consensus weight

[r1610091651]

The previous drops, i know why they happened (related to server
unavailability) so I know the cause. For 5th however I have no clue.

Seb

On Tue, 8 Nov 2016 at 13:12 teor <teor2...@gmail.com> wrote:

>
> > On 8 Nov. 2016, at 22:52, r1610091651 <r1610091...@telenet.be> wrote:
> >
> > Hi all
> >
> > The consensus weight of the relay I'm running drop recently (5th of nov)
> to almost half of previous value. To my knowledge there was no changes on
> my end.
> >
> >
> https://atlas.torproject.org/#details/36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE
>
> If you look at the 1 month graph, this does not seem to be unusual for your
> relay.
>
> > Is there a way to identify the cause of this drop?
>
> The bandwidth authorities measured your relay as being able to handle
> approximately 2490 KByte/s. (High 4370, Low 1410, Median 2490.)
>
> (large page)
>
> https://consensus-health.torproject.org/consensus-health-2016-11-08-11-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE
>
> Your relay's observed bandwidth is also 2.39 MByte/s (hover over the
> bandwidth heading in atlas for these details), so its consensus weight
> will be limited to approximately ~2447 (KByte/s) anyway.
>
> If you want to increase these measurements, try increasing the
> BandwidthRate
> and BandwidthBurst in your relay's torrc, and waiting a week.
>
> > Is there anyone else in same situation?
>
> The system is functioning as designed: your relay's observed maximum
> bandwidth is almost identical to the bandwidth measured by the bandwidth
> authorities.
>
> If you want to fix this, add more bandwidth.
>
> 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
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Drop in consensus weight

[r1610091651]

Hi all

The consensus weight of the relay I'm running drop recently (5th of nov) to
almost half of previous value. To my knowledge there was no changes on my
end.

https://atlas.torproject.org/#details/36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE

Is there a way to identify the cause of this drop? Is there anyone else in
same situation?

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