arm: NameError: global name 'bin' is not defined
Dear Damian,
with revision 24158 I am getting the following error when I want to run arm.
# ./arm
Traceback (most recent call last):
File "./src/starter.py", line 378, in
controller.init(conn)
File "/arm/src/util/torTools.py", line 292, in init
self._exitPolicyChecker = self.getExitPolicy()
File "/arm/src/util/torTools.py", line 766, in getExitPolicy
result = ExitPolicy("reject private", result)
File "/arm/src/util/torTools.py", line 1541, in __init__
lastHop = ExitPolicy(prefix + addr + suffix, lastHop)
File "/arm/src/util/torTools.py", line 1558, in __init__
self.ipAddressBin += ("%8s" % bin(int(octet))[2:]).replace(" ", "0")
NameError: global name 'bin' is not defined
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
Re: Tor 0.2.1.26-1~~lenny+1: segfault with libcryto.so.0.9.8
Am Mittwoch, den 17.11.2010, 12:04 -0500 schrieb Roger Dingledine: > On Wed, Nov 17, 2010 at 11:45:32AM -0500, Nick Mathewson wrote: > > > I noticed that Tor had crashed on my system. I am using Debian Lenny > > > with Tor 0.2.1.26-1~~lenny+1. The only thing I could find out about this > > > crash is the following line running `dmesg`. > > > > > Without more information, there's not much info to go on there to > > diagnose the problem. Generally, to debug a segfault, we need a stack > > trace. To get one of those, make sure you're running Tor with > > coredumps enabled, and use gdb to get a trace if Tor crashes again. > > On Debian, you want to apt-get install tor-dbg, so you get the symbols > for the Tor binary. I did so now. sudo aptitude install tor-dbg (Aptitude is the recommended package manager by Debian since Lenny.) > You might even have a core file already sitting in your datadirectory, > which I think is /var/lib/tor/ Yes, I have. Two of them actually. They are 60 MB and 117 MB big. Is it safe to make them publicly available somewhere? Are they of use for someone since no debug symbols were installed when the core dumps were created? Thanks, Paul signature.asc Description: This is a digitally signed message part
Tor 0.2.1.26-1~~lenny+1: segfault with libcryto.so.0.9.8
Dear Tor folks, I noticed that Tor had crashed on my system. I am using Debian Lenny with Tor 0.2.1.26-1~~lenny+1. The only thing I could find out about this crash is the following line running `dmesg`. $ dmesg […] [Several of these Treason uncloaked messages as you can see some seconds before the crash. I obfuscated the IP addresses.] [3301769.746795] TCP: Treason uncloaked! Peer xxx.xxx.xxx.xxx:60659/42859 shrinks window 1343914705:1343916145. Repaired. [3413085.371871] TCP: Treason uncloaked! Peer yyy.yyy.yyy.yyy:19595/45969 shrinks window 2416591117:2416591857. Repaired. [3604257.970658] tor[22506]: segfault at 21d4fc5 ip 7f1e78ba4ea6 sp 41188920 error 4 in libcrypto.so.0.9.8[7f1e78b21000+172000] [3604257.970707] type=1701 audit(1289305397.030:2): auid=4294967295 uid=102 gid=104 ses=4294967295 pid=22506 comm="tor" sig=11 So it could also be libcrypto is the culprit. `libssl0.9.8` is running with `0.9.8g-15+lenny8` as version. Is that a known problem? What other information can I provide to solve that? Unfortunately I have not found out how to reproduce it yet. Thanks, Paul signature.asc Description: This is a digitally signed message part
Re: torwatch - a little script to visualize traffic of a tor node
Dear startx, Am Dienstag, den 19.10.2010, 09:45 +0100 schrieb startx: > yesterday evening i got a bit tired of staring at all the numbers in > my /var/lib/tor/state file, so i opened a beer and wrote this little > script i called torwatch (for now). > > you can get it from here: http://projects.plentyfact.org/wiki/torwatch > > and see it in "action" here: http://savide.plentyfact.net:8080 > > maybe somebody else finds that useful, i might do some more work on > it next week. Really nice and impressing. There is also arm [1] which does not export to HTML though. […] I attach a patch for the README file. Those typos have to be corrected in the Wiki too. It would be great, if you could put torwatch under version control. Thanks, Paul [1] http://www.atagar.com/arm/ 8<------>8 From: Paul Menzel Date: Tue, 19 Oct 2010 12:22:12 +0200 Subject: [PATCH] README: Two typos. Signed-off-by: Paul Menzel --- README |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index ccd60e5..7d256b6 100644 --- a/README +++ b/README @@ -1,11 +1,11 @@ ABOUT torwatch is a script to visualize the traffic of a tor node. it is written in lua -and uses the GD graphics library to draw the graphs. toewatch 0.1 was written +and uses the GD graphics library to draw the graphs. torwatch 0.1 was written over a pint of lager in october 2010, so please do not blame the author if you find it incomplete, buggy or useless. -i could not come up with a better name yet, if yoy have a brilliant idea, let me know. +i could not come up with a better name yet, if you have a brilliant idea, let me know. torwatch is released unter the GNU Public Licence v3. -- 1.7.2.3 signature.asc Description: This is a digitally signed message part
Re: Full bandwidth is not used.
Am Donnerstag, den 14.10.2010, 08:32 +0200 schrieb Timo Schoeler: > thus Paul Menzel spake: > > Am Mittwoch, den 13.10.2010, 10:31 -0400 schrieb Thomas S. Benjamin: > > > >> Is your relay running on a virtual machine (V-colo)? > > > > Yes, the relay is running on a virtual machine. > > > >> If so, check your user beancounters, they may show you which resources > >> are being exhausted. > > > > Xen is used. So I cannot check those entries, but according to the FAQ, > > this should not be a problem [1]. I also checked with `top` on Dom0 and > > DomU and the ressources are barley used. > > Xen doesn't use beancounters, they're used in OpenVZ, e.g. > > You should be able to find out lack of resources of your Dom0 and DomU > by using the 'usualy' utilities and `xentop', e.g. I did not know about `xentop`. Thank you! But it also show that not all resources are used. > >> Also, do you find any messages in your log? > > > > The log just contains the normal `[NOTICE]` messages. > > Maybe the problem resides outside of what he can see, maybe there's > traffic shaping/accounting with limiting after a certain useage taking > place? There is, but that limit has not been reached yet. Does anyone knowledgeable know, how I could trick the Tor rebalancing algorithms? Thanks, Paul > > [1] http://archives.seul.org/or/talk/Mar-2010/msg00155.html > > [2] > > https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#CanIrunaTorrelayfrommyvirtualserveraccount signature.asc Description: This is a digitally signed message part
Re: Full bandwidth is not used.
Dear Thomas, Am Mittwoch, den 13.10.2010, 10:31 -0400 schrieb Thomas S. Benjamin: > Is your relay running on a virtual machine (V-colo)? Yes, the relay is running on a virtual machine. > If so, check your user beancounters, they may show you which resources > are being exhausted. Xen is used. So I cannot check those entries, but according to the FAQ, this should not be a problem [1]. I also checked with `top` on Dom0 and DomU and the ressources are barley used. > Also, do you find any messages in your log? The log just contains the normal `[NOTICE]` messages. Thanks, Paul [1] http://archives.seul.org/or/talk/Mar-2010/msg00155.html [2] https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#CanIrunaTorrelayfrommyvirtualserveraccount signature.asc Description: This is a digitally signed message part
Full bandwidth is not used.
Dear Tor folks, I am still seeing the same problem [1]. In April it used the whole limit of 1 TB and hibernated after the limit was reached, but afterward it only came back to around 100 GB per month. Fast IT is not limiting the bandwidth in any way. I tested that. CPU and memory are not utilized completely either. Here is the output from arm. arm - anonymisierungsdienst (Linux...) Tor 0.2.1.26 (recommended) anonymisierungsdien - 0.0.0.0:9090, Dir Port: 80, Control Port (open): 9051 cpu: 0.5%mem: 92 MB (13.0%) pid: 1186uptime: 14-15:11:11 fingerprint: B3EC1BF5D7F7D724BA634D91BE5D22D2D7A70160 flags: Exit, Fast, Guard, Named, Running, Stable, Valid I only have AccountingMax 500 GB set in `/etc/tor/torrc`. So it must be a Tor problem. As you can see from the graphs the bandwidth usage goes up and down quite often. What might be the reason? Besides it is still below the available 100 Mbit/s. So does rebalancing still have problems as indicated in Andrew’s answer [3]? Thanks, Paul [1] http://archives.seul.org/or/talk/Mar-2010/msg00010.html [2] http://www.atagar.com/arm/ [3] http://archives.seul.org/or/talk/Apr-2010/msg00140.html signature.asc Description: This is a digitally signed message part
Consider traffic before setting AccountingStart in the middle of an accounting period.
Dear Tor folks,
my server plan only includes 1 TB of traffic. Since traffic increased
quite a bit during the last few days [1] I have to limit the volume to
not go bankrupt.
In `man torrc` [2] I found AccountingMax and AccountingStart. My
accounting starts let us say at April 2nd and I just set
Accounting{Max,Start} and reloaded Tor on April 12th.
Will Tor consider traffic before in its accounting? That information is
quite crucial to me.
Thanks,
Paul
[1]
http://trunk.torstatus.kgprog.com/router_detail.php?FP=b3ec1bf5d7f7d724ba634d91be5d22d2d7a70160
[2] http://www.torproject.org/tor-manual.html.en
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [solved] Full bandwidth is not used.
Am Donnerstag, den 25.03.2010, 13:57 +0100 schrieb Paul Menzel: > Am Freitag, den 19.03.2010, 22:08 -0400 schrieb and...@torproject.org: > > On Fri, Mar 19, 2010 at 05:43:37PM +0100, paulepan...@users.sourceforge.net > > wrote 1.0K bytes in 37 lines about: > > : > I setup a tor relay by just setting > > : > orport, dirport, and nickname and letting it run. It's 0.2.2.9-alpha. > > : > We'll see what happens. > > : > > : Do you have any results yet? > > > > Yes, the ISP traffic shaped me into 300KB/s. But Tor dutifully fills > > that up. It's a non-exit relay named "hugs", fingerprint is > > E5CE54C14A41D829B6EBA77724EA27D88337E211. > > So to rule the last thing out before to blame it on Tor, namely that the > ISP is limiting the bandwidth, can somebody point me to a way on how to > check the bandwidth on different ports. Ok, it looks like they do not limit the bandwidth. Since April 13th traffic increased quite a lot [1]. So it looks like it just took longer to get my exit node propagated to the network. Thanks, Paul [1] http://trunk.torstatus.kgprog.com/router_detail.php?FP=b3ec1bf5d7f7d724ba634d91be5d22d2d7a70160 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Freitag, den 19.03.2010, 22:08 -0400 schrieb and...@torproject.org: > On Fri, Mar 19, 2010 at 05:43:37PM +0100, paulepan...@users.sourceforge.net > wrote 1.0K bytes in 37 lines about: > : > I setup a tor relay by just setting > : > orport, dirport, and nickname and letting it run. It's 0.2.2.9-alpha. > : > We'll see what happens. > : > : Do you have any results yet? > > Yes, the ISP traffic shaped me into 300KB/s. But Tor dutifully fills > that up. It's a non-exit relay named "hugs", fingerprint is > E5CE54C14A41D829B6EBA77724EA27D88337E211. So to rule the last thing out before to blame it on Tor, namely that the ISP is limiting the bandwidth, can somebody point me to a way on how to check the bandwidth on different ports. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Dienstag, den 09.03.2010, 07:40 -0500 schrieb and...@torproject.org: […] > I setup a tor relay by just setting > orport, dirport, and nickname and letting it run. It's 0.2.2.9-alpha. > We'll see what happens. Do you have any results yet? Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Dienstag, den 16.03.2010, 18:51 +0100 schrieb Gitano: > Paul Menzel wrote: > > >>> It is a virtual machine ... > > > Is it safe to say, that it is a client problem that they do not use my > > server? > > 1. On vservers there are many resource limits. Please check: 'cat > /proc/user_beancounters'. Xen is used on the server, so I do not have that file. I checked for CPU and RAM usage and enough is available. > 2. Have you read 'http://www.webtropia.com/home/faq.html?article=366'? I > don't believe that you have reached the traffic limit, but this could be > another reason. I knew about it. But I have not come close to that limit yet and traffic is well below that limit. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Freitag, den 12.03.2010, 11:40 +0100 schrieb Paul Menzel: > Am Dienstag, den 09.03.2010, 14:01 +0100 schrieb Paul Menzel: > > Am Dienstag, den 09.03.2010, 07:40 -0500 schrieb and...@torproject.org: > > > On Mon, Mar 08, 2010 at 10:21:29AM +0100, > > > paulepan...@users.sourceforge.net wrote 1.6K bytes in 52 lines about: > > > : I now increased the RAM too and restarted the server to no avail. It is > > > : still below 100 KB/s. > > > > > > What is the network configuration? > > > > $ more /etc/tor/torrc > > SocksPort 0 # what port to open for local application > > connections > > ControlPort 9051 > > ORPort 443 > > ORListenAddress 0.0.0.0:9090 > > Address 62.141.42.186 > > ContactInfo 1024D/6C0E1D58 Paul Menzel > > DirPort 80 # what port to advertise for directory connections > > DirListenAddress 0.0.0.0:9091 > > I implemented the changes suggested by arma on IRC (due to Exit and > Guard flag [1]) to configure my server as non-exit relay, so I added the > following line. > > ExitPolicy reject *:* > > > It is a virtual machine and connections to port 80 and 443 are forwarded > > by an IPtables entry in the nat table with DNAT to the virtual host. On > > the virtual host using IPtables ports 80 and 443 are forwarded to 9090 > > and 9091. > > > > Sebastian on IRC helped me to gather more data. In `cached-descriptors` > > I have the following. > > > > bandwidth 5242880 10485760 155910 > > > > There are more entries for my IP address when I restarted and upgraded > > Tor. > > > > In `cached-consensus` (from 12:28 UTC) there is > > > > r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA > > vyRDgH2XTP6Tn1MPiJkWE0Yk9e8 2010-03-08 18:05:07 62.141.42.186 443 80 > > s Exit Fast HSDir Running Stable V2Dir Valid > > v Tor 0.2.1.23 > > w Bandwidth=61 > > p reject > > 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999 > > > > and Bandwidth even decreased by 1 (from 62) compared to the value before > > the update (11:14 UTC). > > Unfortunately changing the server to a non-exit relay on 2010-03-10 > 09:28:25 UTC did not change anything. Although looking at my logs and > the data on [2] I would say it differs a bit. According to my logs I > would say, that traffic even decreased. > > $ grep -A 6 "62.141.42.186" cached-descriptors | grep -E > 'published|bandwidth' > published 2010-03-07 17:51:12 > bandwidth 5242880 10485760 55006 > published 2010-03-08 00:05:02 > bandwidth 5242880 10485760 155910 > $ grep -A 6 "62.141.42.186" cached-descriptors | grep bandwidth > bandwidth 5242880 10485760 214272 > bandwidth 5242880 10485760 141962 > $ LANG=C date && grep -A 6 "62.141.42.186" cached-descriptors | grep > bandwidth > Thu Mar 11 10:30:02 UTC 2010 > bandwidth 5242880 10485760 181555 > $ LANG=C date && grep -A 6 "62.141.42.186" cached-descriptors | grep > -E 'published|bandwidth' > Fri Mar 12 09:46:43 UTC 2010 > published 2010-03-10 09:28:24 > bandwidth 5242880 10485760 181555 > published 2010-03-11 03:28:50 > bandwidth 5242880 10485760 178964 > published 2010-03-11 21:29:37 > bandwidth 5242880 10485760 143546 > > The value displayed on [2] seems to be more up to date. > > Here are some compiled values from `cached-consensus`. > > $ grep -A4 62.141.42 cached-consensus # adapted the output. > r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA > QvLgYWR3HuX0DKMSPBCwzjIVpCk 2010-03-09 12:05:55 62.141.42.186 443 80 > s Exit Fast HSDir Running Stable V2Dir Valid > w Bandwidth=63 > $ ls -al (adapted) > 384600 9. Mär 21:27 cached-consensus > w Bandwidth=102 > 362245 9. Mär 23:15 cached-consensus > w Bandwidth=90 > 342063 10. Mär 07:32 cached-consensus > w Bandwidth=88 > # (configure as non-exit relay) > 356455 10. Mär 11:14 cached-consensus > w Bandwidth=86 > 385656 10. Mär 21:16 cached-consensus > w Bandwidth=81 > w Bandwidth=64 > 390325 11. Mär 20:03 cached-consensus > w Bandwidth=58 > Thu Mar 11 20:21:07 UTC 2010 > w Bandwidth=58 > anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA > BfwbPy3Xd3P2smQn
Re: Full bandwidth is not used.
Am Freitag, den 12.03.2010, 19:31 -0600 schrieb Scott Bennett:
[…]
> Well, as I've pointed out in the past, the values in cached-consensus
> do *not* accurately reflect either the traffic load that your relay has
> carried or the traffic capacity of your relay. They are bogus a priori and
> should be ignored in attempting to ascertain your relay's actual loads.
> The sad thing is that recent versions of tor clients now use the consensus
> values for designing routes for circuits they will build, so the bogus
> values produce load distortions throughout the tor network. However, that
> fact has no bearing upon the numbers you're looking for.
> If you want to know the loads that your relay has carried, you should
> look at the byte counts for reads and writes in the extrainfo documents or,
> alternatively, the state file. (The difficulty with using the state file
> is that it gets updated everytime construction of a new circuit succeeds,
> so the values for the most recent time periods change frequently and at
> rather unpredictable intervals. If you always ignore the most recent time
> period for read and for writes, then the state file becomes more usable
> for this purpose.) If, OTOH, you want to know the peak "10-second burst"
> rate, then the value to trust is the one in your relay's descriptors that
> appear in the cached-descriptors{,.new} files.
Thank you for your response. I kept that in mind and compared it to the
values in `/var/lib/tor/state` and they are around the same and maybe
even lower. I also use tools like `nload` to verify the network load.
You can also see bandwidth graphs at [2].
I am a little confused why you are responding nitpicking at the values I
give although I think it was confirmed in the whole thread that the full
bandwidth is not used at all.
Thanks,
Paul
[2]
http://trunk.torstatus.kgprog.com/router_detail.php?FP=b3ec1bf5d7f7d724ba634d91be5d22d2d7a70160
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Dienstag, den 09.03.2010, 14:01 +0100 schrieb Paul Menzel: > Am Dienstag, den 09.03.2010, 07:40 -0500 schrieb and...@torproject.org: > > On Mon, Mar 08, 2010 at 10:21:29AM +0100, paulepan...@users.sourceforge.net > > wrote 1.6K bytes in 52 lines about: > > : I now increased the RAM too and restarted the server to no avail. It is > > : still below 100 KB/s. > > > > What is the network configuration? > > $ more /etc/tor/torrc > SocksPort 0 # what port to open for local application > connections > ControlPort 9051 > ORPort 443 > ORListenAddress 0.0.0.0:9090 > Address 62.141.42.186 > ContactInfo 1024D/6C0E1D58 Paul Menzel > DirPort 80 # what port to advertise for directory connections > DirListenAddress 0.0.0.0:9091 I implemented the changes suggested by arma on IRC (due to Exit and Guard flag [1]) to configure my server as non-exit relay, so I added the following line. ExitPolicy reject *:* > It is a virtual machine and connections to port 80 and 443 are forwarded > by an IPtables entry in the nat table with DNAT to the virtual host. On > the virtual host using IPtables ports 80 and 443 are forwarded to 9090 > and 9091. > > Sebastian on IRC helped me to gather more data. In `cached-descriptors` > I have the following. > > bandwidth 5242880 10485760 155910 > > There are more entries for my IP address when I restarted and upgraded > Tor. > > In `cached-consensus` (from 12:28 UTC) there is > > r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA > vyRDgH2XTP6Tn1MPiJkWE0Yk9e8 2010-03-08 18:05:07 62.141.42.186 443 80 > s Exit Fast HSDir Running Stable V2Dir Valid > v Tor 0.2.1.23 > w Bandwidth=61 > p reject > 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999 > > and Bandwidth even decreased by 1 (from 62) compared to the value before > the update (11:14 UTC). Unfortunately changing the server to a non-exit relay on 2010-03-10 09:28:25 UTC did not change anything. Although looking at my logs and the data on [2] I would say it differs a bit. According to my logs I would say, that traffic even decreased. $ grep -A 6 "62.141.42.186" cached-descriptors | grep -E 'published|bandwidth' published 2010-03-07 17:51:12 bandwidth 5242880 10485760 55006 published 2010-03-08 00:05:02 bandwidth 5242880 10485760 155910 $ grep -A 6 "62.141.42.186" cached-descriptors | grep bandwidth bandwidth 5242880 10485760 214272 bandwidth 5242880 10485760 141962 $ LANG=C date && grep -A 6 "62.141.42.186" cached-descriptors | grep bandwidth Thu Mar 11 10:30:02 UTC 2010 bandwidth 5242880 10485760 181555 $ LANG=C date && grep -A 6 "62.141.42.186" cached-descriptors | grep -E 'published|bandwidth' Fri Mar 12 09:46:43 UTC 2010 published 2010-03-10 09:28:24 bandwidth 5242880 10485760 181555 published 2010-03-11 03:28:50 bandwidth 5242880 10485760 178964 published 2010-03-11 21:29:37 bandwidth 5242880 10485760 143546 The value displayed on [2] seems to be more up to date. Here are some compiled values from `cached-consensus`. $ grep -A4 62.141.42 cached-consensus # adapted the output. r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA QvLgYWR3HuX0DKMSPBCwzjIVpCk 2010-03-09 12:05:55 62.141.42.186 443 80 s Exit Fast HSDir Running Stable V2Dir Valid w Bandwidth=63 $ ls -al (adapted) 384600 9. Mär 21:27 cached-consensus w Bandwidth=102 362245 9. Mär 23:15 cached-consensus w Bandwidth=90 342063 10. Mär 07:32 cached-consensus w Bandwidth=88 # (configure as non-exit relay) 356455 10. Mär 11:14 cached-consensus w Bandwidth=86 385656 10. Mär 21:16 cached-consensus w Bandwidth=81 w Bandwidth=64 390325 11. Mär 20:03 cached-consensus w Bandwidth=58 Thu Mar 11 20:21:07 UTC 2010 w Bandwidth=58 anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA BfwbPy3Xd3P2smQnEdl3Tqp9E9I 2010-03-11 21:29:37 62.141.42.186 443 80 w Bandwidth=52 r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA BfwbPy3Xd3P2smQnEdl3Tqp9E9I 2010-03-11 21:29:37 62.141.42.186 443 80 w Bandwidth=52 Do you have more ideas? Thanks, Paul [1] http://archives.seul.org/or/talk/Jan-2010/msg00175.html [2] http://trunk.torstatus.kgprog.com/router_detail.php?FP=b3ec1bf5d7f7d724ba634d91be5d22d2d7a70160 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Drop Tor users via bridges by over 2/3 in the beginning of March (was: Tor in China)
Am Mittwoch, den 10.03.2010, 13:27 +0100 schrieb Karsten Loesing: […] > I figured out the problem. The metrics portal had the bridge user > numbers from 2009-11-30 to 2010-01-05 imported twice. This affected all > countries, but was simply most visible for Chinese bridge users. I > removed those days from the stats and imported the descriptors again. > > The corrected graphs can be found on the graphs page: > > http://metrics.torproject.org/bridge-users-graphs.html#china So my next question is, why did the users count drop that much in the beginning of March? […] Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[RFC] Campaign »Buy/Sponsor a relay.«
Dear Tor folks, on the Tor start page [1] there is a message »Help us reach 5,000 relays in 2010!« On IRC arma discovered an offer by the British ISP Coldbot where you can buy 1 Mb/s bandwidth for £9 per month [2]. Although it is quite pricey I find the idea very nice. »I guess for people caring about privacy but not wanting/able to set up a server themselves can now be told, you can pay 90 pounds a month [for 10 Mbps] and you will improve the connectivity of the Tor network.« [me on IRC] I suggested to contact ISPs for special rates, but arma and Sebastian pointed out that only getting relays from one ISP would hurt Tor security-wise. So different ISPs world-wide should be contacted. So what do you think about this campaign? I guess the first question is, have you ever been in this kind of situation where people asked you on how to support the Tor project. The second question is, is donating [3] working out quite well, i. e. are a lot of people donating? Would a »Sponsor a relay.« campaign hurt these fund raising efforts? Thanks, Paul [1] http://www.torproject.org/ [2] http://coldbot.com/price/tor [3] http://www.torproject.org/donate signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Dienstag, den 09.03.2010, 07:40 -0500 schrieb and...@torproject.org: > On Mon, Mar 08, 2010 at 10:21:29AM +0100, paulepan...@users.sourceforge.net > wrote 1.6K bytes in 52 lines about: > : I now increased the RAM too and restarted the server to no avail. It is > : still below 100 KB/s. > > What is the network configuration? $ more /etc/tor/torrc SocksPort 0 # what port to open for local application connections ControlPort 9051 ORPort 443 ORListenAddress 0.0.0.0:9090 Address 62.141.42.186 ContactInfo 1024D/6C0E1D58 Paul Menzel DirPort 80 # what port to advertise for directory connections DirListenAddress 0.0.0.0:9091 It is a virtual machine and connections to port 80 and 443 are forwarded by an IPtables entry in the nat table with DNAT to the virtual host. On the virtual host using IPtables ports 80 and 443 are forwarded to 9090 and 9091. Sebastian on IRC helped me to gather more data. In `cached-descriptors` I have the following. bandwidth 5242880 10485760 155910 There are more entries for my IP address when I restarted and upgraded Tor. In `cached-consensus` (from 12:28 UTC) there is r anonymisierungsdien s+wb9df31yS6Y02Rvl0i0tenAWA vyRDgH2XTP6Tn1MPiJkWE0Yk9e8 2010-03-08 18:05:07 62.141.42.186 443 80 s Exit Fast HSDir Running Stable V2Dir Valid v Tor 0.2.1.23 w Bandwidth=61 p reject 25,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999 and Bandwidth even decreased by 1 (from 62) compared to the value before the update (11:14 UTC). Very strange. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
I now increased the RAM too and restarted the server to no avail. It is still below 100 KB/s. Am Sonntag, den 07.03.2010, 12:16 +0100 schrieb Paul Menzel: > Am Freitag, den 05.03.2010, 23:54 +0100 schrieb Paul Menzel: > > Am Freitag, den 05.03.2010, 10:17 -0500 schrieb and...@torproject.org: > > > On Fri, Mar 05, 2010 at 09:32:59AM +0100, > > > paulepan...@users.sourceforge.net wrote 1.4K bytes in 39 lines about: > > > : > What did you configure for your bandwidth limits or accountingmax? > > > : > > > : I did not configure them and so the defaults are used. arm is displaying > > > : »(cap: 5 MB, burst: 10 MB)«. > > > > > > Ok, then Tor will figure out how much bandwidth it can reliably provide. > > > > On what conditions does that depend? Do you have any pointers? Where can I look up what my Tor server is announcing to the outside what bandwidth it support? […] Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Freitag, den 05.03.2010, 23:54 +0100 schrieb Paul Menzel: > Am Freitag, den 05.03.2010, 10:17 -0500 schrieb and...@torproject.org: > > On Fri, Mar 05, 2010 at 09:32:59AM +0100, paulepan...@users.sourceforge.net > > wrote 1.4K bytes in 39 lines about: > > : > What did you configure for your bandwidth limits or accountingmax? > > : > > : I did not configure them and so the defaults are used. arm is displaying > > : »(cap: 5 MB, burst: 10 MB)«. > > > > Ok, then Tor will figure out how much bandwidth it can reliably provide. > > On what conditions does that depend? > > > If you look at your (datadirectory)/state file, it will show you how > > much bandwidth tor has been providing over time. > > I guess arm is using this or something similar to display the bandwidth > usage of Tor. On average arm’s values are the same as the ones in `(datadirectory)/state`. […] Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
provided bandwitdth over time in /var/lib/tor/state (was: Full bandwidth is not used.)
Am Samstag, den 06.03.2010, 02:36 -0800 schrieb Paul Campbell:
> > From: Marcin Kowalczyk
> > Sent: Sat, March 6, 2010 7:56:39 AM
> >
> > > Looking at `DataDirectory/state` directly I cannot figure out how to
> > > interpret the values. Maybe I need tot enable bandwidth accounting.
> >
> > The values for BWHistoryReadValues and BWHistoryWriteValues are
> > sent/received bytes in 15 minutes.
> >
> > So VALUE/1024/15/60 shows you your actual kb/s throughput in one
> > direction.
>
> Maybe this poorly written perl script can help:
>
> perl -ne 'next if !/BW.*Values/; @s = split; print "$s[0]\n"; foreach
> $value (split(/,/, $s[1])) {printf "%10.1f kB/s\n", $value/15/60/1024}'
> <
> /var/lib/tor/state
Thanks a lot for this.
It shows around the same values as arm on average.
Thanks,
Paul
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Freitag, den 05.03.2010, 10:17 -0500 schrieb and...@torproject.org: > On Fri, Mar 05, 2010 at 09:32:59AM +0100, paulepan...@users.sourceforge.net > wrote 1.4K bytes in 39 lines about: > : > What did you configure for your bandwidth limits or accountingmax? > : > : I did not configure them and so the defaults are used. arm is displaying > : »(cap: 5 MB, burst: 10 MB)«. > > Ok, then Tor will figure out how much bandwidth it can reliably provide. On what conditions does that depend? > If you look at your (datadirectory)/state file, it will show you how > much bandwidth tor has been providing over time. I guess arm is using this or something similar to display the bandwidth usage of Tor. Looking at `DataDirectory/state` directly I cannot figure out how to interpret the values. Maybe I need tot enable bandwidth accounting. $ man torrc […] DataDirectory/state A set of persistent key-value mappings. These are documented in the file. These include: - The current entry guards and their status. - The current bandwidth accounting values (unused so far; see below). - When the file was last written - What version of Tor generated the state file - A short history of bandwidth usage, as produced in the router descriptors. DataDirectory/bw_accounting Used to track bandwidth accounting values (when the current period starts and ends; how much has been read and written so far this period). This file is obsolete, and the data is now stored in the ’state’ file as well. Only used when bandwidth accounting is enabled. […] Searching the WWW for »tor state bandwidth« did not help either. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Am Donnerstag, den 04.03.2010, 20:17 -0500 schrieb and...@torproject.org: > On Fri, Mar 05, 2010 at 01:03:22AM +0100, paulepan...@users.sourceforge.net > wrote 1.9K bytes in 66 lines about: > : I updated to 0.2.1.23 to no avail. It is up for 12 hours again and > : staying now at 66 KB/s. I also checked that there is still 50 MB free > : memory. > > 0.2.1.24 is current. There is no Debian package yet for it. The changelog also talks just about performances improvements on the client side. > What did you configure for your bandwidth limits or accountingmax? I did not configure them and so the defaults are used. arm is displaying »(cap: 5 MB, burst: 10 MB)«. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Dear Tor folks, Am Mittwoch, den 03.03.2010, 01:01 +0100 schrieb Paul Menzel: > Am Mittwoch, den 03.03.2010, 00:45 +0100 schrieb Hannah: > > On Wed, Mar 03, 2010 at 12:43:13AM +0100, Paul Menzel wrote: > > >Am Mittwoch, den 03.03.2010, 00:30 +0100 schrieb Hannah: > > >> On Wed, Mar 03, 2010 at 12:26:57AM +0100, Paul Menzel wrote: > > >> >[...] > > > > >> >I am out of ideas. It would be really nice, if someone could help, > > >> >because otherwise the paid traffic volume will be wasted. > > > > >> Did you check CPU usage? If your CPU is maxed out, a higher > > >> configured bandwidth allowance won't help. > > > > >the CPU usage shown by arm is 1.6 % and I verified this with `top`. > > > > >So that should not be it. > > > > Ok. Do you have a fixed IP > > Yes. > > > and has your relay run for long enough so it is deemed stable by the > > authorities? > > It ran for over three days. > > > I think those are factors that > > might detriment the usage of your relay, as well. And it may also be > > influenced by whether it's an exit or a pure relay (or bridge). > > It is an exit node. I updated to 0.2.1.23 to no avail. It is up for 12 hours again and staying now at 66 KB/s. I also checked that there is still 50 MB free memory. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[solved, bug 1269][REGRESSION] Your IP address seems to have changed to xxx.xxx.xxx.xxx. Updating.
Am Donnerstag, den 04.03.2010, 14:18 +0100 schrieb Sebastian Hahn: > On Mar 4, 2010, at 2:08 PM, Paul Menzel wrote: > > I updated from 0.2.0.35-1~lenny2 to 0.2.1.23-2~~lenny+1 and use the > > same > > configuration. But now I am seeing > > > >Your IP address seems to have changed to xxx.xxx.xxx.xxx. Updating. > > > > every 10 seconds in `/var/log/tor/log`. > > > > I have not found anything on the WWW at a first glance and the version > > jump is pretty big. > > > > Any ideas or help is appreciated! > > this is a known bug. See > https://bugs.torproject.org/flyspray/index.php?do=details&id=1269 > . > A workaround for now is to set the Address config option, if you're on > a static IP. Dear Sebastian, thanks, that worked. I guess I should subscribe to tor-relays too then. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Debian packages from deb.torproject.org or backports.org?
Dear Tor folks, in [1] option two instructs to use packages from [2]. This gives me currently version 0.2.1.23-2~~lenny+1 and is as far as I can see based on the version in Debian Sid/unstable and in `changelog.Debian.gz` release is set to `lenny-backport`. Looking at the available packages in the Debian repository [3] there is also a package for Debian Lenny in [4], which is currently version 0.2.1.22-1~bpo50+1. The maintainer is the same person. It looks like using [2] gives you more up-to-date packages. I do not know if it is hard to update the ones in [4]. I guess I am just confused because I read `backports-lenny` in the changelog of [2] and I did not find packages for 0.2.1.24 although reading [5] but which seems just to apply to RPM packages. So I will use the Tor packages from [2] if no one else says otherwise. Thanks, Paul [1] https://www.torproject.org/docs/debian.html [2] http://deb.torproject.org/ [3] http://packages.debian.org/search?keywords=tor [4] http://www.backports.org/ [5] https://blog.torproject.org/blog/new-linux-packaging-tor-and-vidalia-now-available signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[REGRESSION] Your IP address seems to have changed to xxx.xxx.xxx.xxx. Updating.
Dear Tor folks, I updated from 0.2.0.35-1~lenny2 to 0.2.1.23-2~~lenny+1 and use the same configuration. But now I am seeing Your IP address seems to have changed to xxx.xxx.xxx.xxx. Updating. every 10 seconds in `/var/log/tor/log`. I have not found anything on the WWW at a first glance and the version jump is pretty big. Any ideas or help is appreciated! Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Dear Hannah, Am Mittwoch, den 03.03.2010, 00:45 +0100 schrieb Hannah: > On Wed, Mar 03, 2010 at 12:43:13AM +0100, Paul Menzel wrote: > >Am Mittwoch, den 03.03.2010, 00:30 +0100 schrieb Hannah: > >> On Wed, Mar 03, 2010 at 12:26:57AM +0100, Paul Menzel wrote: > >> >[...] > > >> >I am out of ideas. It would be really nice, if someone could help, > >> >because otherwise the paid traffic volume will be wasted. > > >> Did you check CPU usage? If your CPU is maxed out, a higher > >> configured bandwidth allowance won't help. > > >the CPU usage shown by arm is 1.6 % and I verified this with `top`. > > >So that should not be it. > > Ok. Do you have a fixed IP Yes. > and has your relay run for long enough so it is deemed stable by the > authorities? It ran for over three days. > I think those are factors that > might detriment the usage of your relay, as well. And it may also be > influenced by whether it's an exit or a pure relay (or bridge). It is an exit node. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Dear Hannah, Am Mittwoch, den 03.03.2010, 00:30 +0100 schrieb Hannah: > On Wed, Mar 03, 2010 at 12:26:57AM +0100, Paul Menzel wrote: > >[...] > > >I am out of ideas. It would be really nice, if someone could help, > >because otherwise the paid traffic volume will be wasted. > > Did you check CPU usage? If your CPU is maxed out, a higher > configured bandwidth allowance won't help. the CPU usage shown by arm is 1.6 % and I verified this with `top`. So that should not be it. Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Dear Tor folks, Am Montag, den 01.03.2010, 22:21 +0100 schrieb Paul Menzel: > my Tor server is running for over three days now, but the average > bandwidth usage shown by ARM [1] is only 100 KB/s for uploaded and > downloaded. The usage increased during the first two days but has > stagnated now. > > I am using the default `/etc/tor/torrc` so bandwidth should be limited > by 5 MB/s by default, which is also shown by ARM. > > Bandwidth (cap: 5 MB, burst: 10 MB): [ … Pasted warnings seem unrelated. See other subthread. ] I can see no related messages in `/var/log/tor/log`. > Testing the bandwidth by for example downloading a big file shows that > higher bandwidth is available. > > Tor 0.2.0.35 > OR Port: 443 > Dir Port: 80 > > Could you please help me how I can find out, what is limiting Tor to use > the full available bandwidth. I noticed [NOTICE] Performing bandwidth self-test...done. in `/var/log/tor/log`. Can this be used somehow to figure out if there is a problem? I also checked with arm that the used file descriptors are below the maximum allowed ones. I am out of ideas. It would be really nice, if someone could help, because otherwise the paid traffic volume will be wasted. Thanks, Paul > [1] http://www.atagar.com/arm/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Full bandwidth is not used.
Dear SwissTor, thank you for your answer. Am Montag, den 01.03.2010, 23:47 +0100 schrieb starslights: > Well i am not sure but look like you must first upgrade your Tor version to > the > last sable minimum 0.2.1.24 who i think will first fix the "xx:xx:xx > [WARN] Rejecting insecure DH key [0] > xx:xx:xx [WARN] DH key must be at least 2." > > I am not 100% sure about that but pretty sure. I searched for the error on the WWW and it looks like this should be unrelated to the bandwidth problem and only has to do with clients not fully complying to the Tor protocol [1][2]. > A devs will for sure rightanswer you :D Unfortunately it looks like nobody had time yet. I will update my original post with new information. So please reply on the other sub-thread. Thanks, Paul [1] http://archives.seul.org/or/cvs/Oct-2009/msg00232.html [2] http://bugs.noreply.org/flyspray/?do=details&id=1114&area=remind signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Full bandwidth is not used.
Dear Tor folks, my Tor server is running for over three days now, but the average bandwidth usage shown by ARM [1] is only 100 KB/s for uploaded and downloaded. The usage increased during the first two days but has stagnated now. I am using the default `/etc/tor/torrc` so bandwidth should be limited by 5 MB/s by default, which is also show by ARM. Bandwidth (cap: 5 MB, burst: 10 MB): I am only seeing the following warnings. xx:xx:xx [WARN] Rejected invalid g^x xx:xx:xx [WARN] Rejecting insecure DH key [0] xx:xx:xx [WARN] DH key must be at least 2. Testing the bandwidth by for example downloading a big file shows that higher bandwidth is available. Tor 0.2.0.35 OR Port: 443 Dir Port: 80 Could you please help me how I can find out, what is limiting Tor to use the full available bandwidth. Thanks, Paul [1] http://www.atagar.com/arm/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
