https://bugs.kde.org/show_bug.cgi?id=516709
--- Comment #21 from [email protected] --- --- Confirmed still broken on Plasma 6.6.5, NM 1.56.1, CachyOS Linux (Arch-based). I was able to reproduce all three issues and patch them locally. Detailed findings below. --- My setup I have a single physical NIC (eno1) connected to a managed network switch configured as an 802.1Q VLAN trunk. On a trunk port, the switch tags each Ethernet frame with a VLAN ID before sending it down the wire, allowing multiple logically separate networks to share a single physical cable. The receiving end strips or reads the tag to determine which network the frame belongs to. On the Linux side, this looks like: 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... link/ether 30:c5:99:76:c3:cf (no IP address — this is correct and intentional) 213: eno1.10@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> ... inet 192.168.10.200/24 214: eno1.20@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> ... inet 192.168.20.200/24 215: eno1.50@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> ... inet 192.168.50.200/24 eno1 is the physical trunk — it carries tagged frames for all VLANs but has no IP address of its own. Think of it as the cable, not the connection. eno1.10, eno1.20, and eno1.50 are virtual interfaces, one per VLAN. Each one represents this host's presence on that VLAN. The IP address on each is the host's address within that VLAN's subnet, assigned via DHCP from the router. These are the actual connections the user cares about. In NetworkManager terms: - eno1 has a profile (eno1-trunk) with ipv4.method=disabled and ipv6.method=disabled — no IP, just a trunk carrier - eno1.10 has a VLAN profile (asgard), DHCP, full internet access - eno1.20 has a VLAN profile (nidavellir), DHCP - eno1.50 has a VLAN profile (valhalla), DHCP NetworkManager classifies the VLAN sub-interfaces as "slaves" of eno1. But from the user's perspective, the VLAN interfaces are the primary connections — eno1 itself is invisible infrastructure. --- Three separate issues found and patched --- Issue 1 — Tray icon shows disconnected despite active VLAN connections libs/connectionicon.cpp, line 354. The device type check only handled Bridge. Bond and Vlan device types fell through to setDisconnectedIcon(). // Before: } else if (type == NetworkManager::Device::Bridge) { // After: } else if (type == NetworkManager::Device::Bridge || type == NetworkManager::Device::Bond || type == NetworkManager::Device::Vlan) { --- Issue 2 — Active VLAN connections not shown in the Networks widget libs/models/appletproxymodel.cpp, lines 33–37. Slave connections are unconditionally filtered out of the widget when not searching. This is reasonable for inactive connection profiles, but actively connected VLANs with real traffic should be visible. // Before: const bool isSlave = sourceModel()->data(index, NetworkModel::SlaveRole).toBool(); if (isSlave && filter.isEmpty()) { return false; } // After: const bool isSlave = sourceModel()->data(index, NetworkModel::SlaveRole).toBool(); const bool isConnected = sourceModel()->data(index, NetworkModel::ConnectionStateRole).toUInt() == NetworkManager::ActiveConnection::Activated; if (isSlave && filter.isEmpty() && !isConnected) { return false; } --- Issue 3 — Root cause of Issue 2: VLAN connections classified as virtual and gated behind a disabled setting libs/editor/uiutils.cpp, isConnectionTypeVirtual(). Vlan is in the virtual types list, which causes isConnectionTypeSupported() to return false for VLANs unless manageVirtualConnections is explicitly enabled in settings — which defaults to off. // Before: if (type == NetworkManager::ConnectionSettings::Bond || type == NetworkManager::ConnectionSettings::Bridge || type == NetworkManager::ConnectionSettings::Infiniband || type == NetworkManager::ConnectionSettings::Team || type == NetworkManager::ConnectionSettings::Vlan || type == NetworkManager::ConnectionSettings::Loopback) { // After: if (type == NetworkManager::ConnectionSettings::Bond || type == NetworkManager::ConnectionSettings::Bridge || type == NetworkManager::ConnectionSettings::Infiniband || type == NetworkManager::ConnectionSettings::Team || type == NetworkManager::ConnectionSettings::Loopback) { --- A note on perspective for Issues 2 and 3 Whether these are bugs or intentional behavior depends on your point of view, and I want to be transparent about that. From a network engineering perspective, VLANs are real Layer 2 networks. They carry actual traffic, have their own IP subnets, and are the connections a user directly interacts with. The fact that they are software-defined doesn't make them "virtual" in any meaningful UX sense — they are real networks, just defined in software rather than by separate physical cables. Hiding them behind manageVirtualConnections produces genuinely surprising behavior for anyone running a VLAN trunk setup. That said, a system administrator coming from a different background might reasonably expect VLANs to behave like other virtual connection types (Bond, Bridge) and prefer to control their visibility via the manageVirtualConnections toggle. There is a valid argument for that approach too. A reasonable middle ground: keep Vlan in isConnectionTypeVirtual() but change the default value of manageVirtualConnections to true, so VLAN connections are visible out of the box while still being user-controllable. The slave filtering in Issue 2 could similarly be tied to manageVirtualConnections rather than active connection state. I defer to the maintainers on the right approach. The goal here is to document what is happening in the code and why it produces unexpected behavior for users with VLAN trunk setups. Screenshot attached showing the Networks widget after all three patches applied — active VLAN connections visible with real-time traffic stats and Disconnect buttons. -- You are receiving this mail because: You are watching all bug changes.
