Arm Release 1.4.0

[Fabian Keil]

Damian Johnson <atagar1 at gmail.com> wrote:

> > The connection doesn't leave the system because its a socks
> > connection with both the source and the destination address
> > located on the same system.
> 
> Makes sense. So if both the source and destination are private IPs
> (10.*, 172.16.* - 172.31.*, 192.168.*) then skip the private ->
> external translation for the display, right?

Right.
 
> I'm still trying to get my head around the rest of this bit. From an
> UI perspective doing location1 -> location2 -> location3 entries will
> be pretty difficult.

If it's the varying number of columns that would cause difficulties,
you could keep the colums constant with lines like:

location1 (location2) --> location3 ...

>                      Also, I've never run into this use case so I'm
> not quite sure what you're describing. Oh well, maybe things will be
> clearer after a bit more coffee.

You get pretty much the same use case, but without jails, when running
Tor in a local network behind a port-forwarding gateway. I would expect
this to be rather common for bridges.

> > I missed procstat, though.
> 
> Actually, neither of the BSD resolvers were added (that was the Linux
> sockstat entry). I'll add them both.
> 
> 
> The psutil library [1] uses lsof as its default connection resolver
> for FreeBSD so I'd like to get a working fallback for it. However,
> from Hans' feedback earlier it sounds like there's issues with jails
> so I'll use it as a last resort.

Unless I misunderstood Hans, he was mainly concerned about
having to install a dependency that offers nothing the base
system doesn't already provide anyway.

> The command I'm now using for Linux is:
> lsof -nPi -p <pid> | grep "<process>.*(ESTABLISHED)"

With ^ added to the pattern it seems to work:

fk at r500 ~/git/arm $lsof -nPi -p 4775 | grep "^tor.*(ESTABLISHED)"
tor       4775    _tor    4u    IPv4 0xfffffe00471633a8        0t0   TCP 10.0.0.2:35771->[scrubbed]:9001 (ESTABLISHED)
tor       4775    _tor   14u    IPv4 0xfffffe0047c71000        0t0   TCP 10.0.0.2:15999->[scrubbed]:443 (ESTABLISHED)
tor       4775    _tor   15u    IPv4 0xfffffe0047221af8        0t0   TCP 10.0.0.2:9051->10.0.0.2:20692 (ESTABLISHED)

Otherwise arm itself shows up multiple times, too:

fk at r500 ~/git/arm $lsof -nPi -p 4775 | grep "tor.*(ESTABLISHED)"
tor       4775    _tor    4u    IPv4 0xfffffe00471633a8        0t0   TCP 10.0.0.2:35771->[scrubbed]:9001 (ESTABLISHED)
tor       4775    _tor   14u    IPv4 0xfffffe0047c71000        0t0   TCP 10.0.0.2:15999->[scrubbed]:443 (ESTABLISHED)
tor       4775    _tor   15u    IPv4 0xfffffe0047221af8        0t0   TCP 10.0.0.2:9051->10.0.0.2:20692 (ESTABLISHED)
python    9179    _tor    3u    IPv4 0xfffffe0047221000        0t0   TCP 10.0.0.2:20692->10.0.0.2:9051 (ESTABLISHED)
python    9179    _tor    3u    IPv4 0xfffffe0047221000        0t0   TCP 10.0.0.2:20692->10.0.0.2:9051 (ESTABLISHED)
python    9179    _tor    3u    IPv4 0xfffffe0047221000        0t0   TCP 10.0.0.2:20692->10.0.0.2:9051 (ESTABLISHED)
python    9179    _tor    3u    IPv4 0xfffffe0047221000        0t0   TCP 10.0.0.2:20692->10.0.0.2:9051 (ESTABLISHED)
python    9179    _tor    3u    IPv4 0xfffffe0047221000        0t0   TCP 10.0.0.2:20692->10.0.0.2:9051 (ESTABLISHED)
python    9179    _tor    3u    IPv4 0xfffffe0047221000        0t0   TCP 10.0.0.2:20692->10.0.0.2:9051 (ESTABLISHED)

Showing the same connection six times in a row makes little
sense to me, but then again, I'm not familiar with lsof.

lsof also seems to be rather slow (on FreeBSD):

fk at r500 ~/git/arm $time lsof -nPi -p 4775 | grep "^tor.*(ESTABLISHED)" > /dev/null

real    0m0.338s
user    0m0.159s
sys     0m0.183s
fk at r500 ~/git/arm $time sockstat -4c | grep 'tor *4775' > /dev/null

real    0m0.010s
user    0m0.015s
sys     0m0.005s

> However, like sockstat it probably omits the ESTABLISHED tags from
> results. If so, this will need a workaround. On Linux the following
> looks right:
> lsof -nPi -sTCP:ESTABLISHED -p <pid> | grep "<process>" | grep TCP
> 
> Does this to the trick? For some reason there was a UDP connection
> included despite the -sTCP part, hence the extra grep. The lsof man
> warns that "State  names  vary with UNIX dialects" so it might expect
> a different keyword.

That works too, but without the ^, arm itself shows up again.

> If there aren't any concerns between the resolvers then we should
> default to whatever performs the best. When you run at the debug level
> (arm -e 1) it provides the runtime for system calls (sockstat,
> procstat, lsof, etc) so they should be easy to compare.

procstat and sockstat seem to perform comparable, but sockstat
has the advantage that it will work if arm is run as neither
the tor user nor root.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20101211/e8b62336/attachment.pgp>