Re: Arm Release 1.4.0

[Damian Johnson <atagar1@xxxxxxxxx>]

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

I've added both of the commands you mentioned as fallback resolvers.
On Ubuntu procstat doesn't exist but sockstat does, so I've also added
handling for its Linux version too:

atagar@fenrir:~$ sockstat | egrep "tor\s*3475.*ESTABLISHED"
atagar   tor    29672    tcp4   192.168.0.3:36511    <scrubbed>:9001
 ESTABLISHED
atagar   tor    29672    tcp4   192.168.0.3:45906    <scrubbed>:9001
 ESTABLISHED
atagar   tor    29672    tcp4   192.168.0.3:60202    <scrubbed>:4430
 ESTABLISHED
atagar   tor    29672    tcp4   192.168.0.3:34600    <scrubbed>:9001
 ESTABLISHED
...

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")

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):
18:50:00 [ARM_INFO] Operating System: FreeBSD, Connection Resolvers:
sockstat (bsd), procstat (bsd)

if it doesn't match that then let me know what it says.

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)

4. Select one of the bsd options. If it doesn't work then the results
will be unchanged (ie, if options were already listed then they'll
still be listed so don't trust that, please still check the following
step for both).

5. Go back to the log. You'll see an entry like:
18:16:31 [ARM_DEBUG] system call: sockstat -4 | egrep 'tor\s*29672' |
grep -v '*:*' (runtime: 0.03)

Problems come in two flavors. Either the command resulted in an error, like:
18:15:40 [ARM_INFO] system call (failed): procstat -f 'pgrep tor' |
grep '29672' | grep -v '0.0.0.0:0' (error: 'procstat' is unavailable)

in which case please let me know what the error is, or it doesn't
provide any results:
18:15:55 [ARM_INFO] No results found using: sockstat -4 | egrep
'tor\s*29672' | grep -v '*:*'

in which case please try the command on its own and let me know how I
screwed up the greps.

> after polling for lsof and a foreach loop, doesn't work ?
> ...
> would work ... especially if the system in question is doing little (or nothing) other than Tor ...

Sorry, I'm not following. Why is a for-each loop necessary? Process
and connection resolutions are the most costly lookups arm currently
does. A netstat resolution, for instance, takes around 30-40 ms on my
system and is performed every five seconds. Arm tries to be a
lightweight application so running multiple system commands to do each
lookup isn't really an option.

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?

> However if lsof is the only way to do it right

Nope, not necessary at all. But the more connection resolvers
available for FreeBSD the more likely arm will be able to fall back to
something that works.

Cheers! -Damian
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/