-
-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Info about PID/user/program that's sending/receiving bytes. #170
Comments
Hi @Jasha10, thanks for this suggestion. Currently I'm working to introduce some major changes which will be released in the next month or so (v1.2). I had in mind to try adding PIDs in v1.3. EDIT: the implementation of PIDs identification is shifting because I'm giving precedence to other features, as described in the project roadmap. |
Hi @GyulyVGC, finding PID of connections for cross-platform application is challenging, so I want to share my experiences. The nethogs' behavior heavily relies on Specifically, to find PID for a connection on MacOS, we must use undocumented APIs and perform a weird parsing on a big chunk of raw bytes (I still don't know why but it just works). Also, the performance overhead is another factor you should consider. With my implementation, a PID lookup on Linux takes 6000-8000us, while 300-400us on MacOS. Hope my experiences could help you implement this feature in sniffnet. |
Thank you very much @XOR-op What I'd like to achieve is to get, for a given connection, the name of the process responsible for it, such that shown by the Activity Monitor native app for macOS. I'm not too worried about the performance overhead though, since I'm already using dedicated secondary threads to perform rDNS lookups. |
Yes, my implementation supports getting pid, process name, executable path and cmdline of a process by a local port, either TCP or UDP. So it should satisfy your need. As for the re-check, I don't think we need to re-check a port until its related socket is closed. But I didn't dive into sniffnet's code much. So if sniffnet doesn't hijack a connection, instead just monitor it externally (e.g. scan all opened ports but don't interfere them), it'd be better regularly perform the check. |
Sniffnet monitors without interfering and do that not for all the opened ports but those observed (with some packets incoming/outgoing) during the time of the ongoing analysis. Thank you very much for your suggestions, I may come back to you when I'll be working on the next major release 🙌 |
@XOR-op |
Neat, this is similar to a very early prototype of picosnitch where I also used scapy and psutil! It also hit a wall in terms of performance and reliability, after which I switched to focusing on just Linux and used eBPF instead. This greatly improved things and all the BPF code is at the bottom of the single source file if you're interested in it. Also, unlike Little Snitch which it's named after, picosnitch is not a firewall and literally just snitches on programs without interfering. |
Further considerations from #370 by @snooppr:
|
|
Hey @XOR-op I'm currently working on a library to retrieve PID, process name, and socket used by active processes. I was wondering if by chance your macOS implementation also works fine on other BSD systems (FreeBSD, NetBSD, OpenBSD), since they seem to not have a proc file system and how they implement it is poorly documented... |
Hey @GyulyVGC, it may be difficult to directly use the macOS implementation on other BSD systems. However, you could have a look at the freebsd_amd64 implementation from Clash which is written in Go. I did not test this implementation and was uncertain whether this would work. Another approach I suggest is to use CLI tools like |
And here it is my personal attempt to partially fix this: listeners. It currently works on macOS, Windows, and Linux. For the moment only the processes with a TCP socket in LISTEN state are returned, but it could be easily extended to all connection kinds. |
+1 for this feature, otherwise I do not see any real use case for this tool |
Is your feature request related to a problem? Please describe.
Information on what PID/user/program is responsible for each connection
Describe the solution you'd like
In the list of connections, it would be nice to see what local program is responsible for the bytes sent/received.
Additional context
The program nethogs implements this functionality: it displays a PID/username/program next to information about bytes sent/received.
Is this something that could be implemented for sniffnet?
The text was updated successfully, but these errors were encountered: