Re: [tor-relays] Alleged Family Members / Stable flag "issues"

[tor]

>>Yes this entry is gone, shortly (believe 1 day) after the node was taken 
>>down. 

>>Maybe it's due to the fact I comments the MyFamily config option out, I'll 
>>put 
>>it back, just referencing itself. Maybe that will clear things out.

Yep, I think that will probably fix it. You'll need to trigger Tor to re-upload 
its descriptor too. A restart of the Tor service will do it (although there may 
be a better way). I've noticed similar issues before with Atlas holding on to 
old nodes until that's done.

Cheers.

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

Re: [tor-relays] Alleged Family Members / Stable flag "issues"

[Stijn Jonker]

Hi Teor,

Thanks for responding:

On 14 Dec 2017, at 22:56, teor wrote:


> On 15 Dec 2017, at 06:38, Stijn Jonker  wrote:


For a little short of a year I'm running Relay SJC01 
(328E54981C6DDD7D89B89E418724A4A7881E3192), there was some unnoticed 
outage of the relay which caused a couple days of downtime. This was 
at the end of Nov, oddly enough I don't seem to get back the "Stable" 
flag.


In searches I found some conflicting answers, it's either 7 days of 
uptime, a median of seven days of the entire uptime and/or the advice 
to check 
https://consensus-health.torproject.org/consensus-health-2017-12-14-18-00.html#328E54981C6DDD7D89B89E418724A4A7881E3192



The exact figure depends on each authority and its history of your
relay's stability. And how that stability compares to all other relays
it has measured.
What I don't understand is the differences in the output of the 
concensus:
- The concensus nodes that don't have IPv6 (assumed from "KnownFlags" 
from top of page. (longclaw, dizum, moria1 and faravahar) list my 
relay with Stable/Guard.
- The concensus nodes that do assign the "ReachableIPv6" flag, don't 
have my relay listed with those flags.



Does your relay have a stable IPv6 connection?
Was it down over IPv6 at some point in the past?


The IPv6 connectivity is not less stable then the IPv4. The IPv6 is 
native, and used in day-2-day usage as well. Also smokeping/Nagios (ran 
via an other device, but same uplink) don't report any differences in 
connectivity (or the lack thereof).




Alternately, the authorities that measure IPv6 may see the entire set 
of relays
as being less stable. (I can't imagine how they would see them as more 
stable.)

But if this were the case, they would be more likely to give the flag.
To test the IPv6 function, I took an VM outside of my network and ran 
Tor with "UseBridges" only allowing via iptables IPv6 out to my relay 
as entry node, and it the relay is/was functioning on IPv6.



How often does your IPv6 go down?


On average, I would say one or two hours a month.

Now happy to wait an other week/month etc for the stable flag. It 
doesn't add value to me, but I'm more curious why the flag doesn't 
return.



Please wait a few more days.


:-) I'll wait thanks for the response.

Stijn

--
Yours Sincerely / Met Vriendelijke groet,
Stijn Jonker
sjcjon...@sjc.nl
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Alleged Family Members / Stable flag "issues"

[Stijn Jonker]

Hi Tor,

On 14 Dec 2017, at 21:37, tor wrote:

The same with the Alleged Family Member, I had an relay / exit with a 
reduced
exit policy ($F8333E028E952840C1B93DAEE20880F75B90A68A) but that has 
been gone
for quite some weeks (months) as it was taken down by the hoster. Now 
all
info I can find is that when the relay doesn't announce this anymore 
one can

expect it to be gone after some days/weeks.



F8333E028E952840C1B93DAEE20880F75B90A68A does seem to be gone from 
Atlas when searching for it directly. Have you removed the reference 
to it from the MyFamily line of the relay that's still up?


Yes this entry is gone, shortly (believe 1 day) after the node was taken 
down. Maybe it's due to the fact I comments the MyFamily config option 
out, I'll put it back, just referencing itself. Maybe that will clear 
things out.


Again not a major issue in my view, but it kind of feels like stale data 
somewhere. If it's not on my side then I'm sure it will correct at some 
point in time.


thx,
Stijn

--
Yours Sincerely / Met Vriendelijke groet,
Stijn Jonker
sjcjon...@sjc.nl
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] exit relay

[teor]

On 15 Dec 2017, at 09:14, Toralf Förster  wrote:

>> On 12/14/2017 11:08 PM, Sebastian Hahn wrote:
>> If you don't want to run an Exit relay, set ExitRelay 0.
> Not needed IMO - I'm under the impression that nowadays with recent Tor 
> versions a user must opt-in to configure Tor to be an exit.

No, we have not changed this default.
And if we do change it, we will remove the warning seen by the operator.

The latest manual page says:

ExitRelay 0|1|auto
Tells Tor whether to run as an exit relay. If Tor is running as a non-bridge 
server, and ExitRelay is set to 1, then Tor allows traffic to exit according to 
the ExitPolicy option (or the default ExitPolicy if none is specified).
…
If ExitRelay is set to "auto", then Tor behaves as if it were set to 1, but 
warns the user if this would cause traffic to exit. … (Default: auto)

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

Re: [tor-relays] exit relay

[Toralf Förster]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/14/2017 11:08 PM, Sebastian Hahn wrote:
> If you don't want to run an Exit relay, set ExitRelay 0.
Not needed IMO - I'm under the impression that nowadays with recent Tor 
versions a user must opt-in to configure Tor to be an exit.

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

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWjL3uhccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpToTgAP9nYfBgBzcRe1ljF35SCrePFzDr
3fQUEPuCsFRr15sm9gD8CHmEE9KjBvBeTecmqzgmsgQLPcfSVlshncGyvbdbX+0=
=8p3U
-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] exit relay

[Sebastian Hahn]

> On 14. Dec 2017, at 23:04, Evangelos Meintasis  
> wrote:
> 
> Hello to all, 
> I got this warning :
> [warn] Tor is running as an exit relay. If you did not want this behavior, 
> please set the ExitRelay option to 0.
> 
> But in /etc/tor/torrc file, I can not locate an y EXITRELAY option.
> Should I just type it without comments there with the 0 flag?
> Thank you!

Do you *WANT* to run a nexit relay? Then everything is fine and
you can ignore the warning, or set ExitRelay 1, or set an ExitPolicy.
If you don't want to run an Exit relay, set ExitRelay 0.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] exit relay

[Evangelos Meintasis]

Hello to all,
I got this warning :
[warn] Tor is running as an exit relay. If you did not want this behavior, 
please set the ExitRelay option to 0.

But in /etc/tor/torrc file, I can not locate an y EXITRELAY option.
Should I just type it without comments there with the 0 flag?
Thank you!

Vagelis.

Sent from [ProtonMail](https://protonmail.ch), encrypted email based in 
Switzerland.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Alleged Family Members / Stable flag "issues"

[teor]

> On 15 Dec 2017, at 06:38, Stijn Jonker  wrote:
> 
> For a little short of a year I'm running Relay SJC01 
> (328E54981C6DDD7D89B89E418724A4A7881E3192), there was some unnoticed outage 
> of the relay which caused a couple days of downtime. This was at the end of 
> Nov, oddly enough I don't seem to get back the "Stable" flag.
> 
> In searches I found some conflicting answers, it's either 7 days of uptime, a 
> median of seven days of the entire uptime and/or the advice to check 
> https://consensus-health.torproject.org/consensus-health-2017-12-14-18-00.html#328E54981C6DDD7D89B89E418724A4A7881E3192
> 
The exact figure depends on each authority and its history of your
relay's stability. And how that stability compares to all other relays
it has measured.
> What I don't understand is the differences in the output of the concensus:
> - The concensus nodes that don't have IPv6 (assumed from "KnownFlags" from 
> top of page. (longclaw, dizum, moria1 and faravahar) list my relay with 
> Stable/Guard.
> - The concensus nodes that do assign the "ReachableIPv6" flag, don't have my 
> relay listed with those flags.
> 
Does your relay have a stable IPv6 connection?
Was it down over IPv6 at some point in the past?

Alternately, the authorities that measure IPv6 may see the entire set of relays
as being less stable. (I can't imagine how they would see them as more stable.)
But if this were the case, they would be more likely to give the flag.
> To test the IPv6 function, I took an VM outside of my network and ran Tor 
> with "UseBridges" only allowing via iptables IPv6 out to my relay as entry 
> node, and it the relay is/was functioning on IPv6.
> 
How often does your IPv6 go down?
> Now happy to wait an other week/month etc for the stable flag. It doesn't add 
> value to me, but I'm more curious why the flag doesn't return.
> 
Please wait a few more days.

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

Re: [tor-relays] #34C3 Tor Assembly

[info]

On 14.12.2017 22:11, Nicolas Braud-Santoni wrote:
> On Thu, Dec 14, 2017 at 10:05:28PM +0100, i...@artikel5ev.de wrote:
>> [...]
>> It would be great to have a little bigger room than last year.
> 
> Yes, there was a bit of a mix-up last year, so we had to make to with
> the rooms that were still available.
> 

Yes, I thought so. Didn't want to complain. Thanks for taking care!

Looking forwart to the meetup.

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

Re: [tor-relays] #34C3 Tor Assembly

[Nicolas Braud-Santoni]

On Thu, Dec 14, 2017 at 10:05:28PM +0100, i...@artikel5ev.de wrote:
> [...]
> It would be great to have a little bigger room than last year.

Yes, there was a bit of a mix-up last year, so we had to make to with
the rooms that were still available.


Best,

  nicoo


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

Re: [tor-relays] #34C3 Tor Assembly

[info]

Hey nicco,


On 14.12.2017 21:56, Nicolas Braud-Santoni wrote:

> 
> I will facilitate again the Tor Relays operators meetup, like in the last 
> couple
> of years (it was previously organised by Moritz).
> 
> It's not currently listed in the 34C3 wiki because registration for
> self-organised sessions is not yet open.
> 

that is great, if you need any help let us know, at least some of us
were there in the last years.
It would be great to have a little bigger room than last year.

Looking forward to the meetup!

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

Re: [tor-relays] #34C3 Tor Assembly

[Nicolas Braud-Santoni]

Hi,

On Wed, Dec 13, 2017 at 10:46:59PM +0100, Artikel 5 e.V. wrote:
> Hello,
> when I looked around in the wiki for this years Chaos Communication
> Congress in Leipzig (Germany) I found that there is not much happening
> around Tor.

I will facilitate again the Tor Relays operators meetup, like in the last couple
of years (it was previously organised by Moritz).

It's not currently listed in the 34C3 wiki because registration for
self-organised sessions is not yet open.


Best,

  nicoo


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

Re: [tor-relays] Dir address none

[Fabian A. Santiago]

December 14, 2017 3:39 PM, "Fabian A. Santiago"  
wrote:

> December 14, 2017 1:10 PM, "teor"  wrote:
> 
>>> On 15 Dec 2017, at 05:01, Fabian A. Santiago  
>>> wrote:
>>> 
>>> December 14, 2017 11:50 AM, "teor"  wrote:
>>> 
>>> On 15 Dec 2017, at 03:31, Fabian A. Santiago  
>>> wrote:
>>> 
>>> I'm checking my Tor relay on atlas and the dir address is listed as 'none'. 
>>> I have dirport set in
>>> my torrc file to just a number with no other flags. I can hit the HTML page 
>>> in my browser. I did
>>> just stand up my relay less than 24 hours ago.
>> 
>> Thanks for helping Tor!
>>> Anything I'm missing?
>> 
>> Did you set AccountingMax?
>> Tor disables the DirPort when it doesn't know if you will reach the limit.
>> 
>> Do you have low bandwidth or RAM?
>> 
>> Without more details, like your relay fingerprint, specs, and torrc,
>> it is a bit of a guessing game.
>> 
>> T
>>> Hi,
>>> 
>>> RelayBandwidthRate 10102 KBytes
>>> RelayBandwidthBurst 15102 KBytes
>>> 
>>> AccountingMax 150 GBytes
>> 
>> Tor will turn your DirPort back on when it's sure you won't go over
>> the limit. It's best to just let tor manage this.
>> 
>>> ram = 4gb
>>> 
>>> fingerprint = D122094E396DF8BA560843E7B983B0EA649B7DF9
>>> 
>>> ubuntu 16.04 LTS
>>> 
>>> tor installed via the official tor repo
>>> 
>>> i've also noticed it doesn't seem to be making use of ipv6 but that could 
>>> be my torrc. the file has
>>> been posted here for your review:
>>> 
>>> https://pastebin.com/F6H9ypsL
>> 
>> IPv6 needs to be manually configured in your torrc.
>> (We're working on it.)
>> 
>> Try:
>> 
>> ORPort [IPv6]:9001
>> IPv6Exit 1
>> 
>> T
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> what does 'IPv6Exit 1' tell it to do?
> 
> --
> 
> Thanks,
> 
> Fabian S.
> 
> OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

nvm, found it online. thanks. working now on ipv6. 

--

Thanks,

Fabian S.

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

Re: [tor-relays] Dir address none

[Fabian A. Santiago]

December 14, 2017 1:10 PM, "teor"  wrote:

>> On 15 Dec 2017, at 05:01, Fabian A. Santiago  
>> wrote:
>> 
>> December 14, 2017 11:50 AM, "teor"  wrote:
>> 
>> On 15 Dec 2017, at 03:31, Fabian A. Santiago  
>> wrote:
>> 
>> I'm checking my Tor relay on atlas and the dir address is listed as 'none'. 
>> I have dirport set in
>> my torrc file to just a number with no other flags. I can hit the HTML page 
>> in my browser. I did
>> just stand up my relay less than 24 hours ago.
>>> Thanks for helping Tor!
>> 
>> Anything I'm missing?
>>> Did you set AccountingMax?
>>> Tor disables the DirPort when it doesn't know if you will reach the limit.
>>> 
>>> Do you have low bandwidth or RAM?
>>> 
>>> Without more details, like your relay fingerprint, specs, and torrc,
>>> it is a bit of a guessing game.
>>> 
>>> T
>> 
>> Hi,
>> 
>> RelayBandwidthRate 10102 KBytes
>> RelayBandwidthBurst 15102 KBytes
>> 
>> AccountingMax 150 GBytes
> 
> Tor will turn your DirPort back on when it's sure you won't go over
> the limit. It's best to just let tor manage this.
> 
>> ram = 4gb
>> 
>> fingerprint = D122094E396DF8BA560843E7B983B0EA649B7DF9
>> 
>> ubuntu 16.04 LTS
>> 
>> tor installed via the official tor repo
>> 
>> i've also noticed it doesn't seem to be making use of ipv6 but that could be 
>> my torrc. the file has
>> been posted here for your review:
>> 
>> https://pastebin.com/F6H9ypsL
> 
> IPv6 needs to be manually configured in your torrc.
> (We're working on it.)
> 
> Try:
> 
> ORPort [IPv6]:9001
> IPv6Exit 1
> 
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

what does 'IPv6Exit 1' tell it to do?

--

Thanks,

Fabian S.

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

Re: [tor-relays] Alleged Family Members / Stable flag "issues"

[tor]

> The same with the Alleged Family Member, I had an relay / exit with a reduced 
> exit policy ($F8333E028E952840C1B93DAEE20880F75B90A68A) but that has been 
> gone 
> for quite some weeks (months) as it was taken down by the hoster. Now all 
> info I can find is that when the relay doesn't announce this anymore one can 
> expect it to be gone after some days/weeks.


F8333E028E952840C1B93DAEE20880F75B90A68A does seem to be gone from Atlas when 
searching for it directly. Have you removed the reference to it from the 
MyFamily line of the relay that's still up?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Removed x bytes by killing y circuits

[Felix]

Hi

> Do you see a log line that relates to which type of "Scheduler" you are using
> such as:
> 
> [notice] Scheduler type KIST has been enabled.

It's Freebsd:
[notice] Scheduler type KISTLite has been enabled.


> It is seriously a huge amount of circuit and very little data. For isntance
> 13344 bytes that is 0.013 MB for 594572 circuits is just weird.
> 
> Is there a chance you are being DoS in some capacity? That is bunch of
> circuits being opened constantly but with no traffic? You would see that with
> many inbound connections and if they come from non relays also.

This happens every some weeks to different relays. Inbound connections
are on a normal level. I believe some client(?) tries a DoS type of
circuit exhaustion, at least it seems. The number of circuits goes up to
over a million. If it goes with much memory consumption the
remove/killing comes along.


> Another possibility is that Tor is failing to cleanup inactive circuits but
> with more information, we can eliminate options more easily.

What can I do ? The relay is still on with 3.4 GB. But circuits are
pretty relaxed since five hours.

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

Re: [tor-relays] Removed x bytes by killing y circuits

[David Goulet]

On 14 Dec (20:41:56), Felix wrote:
> Hi everybody
> 
> Can someone explain the following tor log entry:
> 
> Removed 528 bytes by killing 385780 circuits; 0 circuits remain alive.
> (it's the nicest one, see below)
> 
> 
> Memory stays at 3 - 4 GB before and after. Only tor restart gets rid of
> the memory.
> 
> We love to remove 528 bytes.
> 
> Tor log becomes 370 MB within 18 hours.
> 
> 
> Tor 0.3.2.6-alpha (git-87012d076ef58bb9)
> MaxMemInQueues 2 GB

Do you see a log line that relates to which type of "Scheduler" you are using
such as:

[notice] Scheduler type KIST has been enabled.

It is seriously a huge amount of circuit and very little data. For isntance
13344 bytes that is 0.013 MB for 594572 circuits is just weird.

Is there a chance you are being DoS in some capacity? That is bunch of
circuits being opened constantly but with no traffic? You would see that with
many inbound connections and if they come from non relays also.

Another possibility is that Tor is failing to cleanup inactive circuits but
with more information, we can eliminate options more easily.

Thanks!
David

> 
> 
> We receive some of these:
> 
> Dec 14 00:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 3:00
> hours, with 508694 circuits open.
> Dec 14 00:30:08.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 00:30:09.000 [notice] Removed 13344 bytes by killing 594572
> circuits; 0 circuits remain alive. Also killed 3 non-linked directory
> connections.
> 
> Dec 14 01:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 4:00
> hours, with 67530 circuits open.
> Dec 14 02:07:16.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 02:07:17.000 [notice] Removed 206448 bytes by killing 484352
> circuits; 0 circuits remain alive. Also killed 2 non-linked directory
> connections.
> 
> Dec 14 03:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 6:00
> hours, with 379182 circuits open.
> Dec 14 03:13:17.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 03:13:17.000 [notice] Removed 528 bytes by killing 385780
> circuits; 0 circuits remain alive. Also killed 0 non-linked directory
> connections.
> 
> Dec 14 05:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 8:00
> hours, with 303958 circuits open.
> Dec 14 05:15:17.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 05:15:18.000 [notice] Removed 528 bytes by killing 317854
> circuits; 0 circuits remain alive. Also killed 0 non-linked directory
> connections.
> 
> and lots of:
> 
> Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 221 circuits;
> 0 circuits remain alive. Also killed 0 non-linked directory connections.
> Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 297 circuits;
> 0 circuits remain alive. Also killed 0 non-linked directory connections.
> Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 395 circuits;
> 0 circuits remain alive. Also killed 0 non-linked directory connections.
> Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 468 circuits;
> 0 circuits remain alive. Also killed 0 non-linked directory connections.
> Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 509 circuits;
> 0 circuits remain alive. Also killed 0 non-linked directory connections.
> 
> 
> -- 
> Thanks and cheers, Felix
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-- 
PQgdff5S0a51LrwYmq/+PRgWSz+jjvkgZTCn3plzEkY=


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] Removed x bytes by killing y circuits

[Felix]

Hi everybody

Can someone explain the following tor log entry:


Removed 528 bytes by killing 385780 circuits; 0 circuits remain alive.
(it's the nicest one, see below)


Memory stays at 3 - 4 GB before and after. Only tor restart gets rid of
the memory.

We love to remove 528 bytes.

Tor log becomes 370 MB within 18 hours.


Tor 0.3.2.6-alpha (git-87012d076ef58bb9)
MaxMemInQueues 2 GB


We receive some of these:

Dec 14 00:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 3:00
hours, with 508694 circuits open.
Dec 14 00:30:08.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 00:30:09.000 [notice] Removed 13344 bytes by killing 594572
circuits; 0 circuits remain alive. Also killed 3 non-linked directory
connections.

Dec 14 01:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 4:00
hours, with 67530 circuits open.
Dec 14 02:07:16.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 02:07:17.000 [notice] Removed 206448 bytes by killing 484352
circuits; 0 circuits remain alive. Also killed 2 non-linked directory
connections.

Dec 14 03:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 6:00
hours, with 379182 circuits open.
Dec 14 03:13:17.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 03:13:17.000 [notice] Removed 528 bytes by killing 385780
circuits; 0 circuits remain alive. Also killed 0 non-linked directory
connections.

Dec 14 05:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 8:00
hours, with 303958 circuits open.
Dec 14 05:15:17.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 05:15:18.000 [notice] Removed 528 bytes by killing 317854
circuits; 0 circuits remain alive. Also killed 0 non-linked directory
connections.

and lots of:

Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 221 circuits;
0 circuits remain alive. Also killed 0 non-linked directory connections.
Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 297 circuits;
0 circuits remain alive. Also killed 0 non-linked directory connections.
Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 395 circuits;
0 circuits remain alive. Also killed 0 non-linked directory connections.
Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 468 circuits;
0 circuits remain alive. Also killed 0 non-linked directory connections.
Dec 14 00:30:22.000 [notice] We're low on memory.  Killing circuits with
over-long queues. (This behavior is controlled by MaxMemInQueues.)
Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 509 circuits;
0 circuits remain alive. Also killed 0 non-linked directory connections.


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

[tor-relays] Alleged Family Members / Stable flag "issues"

[Stijn Jonker]

Hi all,

For a little short of a year I'm running Relay SJC01 
(328E54981C6DDD7D89B89E418724A4A7881E3192), there was some unnoticed outage of 
the relay which caused a couple days of downtime. This was at the end of Nov, 
oddly enough I don't seem to get back the "Stable" flag.

In searches I found some conflicting answers, it's either 7 days of uptime, a 
median of seven days of the entire uptime and/or the advice to check 
https://consensus-health.torproject.org/consensus-health-2017-12-14-18-00.html#328E54981C6DDD7D89B89E418724A4A7881E3192

What I don't understand is the differences in the output of the concensus:
- The concensus nodes that don't have IPv6 (assumed from "KnownFlags" from top 
of page. (longclaw, dizum, moria1 and faravahar) list my relay with 
Stable/Guard.
- The concensus nodes that do assign the "ReachableIPv6" flag, don't have my 
relay listed with those flags.

To test the IPv6 function, I took an VM outside of my network and ran Tor with 
"UseBridges" only allowing via iptables IPv6 out to my relay as entry node, and 
it the relay is/was functioning on IPv6.

Now happy to wait an other week/month etc for the stable flag. It doesn't add 
value to me, but I'm more curious why the flag doesn't return.

The same with the Alleged Family Member, I had an relay / exit with a reduced 
exit policy ($F8333E028E952840C1B93DAEE20880F75B90A68A) but that has been gone 
for quite some weeks (months) as it was taken down by the hoster. Now all info 
I can find is that when the relay doesn't announce this anymore one can expect 
it to be gone after some days/weeks. But in this case it's not going away.

If there are actions on my side happy to take them, but I can't find the "right 
thing" to do here.

Thanks!


-- 
Yours Sincerely / Met Vriendelijke groet,
Stijn Jonker



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] Dir address none

[teor]

> On 15 Dec 2017, at 05:01, Fabian A. Santiago  
> wrote:
> 
> December 14, 2017 11:50 AM, "teor"  wrote:
> 
>>> On 15 Dec 2017, at 03:31, Fabian A. Santiago  
>>> wrote:
>>> 
>>> I'm checking my Tor relay on atlas and the dir address is listed as 'none'. 
>>> I have dirport set in
>>> my torrc file to just a number with no other flags. I can hit the HTML page 
>>> in my browser. I did
>>> just stand up my relay less than 24 hours ago.
>> 
>> Thanks for helping Tor!
>> 
>>> Anything I'm missing?
>> 
>> Did you set AccountingMax?
>> Tor disables the DirPort when it doesn't know if you will reach the limit.
>> 
>> Do you have low bandwidth or RAM?
>> 
>> Without more details, like your relay fingerprint, specs, and torrc,
>> it is a bit of a guessing game.
>> 
>> T
> 
> Hi,
> 
> RelayBandwidthRate 10102 KBytes 
> RelayBandwidthBurst 15102 KBytes
> 
> AccountingMax 150 GBytes

Tor will turn your DirPort back on when it's sure you won't go over
the limit. It's best to just let tor manage this.

> ram = 4gb
> 
> fingerprint = D122094E396DF8BA560843E7B983B0EA649B7DF9
> 
> ubuntu 16.04 LTS
> 
> tor installed via the official tor repo
> 
> i've also noticed it doesn't seem to be making use of ipv6 but that could be 
> my torrc. the file has been posted here for your review:
> 
> https://pastebin.com/F6H9ypsL

IPv6 needs to be manually configured in your torrc.
(We're working on it.)

Try:

ORPort [IPv6]:9001
IPv6Exit 1

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

Re: [tor-relays] Dir address none

[Fabian A. Santiago]

December 14, 2017 11:50 AM, "teor"  wrote:

>> On 15 Dec 2017, at 03:31, Fabian A. Santiago  
>> wrote:
>> 
>> I'm checking my Tor relay on atlas and the dir address is listed as 'none'. 
>> I have dirport set in
>> my torrc file to just a number with no other flags. I can hit the HTML page 
>> in my browser. I did
>> just stand up my relay less than 24 hours ago.
> 
> Thanks for helping Tor!
> 
>> Anything I'm missing?
> 
> Did you set AccountingMax?
> Tor disables the DirPort when it doesn't know if you will reach the limit.
> 
> Do you have low bandwidth or RAM?
> 
> Without more details, like your relay fingerprint, specs, and torrc,
> it is a bit of a guessing game.
> 
> T
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Hi,

RelayBandwidthRate 10102 KBytes 
RelayBandwidthBurst 15102 KBytes

AccountingMax 150 GBytes

ram = 4gb

fingerprint = D122094E396DF8BA560843E7B983B0EA649B7DF9

ubuntu 16.04 LTS

tor installed via the official tor repo

i've also noticed it doesn't seem to be making use of ipv6 but that could be my 
torrc. the file has been posted here for your review:

https://pastebin.com/F6H9ypsL

thanks.

--

Thanks,

Fabian S.

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

Re: [tor-relays] Fwd: someone is livestreaming a bad exit

[Johan Fleury]

Le jeudi 14 décembre 2017 à 13:16 +1100, teor a écrit :
> Forwarded to bad-relays
> 

Wikipedia has a page [1] that basically ask people not to create hoax to prove a
point (most of the time the point is that Wikipedia is not reliable).

Is there any page like this on the Tor project's wiki?

This guy does not seem to understand why his “experimentation” was dangerous.

[1] https://en.wikipedia.org/wiki/Wikipedia:Do_not_create_hoaxes

-- 
Johan Fleury
PGP Key ID : 0x5D404386805E56E6

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] #34C3 Tor Assembly

[x9p]

On Thu, December 14, 2017 6:26 am, Artikel 5 e.V. wrote:
> Hello,
> I forgot to mention this, but please share this information, this way we
> #Tor enthusiast can use this chance to meet and share information.
>
> utzer
>

Would love to go, share and meet people. but finishing things first. Miss
Germany a lot. Hope on the next one.

cheers.

--
x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE
1524 E7EE

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

Re: [tor-relays] #34C3 Tor Assembly

[Artikel 5 e.V.]

Hello,
I forgot to mention this, but please share this information, this way we
#Tor enthusiast can use this chance to meet and share information.

utzer

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