[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Arm Release 1.4.0
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@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/