Created attachment 190087 [details]
Screenshot

Likely the same root cause as Bug 516712. Will investigate.

I assume before Plasma 6.6.1 the icon was a monitor with a wire, and that wire was blue, right?

Yep, same issue as Bug 516712. Marking as a duplicate. Will investigate Bug 516712.

*** This bug has been marked as a duplicate of bug 516712 ***

I am reopening this bug because while the patch in bug 516712 did fix the issue for network bridges as originally reported by the OP, it did not for VLANs, as confirmed in bug 516712 comment 21, Plasma 6.6.2 bugfix did not resolve the disconnected icon issue when using a VLAN connection only.

Darn.

If you can walk me through how to set up a VLAN, I'll fix that too.

*** Bug 517071 has been marked as a duplicate of this bug. ***

I'm more than glad to walk you through it.
Creating a VLAN device is quite straightforward. However I should explicitly mention that the steps I've outlined below will give you limited network connectivity during some stages because after bringing down your main connection, your machine WILL NOT be able to reach anything on the network (including your router and thus the internet). This is because having a fully functioning VLAN interface requires the appropriate configuration on the network equipment.

The idea here is to create a VLAN connection associated with your Ethernet connection, and then assign a static IP address to the VLAN connection, thus tricking NM into thinking the connectivity is present in some form because there's an IP address on the interface.  Below are the steps to achieve this. Every command you have to modify to fit your environment is specifically annotated with "(replace ... with ...)" so that you don't accidentally miss anything.
Connect your USB-Ethernet adapter and disable your WiFi connection (if that's what you're using).
Find your active Ethernet interface name by running:
```
ip --color=always address
```
Your interface will likely be named something like enpXs0 (in my case it's enp2s0).
Also take note of its MAC address, it will be useful later. Look for a text like this just under the line with the interface name:
```
link/ether 12:34:56:78:9a:bc
```
The "12:34:56:78:9a:bc" is an example of your MAC address.
Create a VLAN device with the following command (replace enpXs0 with your interface name):
```
nmcli connection add type vlan ifname vlan1234 con-name VLAN-1234 autoconnect no dev enpXs0 id 1234
```
Add a static IP to the VLAN interface:
```
nmcli connection modify VLAN-1234 ipv4.method manual ipv4.addresses 169.254.123.45/16
```
Bring it up:
```
nmcli connection up VLAN-1234
```
Next, to see the icon go "disconnected", you need to bring down your Ethernet connection. Note: YOU WON'T HAVE INTERNET CONNECTIVITY AFTER THAT, at least until bringing it back up.
To find out your NM *connection name* (note: not the interface name) for the wired connection, run:
```
nmcli | grep "connected to"
```
Example output:
```
enpXs0: connected to Wired Connection 1
vlan1234: connected to VLAN-1234
```
"Wired Connection 1" is an example of your connection name.
Bring down the wired connection (you will lose internet connectivity after this command) (replace "Wired Connection 1" with your default connection name):
```
nmcli connection down "Wired Connection 1"
```
Check your networking tray icon. It should look disconnected despite the VLAN interface being configured. To verify that you did everything right, run:
```
nmcli networking connectivity check
```
It should say "limited".
Bring back your Ethernet connection (replace "Wired Connection 1" with your default connection name):
```
nmcli connection up "Wired Connection 1"
```
You should have full (internet) connectivity now. You can delete your VLAN connection:
```
nmcli connection delete VLAN-1234 
```
To get a better picture of what's going on, below are steps to create a limited Ethernet connection and get the limited connection icon to see the clear difference in behavior between Ethernet and VLAN connections. The idea is the same, except this time I will show you how to create a stub Ethernet connection with an (incorrect) static IP address. Note: you will, once again, lose internet connectivity for some time.
Create a second Ethernet connection (replace enpXs0 with your interface name, replace 12:34:56:78:9a:bc with your MAC address). 
```
nmcli connection add type ethernet ifname enpXs0 con-name eth-stub-con autoconnect no mac 12:34:56:78:9a:bc
```
Add a static IP:
```
nmcli connection modify eth-stub-con ipv4.method manual ipv4.addresses 169.254.123.45/16 ipv6.method disabled
```
Bring the interface up (this will automatically bring down your current Ethernet connection and replace it with the stub one, thus you will lose internet connectivity):
```
nmcli connection up eth-stub-con
```
Look at your icon. It should (correctly) be the limited connectivity icon, which was not the case with the VLAN connection.
Check your connectivity, it should say limited:
```
nmcli networking connectivity check
```
Bring back your Ethernet connection (replace "Wired Connection 1" with your default connection name):
```
nmcli connection up "Wired Connection 1"
```
You can delete your stub connection:
```
nmcli connection delete eth-stub-con
```

Your machine should be in the state it started in. Feel free to reach out for further instructions or if anything goes wrong.

Also, in the other thread I noticed you apologized for the inconvenience of an incomplete fix. Please rest assured that it's totally okay, no worries at all! No matter if you got it perfectly on the first try or not, we all still really appreciate you taking the time to look into these problems.

Thanks! A few questions:

1. So basically, the problem here is that with a VLAN connected but without connectivity, the icon shows a red x (for "disconnected") instead of a yellow triangle (for "limited connectivity")? Is this how it was in Plasma 6.5? Or in Plasma 6.5, did the icon show a monitor with a colored wire when there was a VLAN connected but without connectivity?

2. These steps work to create a broken VLAN without connectivity; how do I create a working one so I can test that case too?

3. When I follow your steps, nothing appears in the Networks widget to indicate that there's a connected VLAN. Is that expected?

Ok, my question #3 is highly relevant here. I traced through the code, and when I follow your steps to create a VLAN, the fact that nothing shows up in the Networks widget means that plasma-nm thinks there's no device. So it falls back to showing a disconnected wired network icon.

This is also what plasma-nm did in Plasma 6.5, it's just that the icon it showed in this case was the wrong one but didn't *look* wrong (blue wire vs red x).

We need to create a VLAN that *does* show up as a device to plasma-nm somehow. Do you know how to do that?

I need some time for testing and also getting an old plasma build. Except a reply tomorrow.

For me the VLAN shows up as connection, but the icon is still red
see screenshot

Created attachment 190545 [details]
screesnhot networkmanager applet

How did you create your VLAN in such a manner that it shows up in the applet?

1.
> For me the VLAN shows up as connection, but the icon is still red.
I'm having the same issue on 6.6.2, no matter the state of the VLAN connection or connectivity check (none, limited, full).

I tried testing on 6.3 (that's the one I was able to get easily with Kubuntu 25.10). Here is what I got:
If the cable is not plugged in, I get a disconnected icon no matter what. All other experiments are done with cable connected at all times.

If the cable is connected and there's only an Ethernet connection, I get either the standard connected icon (white wire) if connection is up or the disconnected icon (red/colored wire) if it is down; hovering over the icon displays an appropriate description (connected to "Wired Ethernet 1"/disconnected respectively).
Totally correct and expected behavior.

When a VLAN connection is added, its state doesn't affect the displayed icon at all. That is, when the Ethernet connection is down, the icon is ALWAYS a colored wire - no matter what state the VLAN connection is (down/up) and connectivity check result (limited/full), at least to the extent of my experiments. And bringing up the Ethernet connection sets the icon to white (assuming full connectivity).
Interestingly enough, hovering over an icon with a connected VLAN (either full or limited) and disconnected Ethernet connection displays no description whatsoever.

I wasn't able to get a limited connection icon any way other than having a limited connectivity on the Ethernet connection.

2.
> These steps work to create a broken VLAN without connectivity
Just to make sure we're on the same page, by "a broken VLAN without connectivity" you mean "VLAN with no internet connection", is that correct?
And the output of
```
nmcli networking connectivity check
```
is "limited" and not "none", is that correct? Because if it's "none" it suggests there's probably a difference in our environments I failed to account for and the VLAN you created might be misconfigured. Were there any error-looking messages when you ran the commands? nmcli is verbose and outputs messages on success too, error messages might have blended in.
Also, just to clarify, "limited" connectivity means there is an interface that is successfully configured (has an IP address, even if a static nonsense one), but NetworkManager can't reach the internet. It's a completely valid connection state, and the tray icon should reflect "limited" state if this is the "main" connection, not "disconnected".

> how do I create a working one so I can test that case too?

VLANs are a mix of software and hardware(network equipment firmware) solutions. Creating a VLAN connection that will give you full network connectivity requires configuring the LAN port on your networking equipment (like a managed network switch) in a specific way, and to the extent of my experience home ISP routers are much more likely to not support VLANs than to support them.
If it's absolutely essential to set up a full connectivity VLAN connection, I can try to come up with *some* setup (which would involve nontrivial virtual routing that I'd be hesitant to run on a daily-driver machine).

3. Strange. I don't have this issue on my main OS installation but I was able to reproduce the issue on a Kubuntu 25 live ISO. Assuming the connections show up in system settings but not in the pop-up widget, this looks like another bug. A workaround I found is to restart plasmashell:
```
systemctl --user restart plasma-plasmashell
```
And as far as I can see this does not affect the icon though, the tray is still showing fallback one even after the connection shows up in the widget.

So about getting a working VLAN connection for testing purposes. I've crafted an example which I made as minimal as I could. The idea is to fake an intermediate level of virtual hardware between you and your router. This will allow you to create a working VLAN connection that connects to your router directly. Warning: you will lose internet connectivity during *some* parts of the process.

You will need OVS for this, install it with your distro's package manager (openvswitch-switch on Debian/Ubuntu, openvswitch on Arch).
Make sure the daemon is running:
```
sudo systemctl enable --now openvswitch-switch # ovs-vswitchd on Arch
```
Create a new virtual switch:
```
sudo ovs-vsctl add-br br-vlan-test
nmcli device set br-vlan-test managed no
sudo ip link set br-vlan-test up 
```
Deconfigure your Ethernet interface and "transfer its ownership" to the virtual switch just created (you will lose internet connectivity) (replace enpXs0 with your actual interface name, replace "Wired Connection 1" with your Ethernet connection name):
```
nmcli connection down "Wired Connection 1"
nmcli device set enpXs0 managed no
sudo ovs-vsctl add-port br-vlan-test enpXs0 tag=1234
```
Create a VLAN connection in NM:
```
nmcli connection add type vlan con-name VLAN1234 autoconnect no ifname vlan1234 dev br-vlan-test id 1234
nmcli connection up VLAN1234
```
Internet connectivity should be back now. Check the results:
```
ip --color=always address
nmcli networking connectivity check
```
Perhaps not the best approach but it's the simplest and gets the job done. Way less convoluted than things I was thinking about at first and should actually be pretty safe to do even on a daily driver (I'm writing this comment from my home PC using a VLAN connection created this way, and can actually now see the issue happening on the second machine, as I'm seeing the "disconnected" icon with full connectivity).

Below are steps to bring your machine into the state it started with (replace enpXs0 with your actual interface name, replace "Wired Connection 1" with your Ethernet connection name):
```
nmcli connection delete VLAN1234
sudo ovs-vsctl del-br br-vlan-test
nmcli device set enpXs0 managed yes
nmcli connection up "Wired Connection 1"
```

I also have the "same" issue and initially when I hit it on Fedora I found https://bugs.kde.org/show_bug.cgi?id=516712 and was waiting for the update. But it didn't fix it for me either. I, however, am not using VLAN but a NIC LACP bond. I thought I'd add the information here, after reading the history of both issues, instead of opening a new report, because I believe it's the same root cause.

NAME  UUID                                  TYPE      DEVICE
sn0   6d663ee3-8e1d-4ae0-a65e-b000b8ce339f  bond      sn0
sn1   8f705eea-751c-407d-bef6-cec3f7faf1e4  ethernet  sn1
sn2   0511a1cd-f78e-45b7-81f5-7cf43430ccdc  ethernet  sn2
lo    6b9fc3e3-6b50-48fb-b4c8-3b876892907d  loopback  lo

sn0 is the bond, sn{1,2} are 2x Intel X710 10G bond members.

*** Bug 517539 has been marked as a duplicate of this bug. ***

I am also seeing this bug on 6.6.3 with an LACP bond. As a workaround I made an edit to the plasma-nm 6.6.3 source at line 354 in libs/connectionicon.cpp and changed 

} else if (type == NetworkManager::Device::Bridge) {

to

} else if (type == NetworkManager::Device::Bridge //
           || type == NetworkManager::Device::Bond) {

then compiled the debian package for my system "fixing" the bug.

Created attachment 192401 [details]
Plasma Network Widget after patches applied

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

David, if you've managed to fix this specific issue without regressing anything, that's great! Please do feel free to submit your patches upstream at https://invent.kde.org/plasma/plasma-nm/-/merge_requests.

As for the other issues you've managed to fix, I agree that there are judgment calls to be made. However plasma-nm currently has no formal maintainer, and it's maintained by the community as a whole. This means if you're a networking professional, you likely know a lot more  about the domain than the people currently testing and merging patches for plasma-nm.

So here's my recommendation:
1. Submit a single-purpose MR that fixes this Bugzilla ticket (i.e. wrong icon with a functional VLAN)
2. Submit another MR that addresses the VLAN visibility issue more broadly, making the behavior coherent according to your professional judgment of what makes sense

What do you think?

Ahoy guys, here you go.

https://invent.kde.org/plasma/plasma-nm/-/merge_requests/593

Git commit cadf1bd0292eecaa3a42d812de1a247ea37dd6db by Nate Graham, on behalf of Fabian Druschke.
Committed on 15/06/2026 at 13:22.
Pushed by ngraham into branch 'master'.

Fix tray icon for virtual wired devices

Treating VLAN, bond, and team devices like other virtual wired
devices for tray icon selection purposes. The activated wired icon
is only used when an Ethernet carrier is present, matching the
bridge and OVS bridge behavior.
FIXED-IN: 6.6.6

M  +7    -3    libs/connectionicon.cpp

https://invent.kde.org/plasma/plasma-nm/-/commit/cadf1bd0292eecaa3a42d812de1a247ea37dd6db

Git commit e7da6e73788db2c62bf0463d81ffd06d6a7a134e by Nate Graham.
Committed on 15/06/2026 at 13:25.
Pushed by ngraham into branch 'Plasma/6.6'.

Fix tray icon for virtual wired devices

Treating VLAN, bond, and team devices like other virtual wired
devices for tray icon selection purposes. The activated wired icon
is only used when an Ethernet carrier is present, matching the
bridge and OVS bridge behavior.
FIXED-IN: 6.6.6


(cherry picked from commit cadf1bd0292eecaa3a42d812de1a247ea37dd6db)

1c08064e Fix tray icon for virtual wired devices

Co-authored-by: Fabian Druschke <fdruschke@outlook.com>

M  +7    -3    libs/connectionicon.cpp

https://invent.kde.org/plasma/plasma-nm/-/commit/e7da6e73788db2c62bf0463d81ffd06d6a7a134e

Git commit 441b9746c4a52e6ab6d2c67ddf9b6c98f8236f96 by Nate Graham.
Committed on 15/06/2026 at 13:24.
Pushed by ngraham into branch 'Plasma/6.7'.

Fix tray icon for virtual wired devices

Treating VLAN, bond, and team devices like other virtual wired
devices for tray icon selection purposes. The activated wired icon
is only used when an Ethernet carrier is present, matching the
bridge and OVS bridge behavior.
FIXED-IN: 6.6.6


(cherry picked from commit cadf1bd0292eecaa3a42d812de1a247ea37dd6db)

1c08064e Fix tray icon for virtual wired devices

Co-authored-by: Fabian Druschke <fdruschke@outlook.com>

M  +7    -3    libs/connectionicon.cpp

https://invent.kde.org/plasma/plasma-nm/-/commit/441b9746c4a52e6ab6d2c67ddf9b6c98f8236f96

i just upgraded to Plasma 6.7.0 but icon still shows disconnected, despite VLAN is connected
same config as earlier

Unfortunately the change for 6.7 was too late to make it into 6.7.0; expect the fix in 6.7.1 next week.