search

Zren / plasma-applet-sysmonitordash

https://store.kde.org/p/1274640/
13 stars 5 forks source link

Add some reporting intelligence to default network socket reporting #9

Open DefueBugs opened 5 years ago

DefueBugs commented 5 years ago

When reporting network sockets, the widget unconditionally reports on all sockets found. This includes NICs which are not plugged in and NICs associated with bridging.

Example: Motherboard has two built-in 1G NICs. A 10G Melonix NIC is installed. Physically, only the 10G NIC is connected to the local network. Because there are several virtual PCs which could be run at various times, 3 TUN devices are defined. The virtual bridge socket 'br0' is defined and the 10G NIC and TUN devices are all bridged to 'br0'.

In this case, the widget currently reports all three physical NICs, the three TUN sockets and the 'br0' bridge. The widget should not report any of the sockets connected to 'br0' (10G NIC and 3 TUNs). Reporting for the two unused NICs should should be user disabled as per the previously entered issue.

DefueBugs commented 5 years ago

Use that attached PNG for reference: blaze-003

Zren commented 5 years ago

I already filter out lo (loopback) and docker networks. Do these TUN sockets have a unique name that differentiates itself from other networks?

https://github.com/Zren/plasma-applet-sysmonitordash/blob/master/package/contents/ui/NetworkListDetector.qml#L27

DefueBugs commented 5 years ago

I think in theory that you never need to report TUN unless the user explicitly wants it. When TAP or TUN are associated with a physical NIC, their combined activity is already associated with the bridge (typically the br0 socket). Unless the user wants to actually track net usage for a given Virtual Machine, then this info is meaningless from the standpoint of the host. If the user really want to track the VMs net usage, they're better off doing it within the VM itself where the TUN device is seen as a normal (eth0) NIC. By default, you should probably filter out all TUN and TAP devices and let the user pull them in from lm-sensors. Then you'd only have to additionally filter out whatever physical NIC is associated with the bridge.