Re: [tor-relays] Relay uptime versus outdated Tor version

[K. Besig]

LolI'll frame it and then upgrade both...thanks for the kick in the
rear..

On Aug 16, 2017 2:34 PM, "Petrusko"  wrote:

> And why not taking a screenshot + print it to remember :p
>
>
>
> tor :
> > You'll lose your uptime, but... don't be ridiculous. It's better to
> > keep Tor up-to-date. That uptime undoubtedly means you're running an
> > outdated kernel too, which is not ideal. I think it would be wise to
> > take the hit and update both.
>
> --
> Petrusko
> C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5
>
>
>
> ___
> 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] Relay Operators Meetup at BornHack

[Alexander Færøy]

Hello relay operators,

DrWhax and I will host a small relay operators meetup at the upcoming
BornHack festival in Denmark.

If you happen to be around and want to join please keep yourself updated
with the event schedule on the BornHack website or track the meetup
event directly at
https://www.bornhack.dk/bornhack-2017/program/tor-relay-operators-meetup/
:-)

All the best,
Alex.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Does fallback directory traffic go over the ORPort?

[tor]

In another thread, Roger said:

> Note that most clients use the ORPort for fetching directory stuff, and
> that's heading towards "all clients" as people upgrade and stop using weird
> configurations.

I'm curious about the 100+ fallback directory mirrors. Does fallback directory 
traffic go over the ORPort too? Is it safe to disable the DirPort on fallback 
relays?___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What causes circuits to collapse?

[x9p_tor]

> Hi,
>
> I have configured a Tor bridge to go through a particular Tor guard
> relay (that I also own), as an experiment.
> Upon initialization I am getting this warning:
>
> "Your guard [fingerprint] is failing an extremely large amount of
> circuits. This could indicate a route manipulation attack, extreme
> network overload, or a bug. Success counts are 52/275. Use counts are
> 67/67. 268 circuits completed, 0 were unusable, 217 collapsed and 1
> timed out. For reference, your timeout cutoff is 60 seconds".
>

As the message says, maybe be a network issue between the bridge and the
relay. To exclude this possibility a second daemon pinging and log the
packets between the 2 machines could be a good thing to exclude this. ISPs
can fail lot of times in a day.

> Both relays are running Tor 3.0.10.
>
> I have never received this warning before. How do I interpret the
> numbers above, and debug the issue?
>

Does your relay also host a HS? Found here this could also be an issue:

https://tor.stackexchange.com/questions/9265/im-building-lots-of-circuits-what-could-cause-this

> The guard is far from saturating its network bandwidth. It has 98%
> idle CPU and plenty of free memory. I am not running any attacks
> against it. It does use a tuned-up sysctl.conf but I have never had
> any problems with it. "tcpdump icmp" does not show anything
> interesting. There are no warnings in the guard's log.
>
> 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] Relay uptime versus outdated Tor version

[Petrusko]

And why not taking a screenshot + print it to remember :p



tor :
> You'll lose your uptime, but... don't be ridiculous. It's better to
> keep Tor up-to-date. That uptime undoubtedly means you're running an
> outdated kernel too, which is not ideal. I think it would be wise to
> take the hit and update both.

-- 
Petrusko
C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5




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] Relay uptime versus outdated Tor version

[tor]

You'll lose your uptime, but... don't be ridiculous. It's better to keep Tor 
up-to-date. That uptime undoubtedly means you're running an outdated kernel 
too, which is not ideal. I think it would be wise to take the hit and update 
both.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bwauth in testing

[Toralf Förster]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/16/2017 10:06 PM, Tom Ritter wrote:
> That is because gabelmoo's bwauth dropped off. Now there are only 3
> bwauths in the system, and your relay was not measured by one of them
> (faravahar). With only 2 measurements, you get kicked down to the
> default I believe.
> 
> The good news is that my bwauth measured you at 75600, which is a bit
> below the other two measurements, but in line with them. So once
> maatuska starts voting on this data you'll be popped back up.
> 
> Please bear with us while we get this sorted out! =)

Ah, thx for the info.
I was a little bit unsettled /c I changed my iptables ruleset around the same 
time where BW dropped down.

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

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWZSoXhccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTiJMAP4ub+dfutsNsy2AAh7+VXMV02w1
93Ip29pWoSSVY7W6RgEAjH13/sYtfGdNojN/k5nE5w8DAsB1FKM8DMP6d7BBpgw=
=f5qG
-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] bwauth in testing

[Tom Ritter]

That is because gabelmoo's bwauth dropped off. Now there are only 3
bwauths in the system, and your relay was not measured by one of them
(faravahar). With only 2 measurements, you get kicked down to the
default I believe.

The good news is that my bwauth measured you at 75600, which is a bit
below the other two measurements, but in line with them. So once
maatuska starts voting on this data you'll be popped back up.

Please bear with us while we get this sorted out! =)

-tom

On 16 August 2017 at 14:36, Toralf Förster  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 08/14/2017 11:22 PM, Tom Ritter wrote:
>> But I wanted to announce it here, both to give an update, and let the
>> community take a look at its output and see if anything looks fishy.
>
> Since few hours the BW is dropped or my exit relay from about 90,000 to 20 
> accordingly to [1].
> A quick check showed that few more relays are affected too.
>
>
> [1] 
> https://consensus-health.torproject.org/consensus-health-2017-08-16-16-00.html#1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA
>
> - --
> Toralf
> PGP C4EACDDE 0076E94E
> -BEGIN PGP SIGNATURE-
>
> iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWZSeohccdG9yYWxmLmZv
> ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTjVtAP9jnze4wzptyJvHJmEZEoXBFdik
> 4alXQ+93w7ITJJLmVgD/dtitebS/ASbD2e41065+z9iZALCd19qkqotRldo04J8=
> =V6zw
> -END PGP SIGNATURE-
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Relay uptime versus outdated Tor version

[K. Besig]

One of my relays has over 416 days of uptime, which I'm very proud of,
however it's running an outdated version of Tor. I should probably already
know the answer, but it seems to me I would have to stop the tor service to
update the relay. Would I in fact lose my uptime or would it be seamless?
Thanks for the response
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bwauth in testing

[Toralf Förster]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/14/2017 11:22 PM, Tom Ritter wrote:
> But I wanted to announce it here, both to give an update, and let the
> community take a look at its output and see if anything looks fishy.

Since few hours the BW is dropped or my exit relay from about 90,000 to 20 
accordingly to [1].
A quick check showed that few more relays are affected too.


[1] 
https://consensus-health.torproject.org/consensus-health-2017-08-16-16-00.html#1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA

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

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWZSeohccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTjVtAP9jnze4wzptyJvHJmEZEoXBFdik
4alXQ+93w7ITJJLmVgD/dtitebS/ASbD2e41065+z9iZALCd19qkqotRldo04J8=
=V6zw
-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] blocking >1 connections per ip address onto Tor DirPort

[Toralf Förster]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/16/2017 12:22 AM, Roger Dingledine wrote:
> On Tue, Aug 15, 2017 at 11:52:31PM +0200, Toralf Förster wrote:
>> Does a particular Tor server/client will open more than 1
>> connection at a time from to the DirPort ?
> 
> I think we definitely want to support that in the protocol.
> 
> I'm not sure whether it happens right now, but it might.
> 
> But preventing it from happening is likely bad.
> 
> Note that most clients use the ORPort for fetching directory
> stuff, and that's heading towards "all clients" as people upgrade
> and stop using weird configurations. So the DirPort is mainly used
> on authorities (by relays that fetch dir stuff or upload relay
> descriptors), and by auxiliary tools like stem and the various
> metrics project scripts.
> 
> If you're worried about denial of service issues on the DirPort,
> maybe the simple answer is to turn off the DirPort? I think the
> only real impact might have something to do with whether old
> clients believe that you're a usable guard.
> 

understood - removed those iptables rules


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

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWZR6CxccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTgNjAP0QUqGlvZdmppzthH85VXkS43xO
iQRyNlODzRe5Jf9TpgD+JX+/bCuuOH/qh+Jdd9GrDBJZ9uvjtQX3OKF9C+u9oKo=
=9bQM
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Unable to compile Tor

[Alan]

Up until now i've relied on updating Tor using yum update but the version
on the repos is currently 0.2.9.10 . Arm reports this as unrecommended, so
compiling from source looks to be the only option.

I pulled down 0.3.0.10, untarred and ran ./configure && make
I get these errors--

In file included from src/common/tortls.c:52:0:
src/common/tortls.h:140:15: error: conflicting types for
‘SSL_SESSION_get_master_key’
 STATIC size_t SSL_SESSION_get_master_key(SSL_SESSION *s, uint8_t *out,
   ^
In file included from src/common/tortls.c:40:0:
/usr/local/include/openssl/ssl.h:1725:15: note: previous declaration of
‘SSL_SESSION_get_master_key’ was here
 __owur size_t SSL_SESSION_get_master_key(const SSL_SESSION *ssl,
   ^
src/common/tortls.c: In function ‘find_cipher_by_id’:
src/common/tortls.c:1331:21: warning: unused variable ‘c’ [-Wunused-variable]
   const SSL_CIPHER *c;
 ^
src/common/tortls.c: In function ‘tor_tls_client_is_using_v2_ciphers’:
src/common/tortls.c:1508:20: error: dereferencing pointer to incomplete type
   ciphers = session->ciphers;
^
src/common/tortls.c: At top level:
src/common/tortls.c:2402:1: error: conflicting types for
‘SSL_get_client_random’
 SSL_get_client_random(SSL *s, uint8_t *out, size_t len)
 ^
In file included from src/common/tortls.c:40:0:
/usr/local/include/openssl/ssl.h:1721:15: note: previous declaration of
‘SSL_get_client_random’ was here
 __owur size_t SSL_get_client_random(const SSL *ssl, unsigned char *out,
   ^
In file included from src/common/tortls.c:27:0:
src/common/tortls.c: In function ‘SSL_get_client_random’:
src/common/tortls.c:2407:15: error: dereferencing pointer to incomplete type
   tor_assert(s->s3);
   ^
src/common/compat.h:196:51: note: in definition of macro ‘PREDICT_UNLIKELY’
 #define PREDICT_UNLIKELY(exp) __builtin_expect(!!(exp), 0)
   ^
src/common/tortls.c:2407:3: note: in expansion of macro ‘tor_assert’
   tor_assert(s->s3);
   ^
src/common/tortls.c:2408:16: error: dereferencing pointer to incomplete type
   memcpy(out, s->s3->client_random, len);
^
src/common/tortls.c: At top level:
src/common/tortls.c:2415:1: error: conflicting types for
‘SSL_get_server_random’
 SSL_get_server_random(SSL *s, uint8_t *out, size_t len)
 ^
In file included from src/common/tortls.c:40:0:
/usr/local/include/openssl/ssl.h:1723:15: note: previous declaration of
‘SSL_get_server_random’ was here
 __owur size_t SSL_get_server_random(const SSL *ssl, unsigned char *out,
   ^
In file included from src/common/tortls.c:27:0:
src/common/tortls.c: In function ‘SSL_get_server_random’:
src/common/tortls.c:2420:15: error: dereferencing pointer to incomplete type
   tor_assert(s->s3);
   ^
src/common/compat.h:196:51: note: in definition of macro ‘PREDICT_UNLIKELY’
 #define PREDICT_UNLIKELY(exp) __builtin_expect(!!(exp), 0)
   ^
src/common/tortls.c:2420:3: note: in expansion of macro ‘tor_assert’
   tor_assert(s->s3);
   ^
src/common/tortls.c:2421:16: error: dereferencing pointer to incomplete type
   memcpy(out, s->s3->server_random, len);
^
src/common/tortls.c: In function ‘SSL_SESSION_get_master_key’:
src/common/tortls.c:2432:13: error: dereferencing pointer to incomplete type
 return s->master_key_length;
 ^
In file included from src/common/tortls.c:27:0:
src/common/tortls.c:2433:30: error: dereferencing pointer to incomplete type
   tor_assert(len == (size_t)s->master_key_length);
  ^
src/common/compat.h:196:51: note: in definition of macro ‘PREDICT_UNLIKELY’
 #define PREDICT_UNLIKELY(exp) __builtin_expect(!!(exp), 0)
   ^
src/common/tortls.c:2433:3: note: in expansion of macro ‘tor_assert’
   tor_assert(len == (size_t)s->master_key_length);
   ^
src/common/tortls.c:2435:16: error: dereferencing pointer to incomplete type
   memcpy(out, s->master_key, len);
^
make[1]: *** [src/common/tortls.o] Error 1
make[1]: Leaving directory `/root/tor-0.3.0.10'
make: *** [all] Error 2


I'm running on Centos 7

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

Re: [tor-relays] keepyourprivcay: Introducing a new 100 mbit/s relay

[John Ricketts]

Thank you!

On Aug 16, 2017, at 10:22, Keepyourprivacy 
> wrote:

Another 100 mbit/s relay has been added, located in sweden. MyFamily entry set 
in torrc.

https://atlas.torproject.org/#details/B92CADBD1E9A2F72E64D7DE5A1BF5B2B30DA7B87
___
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] keepyourprivcay: Introducing a new 100 mbit/s relay

[Keepyourprivacy]

Another 100 mbit/s relay has been added, located in sweden. MyFamily entry set 
in torrc.

https://atlas.torproject.org/#details/B92CADBD1E9A2F72E64D7DE5A1BF5B2B30DA7B87___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays