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 majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/