Re: Arm Release 1.4.0

[Damian Johnson <atagar1@xxxxxxxxx>]

Fantastic - thanks Fabian! The patch looks perfect. I'll apply it
either after work today or tomorrow morning.

> but I think the same should be done with connections on the SocksPort

Yup, sounds like a bug. Until recently arm had just been for relay
usage so I probably missed this when writing the connection panel.
I'll change it when applying the patch.

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

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

> Maybe it should be mentioning in the log message when the torrc
> can't be found?

Good point. I'll change that too.

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

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

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.

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.

Cheers! -Damian

[1] https://code.google.com/p/psutil/
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/