Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task done
corneliusroemer opened this issue Jul 4, 2024 · 2 comments
Labels
enhancement New feature, request, or improvement

Comments

@corneliusroemer
Copy link

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):
image

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
Copy link
Owner

GyulyVGC commented 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 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.

@GyulyVGC GyulyVGC added the enhancement New feature, request, or improvement label Jul 4, 2024
@corneliusroemer
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature, request, or improvement
Projects
None yet
Development

No branches or pull requests

2 participants