UI: Help user select the right net adapter by displaying how many packages are sent per second in "Select network adapter to inspect"

[corneliusroemer]

Is there an existing issue for this?

• I have searched the existing issues.

Describe the solution you'd like

Inside each item/box for each network adapter, don't only display ip addresses, but also show the number of packages that have been sent through it since startup or per second

Something like this (ugly sketch, but I hope it gets the idea across):

Is your feature request related to a problem?

I'm always frustrated when I don't know which network adapter to select. I have lots of adapters, a dozen, and 5 or so have IPs assigned, so I have to go by trial and error to find out which one is the adapter that's actually getting most traffic.

It would be great if I could see at a glance which are the active adapters, saving me the trial/error part.

[GyulyVGC]

I think that having a packet preview such as that displayed by Wireshark, or even just a packet count as you're suggesting would be really nice.

I already thought about this but there's an implementation detail that causes some concerns: in order to get the packet number for each adapter I should spawn a capture for each of the adapters, and this in theory is fine.
Problem is that this should be done in separate threads and the pcap next_packet function consists of a blocking call: this mean that I wouldn't be able to later signal all the secondary threads to stop because they are blocked on that call in case of adapters that aren't receiving packets.
This is not as bad as it seems since a blocked thread isn't wasting CPU cycles, but maybe I could figure out other possible solutions.

A step I took in this direction in the past has been to add the capability to remember the last successfully sniffed adapter when you restart the application.
Thanks to this, the problem you're mentioning only manifests at the very first run of the app.

[corneliusroemer]

Thanks! Blocked thread doesn't sound so bad to me, but I don't know enough about the perf details 😀

[marc-gav]

Hello, maybe this function might help https://docs.rs/pcap/latest/pcap/struct.Capture.html#method.setnonblock ?

I imagine that if sniffnet relies on a loop calling a blocking next_packet, there's some case in which (ethernet cable breaks) the application would never stop gracefully.

Another solution is to use a timeout. The function next_packet in the library pcap relies on a ffi call to this library function: https://www.man7.org/linux/man-pages/man3/pcap_next_ex.3pcap.html. In there, there is mention to a timeout. It is implemented here in pcap: https://github.com/rust-pcap/pcap/blob/87d91b29ca139e3acc10ef4c9042945fe7abf2cf/src/capture/inactive.rs#L49

[marc-gav]

I just started learning Rust but I can give it a try and create a prototype of this feature

[GyulyVGC]

Hey @marc-gav, feel free to give it a try, your help is warmly appreciated!

I actually think that setting the capture as not blocking could be a potential solution.
Ideally I would use this approach for all the network adapters when they haven't been selected yet, but I'd use the blocking mode for the adapter that's being monitored since I think it should be more efficient.