Skip to content

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

Closed

Description

@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):
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.

Activity

  1. GyulyVGC commented on Jul 4, 2024

    @GyulyVGC
    Owner

    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.

  2. corneliusroemer commented on Jul 4, 2024

    @corneliusroemer
    Author

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

  3. GyulyVGC commented on Aug 22, 2024

    @GyulyVGC
    Owner

    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.

  4. self-assigned this
    on Jun 3, 2025
  5. added this to the v1.5.0 milestone on Jun 28, 2025
  6. GyulyVGC commented on Dec 18, 2025

    @GyulyVGC
    Owner

    It's almost there 👀

    Image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature, request, or improvement

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions