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.

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

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

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

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.