Network ghost connections, can't disconnect

Screenshot_20241006_114558

inxi -GSaz
$ inxi -GSaz
System:
  Kernel: 6.11.0-1-default arch: x86_64 bits: 64 compiler: gcc v: 14.2.0
    clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.11.0-1-default
    root=UUID=dd274b2c-7420-497c-b1c7-8bf5ff7f80f8 splash=silent quiet
    nvidia_drm.modeset=1 fbdev=1 security=apparmor mitigations=auto
    rd.driver.blacklist=nouveau
  Desktop: KDE Plasma v: 6.1.5 tk: Qt v: N/A info: frameworks v: 6.6.0
    wm: kwin_x11 tools: avail: xscreensaver vt: 2 dm: SDDM Distro: openSUSE
    Tumbleweed 20241005
Graphics:
  Device-1: NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate] vendor: ASUSTeK
    driver: nvidia v: 560.35.03 alternate: nouveau,nvidia_drm non-free: 550.xx+
    status: current (as of 2024-09; EOL~2026-12-xx) arch: Ampere code: GAxxx
    process: TSMC n7 (7nm) built: 2020-2023 pcie: gen: 4 speed: 16 GT/s
    lanes: 16 ports: active: none off: DP-1 empty: DP-2,DP-3,HDMI-A-1
    bus-ID: 13:00.0 chip-ID: 10de:2504 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.12 with: Xwayland v: 24.1.2
    compositor: kwin_x11 driver: X: loaded: nvidia gpu: nvidia,nvidia-nvswitch
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 81 s-size: 602x343mm (23.70x13.50")
    s-diag: 693mm (27.28")
  Monitor-1: DP-1 mapped: DP-0 note: disabled model: Dell G2722HS
    serial: <filter> built: 2023 res: 1920x1080 dpi: 82 gamma: 1.2
    size: 597x336mm (23.5x13.23") diag: 685mm (27") ratio: 16:9 modes:
    max: 1920x1080 min: 640x480
  API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia device: 2
    drv: swrast gbm: drv: nvidia surfaceless: drv: nvidia x11: drv: nvidia
    inactive: wayland,device-1
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 560.35.03
    glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce RTX 3060/PCIe/SSE2
    memory: 11.72 GiB
  API: Vulkan v: 1.3.290 layers: 10 device: 0 type: discrete-gpu
    name: NVIDIA GeForce RTX 3060 driver: N/A device-ID: 10de:2504
    surfaces: xcb,xlib

When trying to open the drop-down menu on one of the ghost connections and clicking Configure, it opens the Network directory in Settings, but does not select any network.

I have tried disabling and enabling “Show virtual connections” but it did nothing to affect the issue.

I don’t know what other information I should include.

1 Like

Here the same problem on Tumbleweed:

Screenshot_20241006_114202

The number of connections match with the output from nmcli:

$ nmcli conn
NAME             UUID         TYPE      DEVICE 
Aardpeer_vpn     4abaab1d...  vpn       eno1   
eno1             1b316f6c...  ethernet  eno1   
lo               6d296982...  loopback  lo     
tun0             214b5ae7...  tun       tun0

So it looks to me the two ghost entries are for lo and tun0.

For completeness:

$ nmcli dev
DEVICE  TYPE      STATE                   CONNECTION 
eno1    ethernet  connected               eno1       
lo      loopback  connected (externally)  lo         
tun0    tun       connected (externally)  tun0

For “lo” there is an indication on what is wrong in the configuration window that I see also in the openingspost:

Screenshot_20241006_115024

It looks to me to some kind of regression, this was working fine I think a month or more ago. I must say that I have been experimenting with adding a bridge but undid these settings. Network functionality is working as expected.

1 Like
$ nmcli dev
DEVICE       TYPE      STATE                   CONNECTION  
enp21s0f3u1  ethernet  connected               enp21s0f3u1 
lo           loopback  connected (externally)  lo          
virbr0       bridge    connected (externally)  virbr0      
vnet3        tun       connected (externally)  vnet3       
enp18s0      ethernet  unavailable             --          
wlp16s0      wifi      unavailable             --     

It would appear that the ghost connections that I have are for enp18s0 and wlp16s0, but if so, these are only 2 connections, and I have 6.
At the moment of writing this I’m currently running a VM, hence the virbr0, etc.

On the lo connection there is already:

I understand that NetworkManager is/can nowadays “managing” the lo, what I think is not good is that the GUI indicates “Unknown connection type” and KDE Networks applet shows this connection without any details, but maybe that has the same root case.

I did do an experiment with “nmcli” for the VPN. If I disconnect the VPN using the applet, nmcli shows only two connections, the Ethernet and the lo. If I connect the VPN again I get two additional connections (other two connection left out):

$ nmcli
Aardpeer_vpn VPN connection
        controller eno1, VPN, ip4 default
        inet4 10.77.72.6/32
        route4 10.77.72.5/32 metric 50
        route4 10.77.72.1/32 via 10.77.72.5 metric 50
        route4 default via 10.77.72.5 metric 50

tun0: connected (externally) to tun0
        "tun0"
        tun, sw, mtu 1500
        inet4 10.77.72.6/32
        route4 10.77.72.5/32 metric 50
        route4 10.77.72.1/32 via 10.77.72.5 metric 50
        route4 default via 10.77.72.5 metric 50

Not sure what to make from this.

Reading the earlier linked lo topic I see that this is supposed to fixed in KDE:

I see these fixes were merged 3 months ago and that I am running:

$ sudo zypper info kf6-networkmanager-qt | grep Version
Version        : 6.6.0-1.1

And based on Commits · master · Frameworks / NetworkManagerQt · GitLab it looks to me these fixes are in.

1 Like
$ sudo zypper info kf6-networkmanager-qt | grep Version
Version        : 6.6.0-1.1

I’m also running the same version, and from what I understand despite there being fixes, I’m still running into the issue.

Since I updated to openSUSE Tumbleweed 20241006 I see the same problem.

My Arch Linux system shows it as well.

The bug is reported already.

2 Likes

Some activity on the KDE Issue but no sign a a fix yet.

1 Like

Here it is said that a Qt-bug would be at the root of this problem.

However that Qt-bug is fixed in Qt-Versions 6.5.8, 6.8.1 and 6.9.0. So the question is:

Will that fix being backported to Qt 6.7.x or will we have to wait until Qt 6.8.1?

2 Likes

From here:

There will be no more 6.7.x releases

My last Tumbleweed update brought some qt6-*-6.8.0 packages so no 6.8.1 yet.

Last night I updated my system

Operating System: openSUSE Tumbleweed 20241017
KDE Plasma Version: 6.2.1
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.11.3-1-default (64-bit)
Graphics Platform: X11
Graphics Processor: Mesa Intel® HD Graphics 630

and the problem is gone.

3 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.