Re: [tor-relays] confusing error from "tor --verify-config"

2016-12-20 Thread Petrusko
If you try :
sudo -u debian-tor tor --verify-config



Le 21/12/2016 à 01:59, Patrice a écrit :
> Hi,
>> I would suggest running  tor --verify-config as debian-tor user instead of
>> root
> After I run the following command I`ve got no output.
> Is this correct then? I expected a few lines somehow.
>
> su -c "/etc/init.d/tor --verify-config" debian-tor
>
>
>> I would suggest not running tor as root . :)
>> As root you can do:
>> su debian-tor "tor --verify-config"
>>
>
> I am not running tor as root. Tor runs as "debian-tor".
> I installed it from the repositories and changed nothing in the
> permissions.
>
>
> Cheers,
> Patrice
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-- 
Petrusko
EBE23AE5




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] confusing error from "tor --verify-config"

2016-12-20 Thread Patrice

Hi,


I would suggest running  tor --verify-config as debian-tor user instead of
root

After I run the following command I`ve got no output.
Is this correct then? I expected a few lines somehow.

su -c "/etc/init.d/tor --verify-config" debian-tor



I would suggest not running tor as root .:)
As root you can do:
su debian-tor "tor --verify-config"



I am not running tor as root. Tor runs as "debian-tor".
I installed it from the repositories and changed nothing in the permissions.


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


Re: [tor-relays] Updating our IP Address

2016-12-20 Thread diffusae
Hello,

yes you're right. It looks like I accidentally routed all traffic
through tor due to a faulty firewall rule. It was a bit confusing,
because of the quickly updates with the right IP. It took me a while to
understand the background.

Thanks a lot for your help

Regards,

On 20.12.2016 19:35, anondroid wrote:
> I'm familiar with DynDNS and the client. The client tries to detect your
> external IP address in order to keep your dynamic DNS record pointed at
> your current IP. It looks to me like you're running it on a machine
> that's routing through Tor. So it picks up the IP address of the Exit
> you're routed through, and incorrectly tries to update your dynamic DNS
> with this Exit IP instead of your actual IP.
> 
> If this theory is correct, there's not really a "bug" here. It's working
> as expected. You can't run the DynDNS client if you're routing traffic
> through Tor.
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Updating our IP Address

2016-12-20 Thread diffusae
Hello,

sorry, it also was a bit confusing for me as I've seen the logs. Yes,
you are right. I am running a tor node and a ddclient on the same
machine. Tor client and relay is running in a jail. So, it might be
error, because of a faulty firewall rule. It looks like, I've routed all
traffic though the tor client. Therefore it could be a "false" dynsdns
update, but I've don't understand why it was changing so quickly with
right IP.

So, for now I guess, it was my fault.

Regards,
Reiner

On 20.12.2016 18:49, tor-relay.d...@o.banes.ch wrote:
> Hello,
> 
> I'm part of the abuse team of the mentioned Tor Exit.
> Also I follow this mailing list.
> 
> I read you post several times but I'm not sure what you where doing.
> It looks to me like you running a tor node and have also a dyndns update
> process running.
> 
> Is this correct ? Please provide some more information about you use
> case/configuration
> 
> best regards
> 
> Dirk
> 
> 
> On 20.12.2016 15:25, diffusae wrote:
>> Hi!
>>
>> Yesterday I encountered a strange IP address update via DynDNS:
>>
>> Dec 19 23:00:32.000 [notice] Your IP address seems to have changed to
>> 176.10.104.240 (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
>> Dec 19 23:00:32.000 [notice] Our IP Address has changed from xx.xx.xx.xx
>> to 176.10.104.240; rebuilding descriptor (source: METHOD=RESOLVED
>> HOSTNAME=my.dyndns.cc).
>> Dec 19 23:00:36.000 [notice] Self-testing indicates your ORPort is
>> reachable from the outside. Excellent.
>> Dec 19 23:04:32.000 [notice] Your IP address seems to have changed to
>> xx.xx.xx.xx (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
>> Dec 19 23:04:32.000 [notice] Our IP Address has changed from
>> 176.10.104.240 to xx.xx.xx.xx ; rebuilding descriptor (source:
>> METHOD=RESOLVED HOSTNAME=my.dyndns.cc).
>> Dec 19 23:04:34.000 [notice] Self-testing indicates your ORPort is
>> reachable from the outside. Excellent.
>> Dec 19 23:08:32.000 [notice] Your IP address seems to have changed to
>> 176.10.104.240 (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
>> Dec 19 23:08:32.000 [notice] Our IP Address has changed from xx.xx.xx.xx
>> to 176.10.104.240; rebuilding descriptor (source: METHOD=RESOLVED
>> HOSTNAME=my.dyndns.cc).
>> Dec 19 23:08:34.000 [notice] Self-testing indicates your ORPort is
>> reachable from the outside. Excellent.
>> Dec 19 23:13:32.000 [notice] Your IP address seems to have changed to
>> xx.xx.xx.xx (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
>> Dec 19 23:13:32.000 [notice] Our IP Address has changed from
>> 176.10.104.240 to xx.xx.xx.xx; rebuilding descriptor (source:
>> METHOD=RESOLVED HOSTNAME=my.dyndns.cc).
>> Dec 19 23:13:36.000 [notice] Self-testing indicates your ORPort is
>> reachable from the outside. Excellent.
>> Dec 19 23:22:38.000 [notice] Self-testing indicates your DirPort is
>> reachable from the outside. Excellent. Publishing server descriptor
>>
>> The DynDNS client updates the IP every five minutes. It looks like
>> somebody has tried to changed / update the IP manually or via spoofed
>> update (DNS) entry. I also recognized the change at the WebGUI of the
>> DynDNS Provider. The changed IP address is an exit node
>> (0111BA9B604669E636FFD5B503F382A4B7AD6E80) in Switzerland.
>>
>> I don't think, that this is a bug in Tor 0.2.9.7-rc. Are there any
>> possible attacks to Tor relays, if they are using a faked IP address?
>> Normally this shouldn't work. Even if the traffic is redirected to an
>> exit node, but I am not sure.
>>
>> Well, it should be safer to use autodetection of the IP though Tor.
>>
>> Regards,
>> ___
>> 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] confusing error from "tor --verify-config"

2016-12-20 Thread Ivan Markin
Pascal Terjan:
> I would suggest running  tor --verify-config as debian-tor user
> instead of root

I would suggest not running tor as root . :)
As root you can do:
su debian-tor "tor --verify-config"

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


[tor-relays] confusing error from "tor --verify-config"

2016-12-20 Thread Patrice

Hi folks,

my relay is running fine [zeiberschnitzel] and it got no errors. I can`t 
see anything in the logs either.

But when I do the command

#tor --verify-config

I got these outputs:

Dec 20 18:20:27.946 [notice] Tor v0.2.8.11 (git-9fc59eddc17a726a) 
running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Dec 20 18:20:27.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 20 18:20:27.947 [notice] Read configuration file "/etc/tor/torrc".
Dec 20 18:20:27.956 [warn] /var/lib/tor is not owned by this user (root, 
0) but by debian-tor (105). Perhaps you are running Tor as the wrong user?
Dec 20 18:20:27.957 [warn] Failed to parse/validate config: Couldn't 
access/create private data directory "/var/lib/tor"

Dec 20 18:20:27.957 [err] Reading config failed--see warnings above.


I would say it`s nothing tragical but I am curios about it.

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


[tor-relays] confusing error from "tor --verify-config"

2016-12-20 Thread Patrice

Hi folks,

my relay is running fine [zeiberschnitzel] and it got no errors. I can`t 
see anything in the logs either.

But when I do the command

#tor --verify-config

I got these outputs:

Dec 20 18:20:27.946 [notice] Tor v0.2.8.11 (git-9fc59eddc17a726a) 
running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Dec 20 18:20:27.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 20 18:20:27.947 [notice] Read configuration file "/etc/tor/torrc".
Dec 20 18:20:27.956 [warn] /var/lib/tor is not owned by this user (root, 
0) but by debian-tor (105). Perhaps you are running Tor as the wrong user?
Dec 20 18:20:27.957 [warn] Failed to parse/validate config: Couldn't 
access/create private data directory "/var/lib/tor"

Dec 20 18:20:27.957 [err] Reading config failed--see warnings above.


I would say it`s nothing tragical but I am curios about it.

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


Re: [tor-relays] Updating our IP Address

2016-12-20 Thread anondroid
I'm familiar with DynDNS and the client. The client tries to detect your 
external IP address in order to keep your dynamic DNS record pointed at your 
current IP. It looks to me like you're running it on a machine that's routing 
through Tor. So it picks up the IP address of the Exit you're routed through, 
and incorrectly tries to update your dynamic DNS with this Exit IP instead of 
your actual IP.

If this theory is correct, there's not really a "bug" here. It's working as 
expected. You can't run the DynDNS client if you're routing traffic through Tor.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Report of home relay experience (cont'd)

2016-12-20 Thread Roman Mamedov
On Tue, 20 Dec 2016 19:12:54 +0100
Petrusko  wrote:

> Haaa extra packages needed to compile from source...
> I don't remember which ones ! If someone here knows ? :s
> 

Try running "apt-get build-dep tor".

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


Re: [tor-relays] Report of home relay experience (cont'd)

2016-12-20 Thread Petrusko

  
  
Haaa extra packages needed to compile from source...
I don't remember which ones ! If someone here knows ? :s

Something like :
gcc


Le 20/12/2016 à 19:08, Petrusko a
  écrit :


  
  Hey,
  
  I remember Raspberry Pi 1 + 2 are not really friendly with AES
  because of CPU limitation.
  And RPi 3 is better for this...
  
  For lazy guyz, here are Atlas links about the 2 relays :
  https://atlas.torproject.org/#details/31B8C4C4F1C78F923BD906769297B15A428C4A04
  https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400CC6
  
  For new relays, it's always good to wait for consensus growing, so
  it will be more used in the future... may be some weeks needed.
  I see current Raspbian Tor package :     Tor 0.2.5.12 on Linux
  May be it can be better to compile a newer Tor package, by using
  source Tor repo ?
  
  Add Tor repo in the RPi to have the source available (here is
  stable source) :
  in the /etc/apt/source.list, you can add, then apt-get update :
  
  #TOR stable - pour building from source
deb-src http://deb.torproject.org/torproject.org
jessie main
  
  
  I've made a script a moment ago for a RPi, located in my home
  folder :
  nano tor-compil-source.sh
  
  #!/bin/bash
# init
function pause(){
   read -p "$*"
}
mkdir ~/debian-packages
cd ~/debian-packages
rm * -R
apt-get source tor
cd tor-*
debuild -rfakeroot -uc -us
cd ..
pause 'Press [Enter] key to continue... Install TOR'
dpkg -i tor_*.deb tor-*.deb
exit 0
  
  As you can see, the script is waiting for you to push a key before
  installing the new package... Why not, can be cool to watch log
  during set up,
  on another console, or "tmux" window :
  tail -f /var/log/tor/log
  
  (or notice file... depend on what you set up in torrc file)
  
  You can use your current fingerprint, relay name... only the
  packge will be updated.
  (if I'm wrong, don't hesitate to burn me here !)
  
  I hope it can help ;)
  
  
  
  Le 20/12/2016 à 11:10, Rana a écrit :
  
  








  Of the two relays that I run from two
different residential premises for some time now, the first,
nicknamed ZG0 (has absolutely stable dynamic IP and Stable
flag for many days now) is clinically dead despite the
measured BW of 100 kbytes/sec.
   
  The second, nicknamed GG2 (static IP,
Stable, Fast, HSdir) is not
dead but is relaying only about 0.5 gbytes
per day. That’s an average rate of just 4% of its
never-changing measured BW of 153 Kbytes/sec (which is equal
to 100% of its bandwidth limit in torrc). It currently has
900 connections and made over 16,000 circuit handshakes in
the last 6 hours, all of them successful.
   
  The two relays run on identical Pies with
the same configuration except the bandwidth limit (which is
higher on ZG0 than on GG2) and negligible CPU and memory
utilization.
   
  Comments?

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



  




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] Report of home relay experience (cont'd)

2016-12-20 Thread Petrusko

  
  
Hey,

I remember Raspberry Pi 1 + 2 are not really friendly with AES
because of CPU limitation.
And RPi 3 is better for this...

For lazy guyz, here are Atlas links about the 2 relays :
https://atlas.torproject.org/#details/31B8C4C4F1C78F923BD906769297B15A428C4A04
https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400CC6

For new relays, it's always good to wait for consensus growing, so
it will be more used in the future... may be some weeks needed.
I see current Raspbian Tor package :     Tor 0.2.5.12 on Linux
May be it can be better to compile a newer Tor package, by using
source Tor repo ?

Add Tor repo in the RPi to have the source available (here is stable
source) :
in the /etc/apt/source.list, you can add, then apt-get update :

#TOR stable - pour building from source
  deb-src http://deb.torproject.org/torproject.org jessie main


I've made a script a moment ago for a RPi, located in my home folder
:
nano tor-compil-source.sh

#!/bin/bash
  # init
  function pause(){
     read -p "$*"
  }
  mkdir ~/debian-packages
  cd ~/debian-packages
  rm * -R
  apt-get source tor
  cd tor-*
  debuild -rfakeroot -uc -us
  cd ..
  pause 'Press [Enter] key to continue... Install TOR'
  dpkg -i tor_*.deb tor-*.deb
  exit 0

As you can see, the script is waiting for you to push a key before
installing the new package... Why not, can be cool to watch log
during set up,
on another console, or "tmux" window :
tail -f /var/log/tor/log

(or notice file... depend on what you set up in torrc file)

You can use your current fingerprint, relay name... only the packge
will be updated.
(if I'm wrong, don't hesitate to burn me here !)

I hope it can help ;)



Le 20/12/2016 à 11:10, Rana a écrit :


  
  
  
  
  
  
  
  
Of the two relays that I run from two
  different residential premises for some time now, the first,
  nicknamed ZG0 (has absolutely stable dynamic IP and Stable
  flag for many days now) is clinically dead despite the
  measured BW of 100 kbytes/sec.
 
The second, nicknamed GG2 (static IP,
  Stable, Fast, HSdir) is not dead
  but is relaying only about 0.5 gbytes
  per day. That’s an average rate of just 4% of its
  never-changing measured BW of 153 Kbytes/sec (which is equal
  to 100% of its bandwidth limit in torrc). It currently has 900
  connections and made over 16,000 circuit handshakes in the
  last 6 hours, all of them successful.
 
The two relays run on identical Pies with
  the same configuration except the bandwidth limit (which is
  higher on ZG0 than on GG2) and negligible CPU and memory
  utilization.
 
Comments?
  

  




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] Tor Relay on ARM server Marvell Armada 370/XP

2016-12-20 Thread niftybunny
Whoops, wrong one :/

https://atlas.torproject.org/#details/24E91955D969AEA1D80413C64FE106FAE7FD2EA9

> On 20 Dec 2016, at 18:28, Roman Mamedov  wrote:
> 
> On Tue, 20 Dec 2016 18:19:06 +0100
> niftybunny  wrote:
> 
>> Yes, running 12 exits there.
>> 
>> https://atlas.torproject.org/#details/28F4F392F8F19E3FBDE09616D9DB8143A1E2DDD3
>>  
>> 
>> 
>> the atom cpu suxx, install 2 instance, so you get around 100-120 mbit. 
> 
> That's OVH, and Scaleway is Online.net.
> 
> -- 
> With respect,
> Roman
> ___
> 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 Relay on ARM server Marvell Armada 370/XP

2016-12-20 Thread Roman Mamedov
On Tue, 20 Dec 2016 18:19:06 +0100
niftybunny  wrote:

> Yes, running 12 exits there.
> 
> https://atlas.torproject.org/#details/28F4F392F8F19E3FBDE09616D9DB8143A1E2DDD3
>  
> 
> 
> the atom cpu suxx, install 2 instance, so you get around 100-120 mbit. 

That's OVH, and Scaleway is Online.net.

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


Re: [tor-relays] Tor Relay on ARM server Marvell Armada 370/XP

2016-12-20 Thread niftybunny
in my experience long time ago … arm suxx. I would switch to the 2 core atom, 
they suck too but no so bad as the arm there.

Markus

> On 20 Dec 2016, at 14:24, Fabio Pietrosanti (naif) - lists 
>  wrote:
> 
> Hello,
> 
> i'm experimenting Tor setup on very cheap servers from scaleaway.com
> that run a quad-core ARM Marvell Armada 370/XP servers but have
> unlimited bandwidth.
> 
> Those are Soc platform:
> http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf
> 
> I saw no information on torproject mailing list about those SOC.
> 
> I'm trying to push the limits and i saw that those have a crypto
> acceleration support:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
> 
> However with kernel 4.5.7 it does not really work and loading of
> marvel-cesa gives out error:
> [6.841862] marvell-cesa: probe of d009.crypto failed with error -22
> 
> :(
> 
> 
> I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4
> -mtune=xscale and the Tor Relay is at
> https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B7E0
> .
> 
> Does someone have experienced optimizing and tuning Tor specifically on
> ARM processors to understand how far those could be optimized?
> 
> -naif
> ___
> 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 Relay on ARM server Marvell Armada 370/XP

2016-12-20 Thread niftybunny
Yes, running 12 exits there.

https://atlas.torproject.org/#details/28F4F392F8F19E3FBDE09616D9DB8143A1E2DDD3 


the atom cpu suxx, install 2 instance, so you get around 100-120 mbit. 

Markus


> On 20 Dec 2016, at 14:40, Volker Mink  wrote:
> 
> Is it OK with their TOS to run a TOR Relay7Exit?
> If so, i really consider getting a VPS there!
>  
> Gesendet: Dienstag, 20. Dezember 2016 um 14:24 Uhr
> Von: "Fabio Pietrosanti (naif) - lists" 
> An: tor-relays@lists.torproject.org
> Betreff: [tor-relays] Tor Relay on ARM server Marvell Armada 370/XP
> Hello,
> 
> i'm experimenting Tor setup on very cheap servers from scaleaway.com
> that run a quad-core ARM Marvell Armada 370/XP servers but have
> unlimited bandwidth.
> 
> Those are Soc platform:
> http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf 
> 
> 
> I saw no information on torproject mailing list about those SOC.
> 
> I'm trying to push the limits and i saw that those have a crypto
> acceleration support:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
>  
> 
> 
> However with kernel 4.5.7 it does not really work and loading of
> marvel-cesa gives out error:
> [6.841862] marvell-cesa: probe of d009.crypto failed with error -22
> 
> :(
> 
> 
> I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4
> -mtune=xscale and the Tor Relay is at
> https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B7E0
>  
> 
> .
> 
> Does someone have experienced optimizing and tuning Tor specifically on
> ARM processors to understand how far those could be optimized?
> 
> -naif
> ___
> 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] Updating our IP Address

2016-12-20 Thread diffusae
Hi!

Yesterday I encountered a strange IP address update via DynDNS:

Dec 19 23:00:32.000 [notice] Your IP address seems to have changed to
176.10.104.240 (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
Dec 19 23:00:32.000 [notice] Our IP Address has changed from xx.xx.xx.xx
to 176.10.104.240; rebuilding descriptor (source: METHOD=RESOLVED
HOSTNAME=my.dyndns.cc).
Dec 19 23:00:36.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent.
Dec 19 23:04:32.000 [notice] Your IP address seems to have changed to
xx.xx.xx.xx (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
Dec 19 23:04:32.000 [notice] Our IP Address has changed from
176.10.104.240 to xx.xx.xx.xx ; rebuilding descriptor (source:
METHOD=RESOLVED HOSTNAME=my.dyndns.cc).
Dec 19 23:04:34.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent.
Dec 19 23:08:32.000 [notice] Your IP address seems to have changed to
176.10.104.240 (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
Dec 19 23:08:32.000 [notice] Our IP Address has changed from xx.xx.xx.xx
to 176.10.104.240; rebuilding descriptor (source: METHOD=RESOLVED
HOSTNAME=my.dyndns.cc).
Dec 19 23:08:34.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent.
Dec 19 23:13:32.000 [notice] Your IP address seems to have changed to
xx.xx.xx.xx (METHOD=RESOLVED HOSTNAME=my.dyndns.cc). Updating.
Dec 19 23:13:32.000 [notice] Our IP Address has changed from
176.10.104.240 to xx.xx.xx.xx; rebuilding descriptor (source:
METHOD=RESOLVED HOSTNAME=my.dyndns.cc).
Dec 19 23:13:36.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent.
Dec 19 23:22:38.000 [notice] Self-testing indicates your DirPort is
reachable from the outside. Excellent. Publishing server descriptor

The DynDNS client updates the IP every five minutes. It looks like
somebody has tried to changed / update the IP manually or via spoofed
update (DNS) entry. I also recognized the change at the WebGUI of the
DynDNS Provider. The changed IP address is an exit node
(0111BA9B604669E636FFD5B503F382A4B7AD6E80) in Switzerland.

I don't think, that this is a bug in Tor 0.2.9.7-rc. Are there any
possible attacks to Tor relays, if they are using a faked IP address?
Normally this shouldn't work. Even if the traffic is redirected to an
exit node, but I am not sure.

Well, it should be safer to use autodetection of the IP though Tor.

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


Re: [tor-relays] Tor Relay on ARM server Marvell Armada 370/XP

2016-12-20 Thread Roman Mamedov
On Tue, 20 Dec 2016 14:24:47 +0100
"Fabio Pietrosanti (naif) - lists"  wrote:

> Hello,
> 
> i'm experimenting Tor setup on very cheap servers from scaleaway.com
> that run a quad-core ARM Marvell Armada 370/XP servers but have
> unlimited bandwidth.
> 
> Those are Soc platform:
> http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf
> 
> I saw no information on torproject mailing list about those SOC.
> 
> I'm trying to push the limits and i saw that those have a crypto
> acceleration support:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
> 
> However with kernel 4.5.7 it does not really work and loading of
> marvel-cesa gives out error:
> [6.841862] marvell-cesa: probe of d009.crypto failed with error -22
> 
> :(
> 
> 
> I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4
> -mtune=xscale and the Tor Relay is at
> https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B7E0
> .
> 
> Does someone have experienced optimizing and tuning Tor specifically on
> ARM processors to understand how far those could be optimized?

Do you run two Tor instances per machine? On platforms like these (with two
or more cores, but each core being rather weak), you pretty much have to, if
you want good resource utilization. Pin the 1st instance to cores 0,1, the
second one to 2,3 using schedtool for better cache locality, and if you're
already using schedtool, might as well mark the Tor processes as SCHED_BATCH.

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


Re: [tor-relays] Tor Relay on ARM server Marvell Armada 370/XP

2016-12-20 Thread Volker Mink

Is it OK with their TOS to run a TOR Relay7Exit?

If so, i really consider getting a VPS there!

 

Gesendet: Dienstag, 20. Dezember 2016 um 14:24 Uhr
Von: "Fabio Pietrosanti (naif) - lists" 
An: tor-relays@lists.torproject.org
Betreff: [tor-relays] Tor Relay on ARM server Marvell Armada 370/XP

Hello,

i'm experimenting Tor setup on very cheap servers from scaleaway.com
that run a quad-core ARM Marvell Armada 370/XP servers but have
unlimited bandwidth.

Those are Soc platform:
http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf

I saw no information on torproject mailing list about those SOC.

I'm trying to push the limits and i saw that those have a crypto
acceleration support:
https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell-cesa.txt

However with kernel 4.5.7 it does not really work and loading of
marvel-cesa gives out error:
[6.841862] marvell-cesa: probe of d009.crypto failed with error -22

:(


I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4
-mtune=xscale and the Tor Relay is at
https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B7E0
.

Does someone have experienced optimizing and tuning Tor specifically on
ARM processors to understand how far those could be optimized?

-naif
___
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] Tor Relay on ARM server Marvell Armada 370/XP

2016-12-20 Thread Fabio Pietrosanti (naif) - lists
Hello,

i'm experimenting Tor setup on very cheap servers from scaleaway.com
that run a quad-core ARM Marvell Armada 370/XP servers but have
unlimited bandwidth.

Those are Soc platform:
http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf

I saw no information on torproject mailing list about those SOC.

I'm trying to push the limits and i saw that those have a crypto
acceleration support:
https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell-cesa.txt

However with kernel 4.5.7 it does not really work and loading of
marvel-cesa gives out error:
[6.841862] marvell-cesa: probe of d009.crypto failed with error -22

:(


I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4
-mtune=xscale and the Tor Relay is at
https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B7E0
.

Does someone have experienced optimizing and tuning Tor specifically on
ARM processors to understand how far those could be optimized?

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


Re: [tor-relays] snaptor relays: MyFamily update required

2016-12-20 Thread nusenu


Sec INT:
> Hi
> 
> Will do today

better but not there yet:

+---+---+
| nickname  | MyFamilyCount |
+---+---+
| SnapExitBULG  |9. |
| SnapExitFIN   |   10. |
| SnapExitMOLD  |   10. |
| SnapExitUS|   10. |
| SnapTorBANG   |   10. |
| SnapTorCAN|   10. |
| SnapTorFr |9. |
| SnapTorRelay1 |8. |
| SnapTorSNPR   |   10. |
| SnapTorSTRAS  |   10. |
+---+---+
10 rows

https://atlas.torproject.org/#details/302B1C6E59277803ADF8F1FAAB4FF63D22F0E368


>> +-+-+---+--+
>> | first_seen  | IP  | MyFamilyCount | exit |
>> +-+-+---+--+
>> | 2016-11-12 00:00:00 | 213.32.66.192   |9. |0 |
>> | 2016-11-26 23:00:00 | 193.70.90.199   |9. |0 |
>> | 2016-11-26 23:00:00 | 128.199.108.14  |9. |0 |
>> | 2016-11-27 00:00:00 | 139.59.46.211   |9. |0 |
>> | 2016-11-28 11:00:00 | 94.156.77.41|8. |1 |
>> | 2016-11-28 14:00:00 | 142.4.206.241   |9. |1 |
>> | 2016-11-29 00:00:00 | 185.103.110.210 |9. |1 |
>> | 2016-12-03 23:00:00 | 144.217.90.138  |9. |0 |
>> | 2016-12-16 15:00:00 | 176.123.26.27   |8. |1 |
>> | 2016-12-16 23:00:00 | 193.70.22.86|  NULL |0 |
>> +-+-+---+--+
>>
>>
>> https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt
>>
>> regards,
>> nusenu
>> --
>> https://github.com/nusenu/ansible-relayor




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] zencurity.dk relays: MyFamily update required

2016-12-20 Thread nusenu


Henrik Lund Kramshøj:
> So sorry, I have updated config with family

thanks for fixing it.



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


[tor-relays] Report of home relay experience (cont'd)

2016-12-20 Thread Rana
Of the two relays that I run from two different residential premises for
some time now, the first, nicknamed ZG0 (has absolutely stable dynamic IP
and Stable flag for many days now) is clinically dead despite the measured
BW of 100 kbytes/sec.
 
The second, nicknamed GG2 (static IP, Stable, Fast, HSdir) is not dead but
is relaying only about 0.5 gbytes per day. That's an average rate of just 4%
of its never-changing measured BW of 153 Kbytes/sec (which is equal to 100%
of its bandwidth limit in torrc). It currently has 900 connections and made
over 16,000 circuit handshakes in the last 6 hours, all of them successful.
 
The two relays run on identical Pies with the same configuration except the
bandwidth limit (which is higher on ZG0 than on GG2) and negligible CPU and
memory utilization.
 
Comments?
 
Rana
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays