[Feature Request] Info about PID/user/program that's sending/receiving bytes.
Jasha10 opened this issue · 15 comments
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?
Hi @Jasha10, thanks for this suggestion.
It's definitely something that I'd like to do!
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.
It's not so straightforward since it's a platform-dependent feature, but I'll try to give it a go.
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 /proc and Linux only, so I don't think you should go to reference it. Instead, there is a cross-platform finding-process Go implementation from Clash, including all platforms sniffnet supports. And here is my implementation from BoltConn written in Rust, but only for MacOS and Linux.
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
Some month ago I started trying getting PIDs on MacOS and then gave up.
In particular, what I wanted to retrieve are not just PIDs but also process names.
I thought that using sudo lsof -i -P | grep LISTEN | grep :$PORT could be a good starting point to see if I could get something interesting, but it doesn't output what I expected (i.e. all the active sockets).
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.
The performance overhead could become a problem if we should re-check the process multiple times for a given socket though, if it can change over time (?)
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
Do you have implementation I can see?
I tried to implement something like that using combination of netstat
process_sniffer
it's working but it has bad performance and it's not reliable (I think it doesn't catch all the packets)
process_sniffer it's working but it has bad performance and it's not reliable (I think it doesn't catch all the packets)
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:
To understand which utility is driving traffic, you have to run the cli with commands, for example, as in the screenshot (
lsof -i | grep part of the IP address). How realistic is it to implement this in Sniffnet software?
In this case, the network activity is created by the Signal software, but I learned about this from the CLI, not from Sniffnet
Rationale: All operating systems have GUI software that displays network activity and the application that creates it, with GNU/Linux problems.
Here is an example of a software utility from Nirsoft that contains less than 300Kb (It is clear and obvious what kind of software creates and drives traffic in Windows OS.).:
tcplogview-x64
networktrafficview-x64
process_sniffer it's working but it has bad performance and it's not reliable (I think it doesn't catch all the packets)
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.
eBPF is great for that task. I wonder if Windows had similar ability to wrap recv / send.
It will be very interesting to have that feature in windows