Re: [tor-relays] Disparity between download and upload traffic

[Gage Parrott]

Teor,

Yes, I can absolutely do that, let me set up logging and give it a couple
of hours to get some data for you.

I can't say that I'm terribly comfortable sending the logs via a public,
archived distribution list.  Mind if I email them to you (or a non-public
distribution) directly?  We can update this thread later if we figure out
that there is indeed an issue so anyone else in this position can learn.

Thanks again!
gp

On Tue, Jan 3, 2017 at 12:13 AM, teor  wrote:

>
> > On 27 Dec 2016, at 03:47, Gage Parrott  wrote:
> >
> > Morning, everyone,
> >
> > I recently migrated my bridge relay over to a VM and everything seems to
> be working fine except for one oddity.  I consistently see lines like this
> in tor's log file on the new machine:
> >
> > Dec 25 23:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 5:59
> hours, with 43 circuits open. I've sent 1.78 GB and received 28.37 GB.
> > Dec 25 23:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen
> 2 unique clients.
> > Dec 26 05:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 11:59
> hours, with 105 circuits open. I've sent 1.87 GB and received 29.24 GB.
> > Dec 26 05:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen
> 2 unique clients.
> >
> > Notice the amount of data sent and received.  Can anyone think of why
> there would be such a large discrepancy between the amount of traffic
> downloaded versus uploaded?  This behavior persists after reboots, as well.
> >
> > I thought maybe it was downloading a ton of directory data, but is there
> really a GB's worth of directory data to download every six hours??  Also,
> the logs on my old machine (pre-migration, one line pasted below for
> reference) indicated that nearly the same amount of data was being sent as
> was being received.  Any ideas on why would this have changed?
> >
> > Dec 07 06:02:03.000 [notice] Heartbeat: Tor's uptime is 4 days 6:12
> hours, with 78 circuits open. I've sent 33.71 GB and received 33.47 GB.
> >
> > Any help is greatly appreciated.  Thanks a bunch and merry Christmas!
>
> It looks like you have very few clients.
> Perhaps those clients have switched to using interactive protocols?
> Or, more precisely, perhaps those clients are sending almost-empty
> cells, and then receiving back almost-full cells in response?
> (This could be an amplification attack, or simply lots of downloads.)
>
> On the other hand, your bridge could be repeatedly asking for directory
> documents. If this is the case, we'd *really* like to know what is
> causing the issue. Please send more logs, at info-level if possible.
>
> 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] Current pluggable transport recommendation

[Alexander Dietrich]

Hi,

the obfs2 pluggable transport was deprecated a while ago since it was 
easy to detect, but obfs3 was still considered safe, IIRC. Has anything 
changed here?


I was just wondering if new bridges should only run obfs4, or if it's 
fine to run obfs3 at the same time.


Best regards,
Alexander
--
PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] zwieb...@online.de relays: MyFamily fixed

[nusenu]

thanks for fixing it!

+-++
| nickname| eMyFamilyCount |
+-++
| chisinau2onion  |29. |
| rigaonion   |29. |
| chisinau2onion2 |29. |
| budweisonion4   |29. |
| budweisonionb4  |29. |
| budweisonion5   |29. |
| budweisonion|29. |
| budweisonion5b  |29. |
| budweisonionb   |29. |
| montrealonion   |29. |
| alsaceonion |29. |
| quebeconion |29. |
| milanoonion |29. |
| goethe  |29. |
| schiller|29. |
| schillerb   |29. |
| goetheb |29. |
| thueronionb |29. |
| heineb  |29. |
| heine   |29. |
| bsdonion|29. |
| thueronion  |29. |
| budapestonion   |29. |
| humboldt|29. |
| montrealonionb  |29. |
| alsaceonionb|29. |
| quebeconionb|29. |
| milanoonionb|29. |
| hecker  |29. |
+-++
29 rows



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[nusenu]

>> https://github.com/ornetstats/stats/blob/master/o/main_guard_operators.txt
> 
> I do not know how to interpret this table. How many guards are there at any 
> given time?

The list includes all relays having
- the guard flag
_and_ a
- guard probability > 0%*
now, 2079 relays currently.
732 of them have no ContactInfo set (representing ~30.7% guard probability).


*(as reported by https://onionoo.torproject.org)



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] consensus-health

[David Goulet]

On 03 Jan (18:24:07), Felix wrote:
> https:// consensus-health.torproject.org/
> (observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00)
> shows
> * dannenberg: Missing entirely from consensus

The ed25519 key of dannenberg expired so it has to be fixed to resolved
the situation. I believe Andreas has been notified already of this.

> * faravahar: Missing Signature! Valid-after time of auth's displayed
> consensus: 2017-01-03 15:00:00

This will continue to be as long as faravahar doesn't update to 0.2.9.8+
as it's not understanding the consensus-method that the other dirauth
have voted on.

> * moria1: Sees only 2620 relays running

This is still a mystery... this happens sometimes when moria1 is run
under valgrind or maybe some network issues. Or maybe some bug in 0.3.0
so we'll see about it.

Cheers!
David

> 
> Is https://
> lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html
> ok ?
> 
> -- 
> imho - like always
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


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

[tor-relays] consensus-health

[Felix]

https:// consensus-health.torproject.org/
(observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00)
shows
* dannenberg: Missing entirely from consensus
* faravahar: Missing Signature! Valid-after time of auth's displayed 
consensus: 2017-01-03 15:00:00

* moria1: Sees only 2620 relays running

Is https:// 
lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html 
ok ?


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

Re: [tor-relays] Speed up of reconnections after IP Address change

[Toralf Förster]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/03/2017 05:45 PM, balbea16 wrote:
> stops and then restarts the Tor service again
wouldn't be a SIGHUP enough ?

- -- 
Toralf
PGP: C4EACDDE 0076E94E
-BEGIN PGP SIGNATURE-

iHYEAREIAB4FAlhr2D4XHHRvcmFsZi5mb2Vyc3RlckBnbXguZGUACgkQxOrN3gB2
6U5VzAD+LhaG1aapPdSIWx+3V8wk9nt6RyatD9wBsNL4lk/goWIA/jnEiWduJnW4
E5YQRhJ6+oZveV/9VjeinpFncH2/yag4
=S1mi
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Speed up of reconnections after IP Address change

[balbea16]

Hi ThereI've just written a simple bash script which verifies (in a while loop) 
every 2 minutes if the OR address has been changed by my ISP. If so, it stops 
and then restarts the Tor service again. Then it sleeps for 24 hours and starts 
the 2 minute loop again. Not very sophisticated, but it might work. Mike___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] how to generate relay keys manually (before actually running the relay)

[Sec INT]

Thanks - will do

Cheers
Mark B
Snaptor.co.uk (non commercial)


On 3 Jan 2017, at 16:24, nusenu  wrote:

>>> Tipp: If you are planing to grow beyond your 31 relays I recommend
>>> you preemptively generate the keys for your upcoming relays so you
>>> don't have to touch all other relays everytime you add a single
>>> relay (to the MyFamily line).
> 
> 
>> How do you pregenerate keys? Id be interested as Im spinning up
>> quite a few soon
> 
> create a folder per tor instance:
> 
> mkdir future-relay1 future-relay2 ...
> 
> 
> then invoke tor manually (this will just generate keys and exit after that):
> 
> tor --PublishServerDescriptor 0 --orport auto --list-fingerprint
> --datadirectory future-relay1 --Log "err stdout"
> 
> 
> tor --PublishServerDescriptor 0 --orport auto --list-fingerprint
> --datadirectory future-relay2 --Log "err stdout"
> 
> ...
> 
> In these folders you will then find the fingerprint that you can use in
> MyFamily, so you don't have to touch your existing relays anymore once
> you actually use these generated keys on new relays.
> 
> Make sure you take care of filesystem permissions when using these keys
> on the actual relay.
> 
> ___
> 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] how to generate relay keys manually (before actually running the relay)

[nusenu]

>> Tipp: If you are planing to grow beyond your 31 relays I recommend
>> you preemptively generate the keys for your upcoming relays so you
>> don't have to touch all other relays everytime you add a single
>> relay (to the MyFamily line).


> How do you pregenerate keys? Id be interested as Im spinning up
> quite a few soon

create a folder per tor instance:

mkdir future-relay1 future-relay2 ...


then invoke tor manually (this will just generate keys and exit after that):

tor --PublishServerDescriptor 0 --orport auto --list-fingerprint
--datadirectory future-relay1 --Log "err stdout"


tor --PublishServerDescriptor 0 --orport auto --list-fingerprint
--datadirectory future-relay2 --Log "err stdout"

...

In these folders you will then find the fingerprint that you can use in
MyFamily, so you don't have to touch your existing relays anymore once
you actually use these generated keys on new relays.

Make sure you take care of filesystem permissions when using these keys
on the actual relay.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] zwieb...@online.de relays: MyFamily update required (new relay added)

[Sec INT]

Hi

How do you pregenerate keys? Id be interested as Im spinning up quite a few 
soon 

Cheers
Mark B
Snaptor.co.uk (non commercial)


> On 3 Jan 2017, at 00:43, nusenu  wrote:
> 
> Hi zwiebeln,
> 
> thanks for adding your 31. relay nicknamed 'hecker' !
> 
> Please do not forget to update your MyFamily on all relays.
> 
> Tipp:
> If you are planing to grow beyond your 31 relays I recommend you
> preemptively generate the keys for your upcoming relays so you don't
> have to touch all other relays everytime you add a single relay (to the
> MyFamily line).
> 
> 
> ++--+-++
> | first_seen | nickname | IP  | eMyFamilyCount |
> ++--+-++
> | 2016-04-11 | chisinau2onion   | 178.17.170.179  |30. |
> | 2016-05-14 | rigaonion| 195.123.209.184 |30. |
> | 2016-07-03 | chisinau2onion2  | 178.17.170.179  |30. |
> | 2016-08-28 | budweisonion4| 37.157.193.161  |30. |
> | 2016-09-10 | budweisonionb4   | 37.157.193.161  |30. |
> | 2016-09-16 | budweisonion5| 89.221.209.100  |30. |
> | 2016-09-18 | budweisonion | 37.157.196.97   |30. |
> | 2016-09-27 | budweisonionb| 37.157.196.97   |30. |
> | 2016-09-27 | budweisonion5b   | 89.221.209.100  |30. |
> | 2016-11-12 | montrealonion| 144.217.60.211  |30. |
> | 2016-11-12 | strasbourgonion  | 213.32.55.239   |30. |
> | 2016-11-14 | alsaceonion  | 149.202.238.204 |30. |
> | 2016-11-15 | milanoonion  | 158.58.170.150  |30. |
> | 2016-11-15 | quebeconion  | 144.217.60.239  |30. |
> | 2016-11-28 | goetheb  | 178.17.170.212  |30. |
> | 2016-11-28 | schiller | 178.17.170.27   |30. |
> | 2016-11-28 | goethe   | 178.17.170.212  |30. |
> | 2016-11-28 | schillerb| 178.17.170.27   |30. |
> | 2016-12-05 | heine| 51.15.53.83 |30. |
> | 2016-12-05 | bsdonion | 46.182.18.214   |30. |
> | 2016-12-05 | thueronionb  | 46.182.18.29|30. |
> | 2016-12-05 | thueronion   | 46.182.18.29|30. |
> | 2016-12-05 | heineb   | 51.15.53.83 |30. |
> | 2016-12-16 | budapestonion| 88.151.99.224   |30. |
> | 2016-12-18 | milanoonionb | 158.58.170.150  |30. |
> | 2016-12-18 | humboldt | 185.14.29.129   |30. |
> | 2016-12-18 | quebeconionb | 144.217.60.239  |30. |
> | 2016-12-18 | strasbourgonionb | 213.32.55.239   |30. |
> | 2016-12-18 | montrealonionb   | 144.217.60.211  |30. |
> | 2016-12-18 | alsaceonionb | 149.202.238.204 |30. |
> | 2017-01-02 | hecker   | 46.182.19.219   |   NULL |
> ++--+-++
> 31 rows
> 
> ___
> 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] Container tor relay

[Sec INT]

Had a search but cant find much info on running tor relays in containers 
specifically by proxmox lxc containers - I have a free server atm but dont 
really want to spinup a load of vms when I could do containers instead - its a 
load test for me but would mean quite a few relays running with gbps network 
card (all their own ip's)

Anyone tried this yet?

Cheers
Mark B
Snaptor.co.uk (non commercial)

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

Re: [tor-relays] The Onion Box v3.2: Web Interface for your Tor relay

[Sec INT]

Sounds good - I didnt know about this before so I'll have a look tonight 

Cheers
Mark B
Snaptor.co.uk (non commercial)


> On 3 Jan 2017, at 13:26, theonion...@gmx.com wrote:
> 
> Hello friends!
>  
> First of all I'd like to send you my greetings for 2017 wishing you and the 
> whole Tor community all the best and great success on the journey to support 
> the freedom of the internet.
>  
> There is a RC for v3.2 of The Onion Box available at GitHub. The changes 
> happened mostly in the background as preparation for the Box to monitor local 
> as well as remote relays. The first result of this endeavor is the new 
> section Family Performance that displays Onionoo network (bandwidth) data for 
> all relays within the family of the local relay.
>  
> Therefore I would like to ask especially those of you who run a number of 
> relays to give this version a try. I would be very happy to receive some 
> feedback (good or bad) or even some feature requests if you're interested in 
> a dedicated functionality.
>  
> The new release partially answers this request of nusenu.
>  
> Thank's for using The Onion Box!
> Have fun!
>  
> Best regards,
>  
> 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

[tor-relays] The Onion Box v3.2: Web Interface for your Tor relay

[theonionbox]

Hello friends!

 

First of all I'd like to send you my greetings for 2017 wishing you and the whole Tor community all the best and great success on the journey to support the freedom of the internet.

 

There is a RC for v3.2 of The Onion Box available at GitHub. The changes happened mostly in the background as preparation for the Box to monitor local as well as remote relays. The first result of this endeavor is the new section Family Performance that displays Onionoo network (bandwidth) data for all relays within the family of the local relay.

 

Therefore I would like to ask especially those of you who run a number of relays to give this version a try. I would be very happy to receive some feedback (good or bad) or even some feature requests if you're interested in a dedicated functionality.

 

The new release partially answers this request of nusenu.

 



Thank's for using The Onion Box!

Have fun!


 

Best regards,

 

Ralph

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

Re: [tor-relays] How can we trust the guards?

[Andreas Krey]

On Tue, 03 Jan 2017 11:34:19 +, Aeris wrote:
...
> And there is also an hardware bottleneck, because every components (mainly 
> ethernet & SD card here) are connected to the same physical USB controller 
> limited to 480Mbps for *overall* transfer (network + disk + others USB).

Which isn't that small. tor does not do disk (or 'other'), and 25MByte/s
is quite a lot - more than I can push with big iron due to traffic limits.

...
> No no, GB. 128GB is usual on server. We even begin to see 1TB RAM machine.

You mean 'this is what you usually get as a server machine',
not 'this is what tor typically uses, right?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] what to expect with baby exitnodes?

[Matt Traudt]

On 1/3/17 05:34, stinkyon...@sigaint.org wrote:

well the subject sums it up really I couldn't find a solid explanation. I
believe it was ARMA that explained the life cycle of a relay, so I'm
curious does this apply for exit nodes?
thanks for the clarification



The lifecycle for exits is different and simpler.

Expect to get as much traffic as you can carry within a few days or a 
week. Then expect it to never go away.


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

[tor-relays] what to expect with baby exitnodes?

[stinkyonion]

well the subject sums it up really I couldn't find a solid explanation. I
believe it was ARMA that explained the life cycle of a relay, so I'm
curious does this apply for exit nodes?
thanks for the clarification



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

[tor-relays] what to expect with baby exitnodes?

[stinkyonion]

well the subject sums it up really I couldn't find a solid explanation. I
believe it was ARMA that explained the life cycle of a relay, so I'm
curious does this apply for exit nodes?
thanks for the clarification



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

Re: [tor-relays] How can we trust the guards?

[Aeris]

> The question remains whether  NOT having access to my relay makes life
> easier for people. Sometimes I guess you are right. But when all the big
> relays get overloaded, small relays could provide MORE bandwidth than large
> relays.Both your and my statements are qualitative, I would like someone
> who knows the numbers to respond.

Currently, big relays are not really overloaded.
We have 55Gbps on guards, and overall bandwidth used at only 50%.
https://metrics.torproject.org/bwhist-flags.html
https://metrics.torproject.org/bandwidth.html

> There are 850 MB unused memory on my $35 Pi relay that is used to 7% of its 
link capacity.

On Pi, bottleneck is not RAM, but CPU to do crypto. Because no AES-NI 
extension on the CPU and very low CPU benchmark (AES256 30MBps max, compared 
to 500MBps with i5).
And there is also an hardware bottleneck, because every components (mainly 
ethernet & SD card here) are connected to the same physical USB controller 
limited to 480Mbps for *overall* transfer (network + disk + others USB).

> HUNDRED GB of RAM? I believe you mean hundred MB? In this case ditto.

No no, GB. 128GB is usual on server. We even begin to see 1TB RAM machine.

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How can we trust the guards?

[Rana]

>Any people who will use your relay on a circuit will also damn you to run such 
>small relay. This is so slow and not usable for day to day web surfing, 
>specially if you are well connected to Internet (fiber or decent ADSL).
>Personnally, I have around this speed directly for my ADSL Internet connection 
>(500/80kB), and I rant each day I have to upload something…

The question remains whether  NOT having access to my relay makes life easier 
for people. Sometimes I guess you are right. But when all the big relays get 
overloaded, small relays could provide MORE bandwidth than large relays.Both 
your and my statements are qualitative, I would like someone who knows the 
numbers to respond.

>Memory and TCP ports ?
>A node need to maintain thousands of circuits. This consumes a lot of memory 
>(400MB on one of my guard) and a lot of TCP sockets (14k sockets).

There are 850 MB unused memory on my $35 Pi relay that is used to 7% of its 
link capacity. Therefore the memory limitation you cited is irrelevant.

>Those parameters don’t scale very well if you have more nodes (65k TCP port 
>only, or some hundred of GB of RAM). 

HUNDRED GB of RAM? I believe you mean hundred MB? In this case ditto.

>Currently, with standard hardware, seems we can’t host more than 10 or 20× 
>more nodes than today without hitting some hardware limit.

10x more nodes than today sounds good to me. My understanding is that Tor is 
nowhere near breaking out of its 7K and moving to this limit.  Therefore, the 
spare capacity of small relays could be used.

Rana

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

Re: [tor-relays] How can we trust the guards?

[Aeris]

> 93% of the time despite having decent ultra-stable 153 KB/s bandwidth
> and static IP);
> The same relay is VERY reliable - totally stable for weeks,
> yet still under-used only because it is small.

Any people who will use your relay on a circuit will also damn you to run such 
small relay. This is so slow and not usable for day to day web surfing, 
specially if you are well connected to Internet (fiber or decent ADSL).
Personnally, I have around this speed directly for my ADSL Internet connection 
(500/80kB), and I rant each day I have to upload something…

> 4. I do not see why the current design of Tor prevents using more relays. I
> do not believe the current design is limited by design in the number of
> relays it can support.

Memory and TCP ports ?
A node need to maintain thousands of circuits. This consumes a lot of memory 
(400MB on one of my guard) and a lot of TCP sockets (14k sockets).
Those parameters don’t scale very well if you have more nodes (65k TCP port 
only, or some hundred of GB of RAM). Currently, with standard hardware, seems 
we can’t host more than 10 or 20× more nodes than today without hitting some 
hardware limit.

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Speed up of reconnections after IP Address change

[Rana]

Such script is one typical entry that I would put on the small relay operator 
Wiki (see my earlier post)

Rana

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Dr Gerard Bulger
Sent: Tuesday, January 03, 2017 10:49 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Speed up of reconnections after IP Address change

I would be interested in such a script to SIGHUP each time IP changes if anyone 
makes one!



-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: 03 January 2017 07:32
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Speed up of reconnections after IP Address change


> On 22 Dec 2016, at 18:19, balbea16  wrote:
> 
> Hi There,
> I only have a dynamic IP address and my ISP changes it almost every 
> time
after 24 hours. It is somehow sad to see 1.400 connections drop to almost none. 
After the change it takes 20 minutes until my OR notices this (our IP Address 
has changed from ...). It than takes another hour until the connections start 
to actualy rebuild. This means it takes more than an hour (every per day) to 
reach the normal operating Mode.
> 
> Is there any way to speed up this process? Could adjust the torrc 
> script
for instance?

No, sorry, new relay details are only published in the tor consensus every hour.

To reduce the 20 minute delay, you could write a script that issues a SIGHUP
(reconfigure) to tor when your address changes.

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