Arm Release 1.4.0

Damian Johnson atagar1 at gmail.com
Mon Dec 6 18:25:39 UTC 2010


Hazaa, many thanks for the patches! Committed with the exception of
sockstat2 (see below).

http://www.atagar.com/transfer/tmp/arm_bsdTest2.tar.bz2

> One unrelated problem I noticed is that Arm tends to show local
> connections as Outbound.

Netstat, lsof, etc doesn't include a notion of the directionality of a
connection, so I'm using the local port to determine if it's inbound
or outbound. If it matches the ORPort or DirPort then it's inbound,
otherwise it's outbound (line 323 of the connPanel.py [1]). Do you
know a smarter way of handling this?

I'm familiar with Linux's chroot jail environments (where this works),
but not that details of what the bsd counterpart does.

> 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.

Sorry, I'm not following. Why isn't the tor connection leaving the
system? I'm using the results of 'GETINFO address' which tends to be a
lot more helpful than showing the ip on the local network (though I
can include an option to display the local address instead if you'd
like).

> Also, when running Arm outside the Tor jail, the Tor
> configuration file isn't found.

See the "features.pathPrefix" entry in the sample armrc [2]. It's
specifically for jail environments (arm will otherwise also be failing
to find tor's state, log file, and some other resources used to
prepopulate data). If you have a suggestion for an automatic method
for determining the jail path then I'm all ears.

> 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.

I'm attempting to read the torrc from the location Tor reports (via
'GETINFO config-file'), using the features.pathPrefix as... well, a
path prefix. I'm not familiar with a method of getting the jail path
for Linux jails. Is this information available for bsd jails?

I'm happy to help with a patch to autodetect for bsd jails if you have
a suggestion for how.

> Thanks, too.  BTW where is the git repo, please ?

Arm is in svn (repository links are available on the site [3]). If
others start hacking on arm with me and prefer git then I have no
objection to moving. Until then, however, svn is what I'm most
familiar with.

> 15:08:52 [ARM_WARN] Unable to resolve tor pid, abandoning connection listing

Ick!

Many thanks for the patches! Lacking the pid will mess with most of
the system commands so this is *very* helpful.

> 15:08:51 [ARM_DEBUG] system call: netstat -npl | grep 127.0.0.1:9051 (runtime: 0.00)
> ###   ????

That was from the failed pid resolution. I attempted to use the
PidFile, pidof, netstat, and ps to resolve the pid (see getPid in
torTools.py [4]) though as the patch points out these all fail on
FreeBSD.

> -- sockstat    sockstat -4 | egrep '<process>\s*<pid>' | grep -v '*:*'
> +- sockstat    sockstat -4c | grep '<process> *<pid>'

Aren't the *:* connections unestablished? From the output given earlier:
_tor     tor        4397  8  udp4   172.27.72.202:53      *:*
_tor     tor        4397  9  tcp4   172.27.72.202:9051    *:*
_tor     tor        4397  12 tcp4   172.27.72.202:54011   [scrubbed]:9001

that seemed to be what it meant. Arm might choke on the asterisks (it
expects numeric port numbers), but including with the commit...

> +  userInput = raw_input("Enter query (<ss, netstat, lsof, sockstat> PROCESS_NAME [PID]): ").split()
> +  elif userInput[0] == "sockstat": userInput[0] = CMD_SOCKSTAT

Nice catch!

> +RUN_BSD_SOCKSTAT_2 = "sockstat -4c | awk '($2 == \"%s\" && $3 == %s) {print $6 \" \" $7}'"

Is there any advantage to having both sockstat commands? This will
probably just confuse users so I'm holding off on this one for now.

> +  5. "pgrep -x tor"

This works beautifully under Linux too, so I'm making it the secondary
resolver (after the PidFile and before pidof), this way bootstrapping
on BSD won't churn through system calls that are doomed to fail.

> + 5. "sockstat -4l -P tcp -p %i | grep tor" % <tor control port>

This one's BSD only due to the -4 flag, so keeping it as the last fallback.

> +  # XXX: both issues could be solved by filtering for the
> +  #      control port IP address instead of the process name.

By the control port IP address? If there's multiple tor instances on
the same system then they'd all have the same IP.

Again, many thanks for the patches! -Damian

[1] https://svn.torproject.org/svn/arm/trunk/src/interface/connPanel.py
[2] https://svn.torproject.org/svn/arm/trunk/armrc.sample
[3] http://www.atagar.com/arm/
[4] https://svn.torproject.org/svn/arm/trunk/src/util/torTools.py
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/



More information about the tor-talk mailing list