GyulyVGC
Feature Requests: Support for UDP protocol and also details on network connections.
Hey thanks for creating this really cool library!
In the README its mention that it supports TCP only. Is it feasible to include UDP as well?
In addition, currently it only includes processes that are listening on a port. Is it feasible to include all network connections, both listening and estblashied?
Similar to the netstat output below
Proto Local Address Foreign Address (state)
tcp 10.123.123.123:54459 185.199.108.133:443 ESTABLISHED
tcp 10.123.123.123:54458 185.199.109.154:443 ESTABLISHED
tcp 127.0.0.1.8384 *.* LISTEN
udp *.56612 *.*
Feature Request Summary
- Support for UDP protocol
- Include details on all network connections
If these requests are out of scope, no worries. Feel free to close the issue Let me know if additional info is required.
Thanks!
Is it feasible to include UDP as well? ... In addition, currently it only includes processes that are listening on a port. Is it feasible to include all network connections, both listening and estblashied?
Yes, it is feasible. However, at the moment just TCP is included since UDP is connectionless and the concept of listener doesn't really apply. And as the name of the library suggests, only connections in the listen state are reported (this is on purpose). However, I could consider extending the scope of this library in the future.
I'll leave this issue open as a reminder, thanks 🙌
UDP is connectionless and the concept of listener doesn't really apply.
But UDP servers "listen" for packets, like DNS-servers listen on port 53, for example. Don't they?
But UDP servers "listen" for packets, like DNS-servers listen on port 53, for example. Don't they?
UDP ports are either open or close, they don't have other possible states. So you could consider an open UDP port as "listening", but the concept is different since UDP just sends datagrams and doesn't establish connections.
Are you accepting contributions to this project? I believe you started this library to extend Sniffnet with PID. I was thinking of adding UID to Sniffnet - I once did but it was not cross-platform - until I came across your library. This feature would be of great importance especially in the context of many users connected to the system - like servers. Of course, this feature - as well as UDP - would change the scope of this library.
Hi @islameehassan
It would be awesome if you could help!
Yeah, I'm planning to use this library with Sniffnet in case it gets accurate enough. The criteria is to at least support Windows, Linux, and macOS.
From what I've learnt so far, the most difficult part is to get process names for all the connections we are monitoring in Sniffnet.
It's fine to change the scope of this library if we'll get a good solution to this problem, don't worry about that.
@islameehassan a problem you'll probably face is that in general there is no process information available for most of the connections... this is why I was just focusing on the TCP in listen state. You'll notice that most of the connections established by Sniffnet are not there.
@islameehassan a problem you'll probably face is that in general there is no process information available for most of the connections... this is why I was just focusing on the TCP in listen state. You'll notice that most of the connections established by Sniffnet are not there.
Yes, I noticed that. I modified the get_all example to run in an infinite loop to get all current and previous listeners, while at the same time running Sniffnet, setting the protocol filter to TCP. The difference was huge, which was apparent even without doing this experiment. But when I added SYN_SENT state (in tcp_listeners.rs in Linux), the difference largely decreased (compared to LISTEN only), and all connections got process information. Still, there were many connections in Sniffnet not shown by get_all.