Damian Johnson <atagar1@xxxxxxxxx> 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@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@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@r500 ~/git/arm $time lsof -nPi -p 4775 | grep "^tor.*(ESTABLISHED)" > /dev/null real 0m0.338s user 0m0.159s sys 0m0.183s fk@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
Attachment:
signature.asc
Description: PGP signature