Re: Arm Release 1.4.0
Damian Johnson atag...@gmail.com wrote: Hi all. I've checked in the resolver fixes (thank Fabian and Hans!) and a test tarball is available at: http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2 http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2.asc Thanks. For BSD I'm using the following commands: sockstat -4 | egrep 'process\s*pid' | grep -v '*:*' procstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' Neither of those commands work for me. To let Arm figure out Tor's pid I still need the pgrep patch I mailed you yesterday. Attached are the patches I used to get it working on FreeBSD 9.0 CURRENT. I also rebased the sockstat+awk patch, but sockstat+grep probably works reliably enough. One unrelated problem I noticed is that Arm tends to show local connections as Outbound. A connection from the Privoxy jail to the Tor jail: _tor tor2750 25 tcp4 10.0.0.2:9050 10.0.0.1:20528 shows up as: [public gateway IP address scrubbed]:9050 -- scrubbed 0.0s (OUTBOUND) Given that the connection doesn't leave the system, replacing the Tor jail IP address with the public IP address of the gateway is a bit confusing. Also, when running Arm outside the Tor jail, the Tor configuration file isn't found. Fabian From 48734e94a8205754f793b19d1db77bd72e2a305b Mon Sep 17 00:00:00 2001 From: Fabian Keil f...@fabiankeil.de Date: Sat, 4 Dec 2010 17:36:53 +0100 Subject: [PATCH 1/4] Add pgrep as another way to get the tor pid. --- src/util/torTools.py | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/src/util/torTools.py b/src/util/torTools.py index d18869b..077c2e1 100644 --- a/src/util/torTools.py +++ b/src/util/torTools.py @@ -96,6 +96,7 @@ def getPid(controlPort=9051, pidFilePath=None): 2. pidof tor 3. netstat -npl | grep 127.0.0.1:%s % tor control port 4. ps -o pid -C tor + 5. pgrep tor If pidof or ps provide multiple tor instances then their results are discarded (since only netstat can differentiate using the control port). This @@ -150,6 +151,16 @@ def getPid(controlPort=9051, pidFilePath=None): if pid.isdigit(): return pid except IOError: pass + # attempts to resolve using pgrep, failing if: + # - tor is running under a different name + # - there are multiple instances of tor + try: +results = sysTools.call(pgrep tor) +if len(results) == 1 and len(results[0].split()) == 1: + pid = results[0].strip() + if pid.isdigit(): return pid + except IOError: pass + return None def getConn(): -- 1.7.3.2 From 1bd8015476dd5c3613e3384ca373d9f096aabae4 Mon Sep 17 00:00:00 2001 From: Fabian Keil f...@fabiankeil.de Date: Sun, 5 Dec 2010 11:49:35 +0100 Subject: [PATCH 2/4] Shorten RUN_BSD_SOCKSTAT and get it working. --- src/util/connections.py |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/connections.py b/src/util/connections.py index 2487afb..7824f4f 100644 --- a/src/util/connections.py +++ b/src/util/connections.py @@ -12,7 +12,7 @@ all queries dump its stderr (directing it to /dev/null). FreeBSD lacks support for the needed netstat flags and has a completely different program for 'ss'. However, there's a couple other options (thanks to Fabian Keil and Hans Schnehl): -- sockstatsockstat -4 | egrep 'process\s*pid' | grep -v '*:*' +- sockstatsockstat -4c | grep 'process *pid' - procstatprocstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' @@ -62,7 +62,7 @@ RUN_LSOF = lsof -nPi | grep \%s\s*%s.*(ESTABLISHED)\ # *note: this isn't available by default under ubuntu RUN_SOCKSTAT = sockstat | egrep \%s\s*%s.*ESTABLISHED\ -RUN_BSD_SOCKSTAT = sockstat -4 | egrep '%s\s*%s' | grep -v '*:*' +RUN_BSD_SOCKSTAT = sockstat -4c | grep '%s *%s' RUN_BSD_PROCSTAT = procstat -f 'pgrep %s' | grep '%s' | grep -v '0.0.0.0:0' RESOLVERS = [] # connection resolvers available via the singleton constructor -- 1.7.3.2 From 12d267f497870ecff1b37bddb1aeb44e9ba01994 Mon Sep 17 00:00:00 2001 From: Fabian Keil f...@fabiankeil.de Date: Sun, 5 Dec 2010 12:07:36 +0100 Subject: [PATCH 3/4] Get RUN_BSD_PROCSTAT working. --- src/util/connections.py |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/util/connections.py b/src/util/connections.py index 7824f4f..062562e 100644 --- a/src/util/connections.py +++ b/src/util/connections.py @@ -13,7 +13,7 @@ FreeBSD lacks support for the needed netstat flags and has a completely different program for 'ss'. However, there's a couple other options (thanks to Fabian Keil and Hans Schnehl): - sockstatsockstat -4c | grep 'process *pid' -- procstatprocstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' +- procstatprocstat -f pid | grep TCP | grep -v 0.0.0.0:0 import os @@ -63,7 +63,7 @@ RUN_LSOF = lsof -nPi | grep \%s\s*%s.*(ESTABLISHED)\ RUN_SOCKSTAT = sockstat | egrep \%s\s*%s.*ESTABLISHED\ RUN_BSD_SOCKSTAT = sockstat -4c |
Re: Arm Release 1.4.0
Answering to Fabian's mail, which came a minute before I was about send a more verbose answer. On Sun, Dec 05, 2010 at 01:02:16PM +0100, Fabian Keil wrote: Damian Johnson atag...@gmail.com wrote: Hi all. I've checked in the resolver fixes (thank Fabian and Hans!) and a test tarball is available at: http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2 http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2.asc Thanks. Thanks, too. BTW where is the git repo, please ? For BSD I'm using the following commands: sockstat -4 | egrep 'process\s*pid' | grep -v '*:*' procstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' Neither of those commands work for me. To let Arm figure out Tor's pid I still need the pgrep patch I mailed you yesterday. It did work fine under FreeBSD 7.4-PRERELEASE with sockstat the way you suggested. I modified in src/util/connections.py again to RUN_BSD_SOCKSTAT = sockstat -4c | grep '%s%s' (See Fabian's patch.) This works fine, too. Just one cycle less. Neither of the other options though did succeed in displaying a connection list. Attached are the patches I used to get it working on FreeBSD 9.0 CURRENT. I also rebased the sockstat+awk patch, but sockstat+grep probably works reliably enough. One unrelated problem I noticed is that Arm tends to show local connections as Outbound. A connection from the Privoxy jail to the Tor jail: _tor tor2750 25 tcp4 10.0.0.2:9050 10.0.0.1:20528 shows up as: [public gateway IP address scrubbed]:9050 -- scrubbed 0.0s (OUTBOUND) Can verify this, running arm on a host connecting to a jail's tor controlport results in this. Given that the connection doesn't leave the system, replacing the Tor jail IP address with the public IP address of the gateway is a bit confusing. Also, when running Arm outside the Tor jail, the Tor configuration file isn't found. An old torrc located in the host in the same path as the jail, I wondered where these odd configs came from. Removing the hosts torrc gave ### Unable to load the torrc ### so arm is trying to read a torrc on the host in the location it knows which is displayed from the jail, but is ignoring the jail flag. Sorry for not getting deeper in this right now. To Fabian, instead of adding another patch: Running 'pgrep tor' might show multiple results, anything containing the string 'tor' will present it's pid. On 7 it's 'pgrep -x' to get an exact match of the argument ,see man pgrep(1). Thanks for the patches ! To all : The working connection list looks great ! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
On Sat, Dec 04, 2010 at 07:49:58PM -0800, Damian Johnson wrote: ... For BSD I'm using the following commands: sockstat -4 | egrep 'process\s*pid' | grep -v '*:*' procstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' The purpose of these greps is to only get established connections and to filter by the pid (in case there's multiple tor instances). To test please do the following: 1. Run arm at its debug runlevel (arm -e 1) 15:08:52 [ARM_INFO] Terminal color support detected and enabled 15:08:52 [ARM_DEBUG] GETINFO events/names (runtime: 0.0002) [1 duplicate hidden] 15:08:52 [ARM_DEBUG] GETCONF ORPort (cache fetch) [19 duplicates hidden] 15:08:52 [ARM_DEBUG] GETINFO accounting/enabled (runtime: 0.0001) 15:08:52 [ARM_DEBUG] GETINFO desc/id/Unknown (runtime: 0.0001) 15:08:52 [ARM_DEBUG] GETINFO fingerprint (cache fetch) [2 duplicates hidden] 15:08:52 [ARM_WARN] Unable to resolve tor pid, abandoning connection listing 15:08:52 [ARM_DEBUG] GETINFO config/names (runtime: 0.0012) 15:08:52 [ARM_DEBUG] GETINFO config-text (runtime: 0.0016) --- 15:08:51 [ARM_DEBUG] system call: sockstat -4c | grep 'tor' (runtime: 0.00) 15:08:51 [ARM_DEBUG] GETINFO ns/id/Unknown (runtime: 0.0002) 15:08:51 [ARM_DEBUG] GETINFO fingerprint (runtime: 0.0002) 15:08:51 [ARM_DEBUG] GETINFO address (runtime: 0.0003) 15:08:51 [ARM_DEBUG] GETINFO status/version/current (runtime: 0.0002) 15:08:51 [ARM_DEBUG] GETINFO version (cache fetch) 15:08:51 [ARM_INFO] Operating System: FreeBSD, Connection Resolvers: sockstat (bsd), procstat (bsd) 15:08:51 [ARM_WARN] Unable to load torrc (no such file or directory: '/path/to/torrc') ### this is the path on the host, tor is running in a jail 15:08:51 [ARM_DEBUG] GETINFO config-file (runtime: 0.0002) 15:08:51 [ARM_DEBUG] system call: ps -o pid -C tor (runtime: 0.00) 15:08:51 [ARM_DEBUG] system call: netstat -npl | grep 127.0.0.1:9051 (runtime: 0.00) ### 15:08:51 [ARM_INFO] system call (failed): pidof tor (error: 'pidof' is unavailable) 15:08:51 [ARM_INFO] Loaded configuration descriptions from '/tmp/arm/torConfigDescriptions.txt' (runtime: 0.000) 15:08:51 [ARM_DEBUG] GETINFO version (runtime: 0.0002) 15:08:45 [ARM_NOTICE] No configuration found at '/home/user/.armrc', using defaults 2. Arm defaults to the bsd resolvers if os.uname() matches FreeBSD. Please look for an entry like the following in your logs (it'll be near the start): See above. 3. Go to arm's second page and press u to bring up the resolver options. Regardless of the OS detected it will have: * auto * netstat * ss * lsof * sockstat * sockstat (bsd) * procstat (bsd) To make it short: the sockstat (bsd) option works on FreeBSD 7.4-PRERELEASE. This is nice. See above for log. That said, from the link you provided it looks like this isn't necessary. What arm currently attempts is: lsof -nPi | grep process\s*pid.*(ESTABLISHED) If FreeBSD has an equivalents for the flags (n = prevent dns lookups, P = show port numbers (not names), i = ip only) then please show me what its output looks like and I'd be happy to add it as another fallback resolver. What order should sockstat, procstat, and lsof be attempted in? Are any of them preferable due to jails over the others? I would avoid lsof. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Hans Schnehl torvallena...@gmail.com wrote: On Sun, Dec 05, 2010 at 01:02:16PM +0100, Fabian Keil wrote: Damian Johnson atag...@gmail.com wrote: Hi all. I've checked in the resolver fixes (thank Fabian and Hans!) and a test tarball is available at: http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2 http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2.asc Thanks. Thanks, too. BTW where is the git repo, please ? I don't think there is an official git repository. To Fabian, instead of adding another patch: Running 'pgrep tor' might show multiple results, anything containing the string 'tor' will present it's pid. Good point. On 7 it's 'pgrep -x' to get an exact match of the argument ,see man pgrep(1). It's -x on CURRENT, too. Patch attached. I also attached one to get the pid through sockstat. I think changing it to additionally filter for the control port address would get the most reliable results. Fabian From cdb53450e64c38a5792b10328790dee49be32371 Mon Sep 17 00:00:00 2001 From: Fabian Keil f...@fabiankeil.de Date: Sun, 5 Dec 2010 15:09:26 +0100 Subject: [PATCH 1/2] Use pgrep's -x flag. Pointed out by Hans Schnehl --- src/util/torTools.py |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/torTools.py b/src/util/torTools.py index 077c2e1..056b066 100644 --- a/src/util/torTools.py +++ b/src/util/torTools.py @@ -96,7 +96,7 @@ def getPid(controlPort=9051, pidFilePath=None): 2. pidof tor 3. netstat -npl | grep 127.0.0.1:%s % tor control port 4. ps -o pid -C tor - 5. pgrep tor + 5. pgrep -x tor If pidof or ps provide multiple tor instances then their results are discarded (since only netstat can differentiate using the control port). This @@ -155,7 +155,7 @@ def getPid(controlPort=9051, pidFilePath=None): # - tor is running under a different name # - there are multiple instances of tor try: -results = sysTools.call(pgrep tor) +results = sysTools.call(pgrep -x tor) if len(results) == 1 and len(results[0].split()) == 1: pid = results[0].strip() if pid.isdigit(): return pid -- 1.7.3.2 From fc8f0f7be7590a6bde2c2efaaa84f36be5af1136 Mon Sep 17 00:00:00 2001 From: Fabian Keil f...@fabiankeil.de Date: Sun, 5 Dec 2010 15:24:50 +0100 Subject: [PATCH 2/2] Add sockstat as another way to get the tor pid. --- src/util/torTools.py | 17 - 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/src/util/torTools.py b/src/util/torTools.py index 056b066..1a36f71 100644 --- a/src/util/torTools.py +++ b/src/util/torTools.py @@ -96,7 +96,8 @@ def getPid(controlPort=9051, pidFilePath=None): 2. pidof tor 3. netstat -npl | grep 127.0.0.1:%s % tor control port 4. ps -o pid -C tor - 5. pgrep -x tor + 5. sockstat -4l -P tcp -p %i | grep tor % tor control port + 6. pgrep -x tor If pidof or ps provide multiple tor instances then their results are discarded (since only netstat can differentiate using the control port). This @@ -151,6 +152,20 @@ def getPid(controlPort=9051, pidFilePath=None): if pid.isdigit(): return pid except IOError: pass + # attempts to resolve using sockstat, failing if: + # - tor is running under a different name + # - there are multiple instances of Tor, using the + # same control port on different addresses. + # + # XXX: both issues could be solved by filtering for the + # control port IP address instead of the process name. + try: +results = sysTools.call(sockstat -4l -P tcp -p %i | grep tor % controlPort) +if len(results) == 1 and len(results[0].split()) == 7: + pid = results[0].split()[2] + if pid.isdigit(): return pid + except IOError: pass + # attempts to resolve using pgrep, failing if: # - tor is running under a different name # - there are multiple instances of tor -- 1.7.3.2 signature.asc Description: PGP signature
Re: [notice] Circuit build measurement period of 218915ms is more than twice the maximum build time we have ever observed. Capping it to 152350ms.
Roger Dingledine wrote: On Sat, Dec 04, 2010 at 07:00:17AM +, Orionjur Tor-admin wrote: I have the above record in '/var/tor/log' on my exit-node. What it can mean?! Tor clients build circuits when they first start up, to estimate the average amount of time it takes to build a circuit. Once they have a good estimate, they abandon the slowest 20% of the circuits they make, since a circuit that takes a long time to build will probably be no fun to use. Your circuit build times appear to be really crummy. Your Tor has estimated that the 80% mark for you is 219 seconds. But in fact, the slowest circuit you've actually created took only 152 seconds. I believe this situation can occur when many of the circuits your Tor tries to make fail to get created at all. Are you rate limiting your exit node? Perhaps you should start. It seems like your network is really overloaded. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ I rated limiting my node the following: BandwidthRate 200 KBytes BandwidthBurst 400 KBytes And some times ago it works time. But that time it permanently crashes, I cannot understand why. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [notice] Circuit build measurement period of 218915ms is more than twice the maximum build time we have ever observed. Capping it to 152350ms.
On Sun, Dec 05, 2010 at 03:16:01PM +, Orionjur Tor-admin wrote: Are you rate limiting your exit node? Perhaps you should start. It seems like your network is really overloaded. I rated limiting my node the following: BandwidthRate 200 KBytes BandwidthBurst 400 KBytes Try RelayBandwidthRate 200 KBytes RelayBandwidthBurst 400 KBytes instead, and see if that makes things better on your side. And some times ago it works time. But that time it permanently crashes, I cannot understand why. https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#MyTorkeepscrashing. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Configuring a Hidden Service
Hello. In reading: Configuring Hidden Services for Tor I came upon this in Step Three: More advanced tips. If your computer isn't online all the time, your hidden service won't be either. This leaks information to an observant adversary. Does it leak because it is online all the time or because it isn't online all the time? And how or what does it leak? Also, does one need to be connected (online), to the Tor network in order to precheck a Hidden Services site in order to make sure it is working properly? Can it open in Firefox browser offline and whatever one will put on or in their site, can be done without and before, Tor clients can visit? I'm assuming that if one does this and I'm assuming prechecking is necessary, then that would mean the new onion address is not yet advertised to the Tor network for Tor clients to use but it is now part of the database of the Tor servers in order for them to resolve the 16 digit onion URL. Am I on the right track here? Thanks
