You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
UI: Help user select the right net adapter by displaying how many packages are sent per second in "Select network adapter to inspect" #556
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.
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 pcapnext_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.
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.
Activity
GyulyVGC commentedon Jul 4, 2024
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
pcapnext_packetfunction 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 commentedon Jul 4, 2024
Thanks! Blocked thread doesn't sound so bad to me, but I don't know enough about the perf details 😀
GyulyVGC commentedon Aug 22, 2024
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.
GyulyVGC commentedon Dec 18, 2025
It's almost there 👀