Package: discover
Version: 2.1.2-10.1
Severity: normal
Tags: ipv6 upstream
X-Debbugs-Cc: [email protected]
Dear Maintainer,
* Software/OS info
Operating System: SolydXK 13 (Debian stable)
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Kernel Version: 7.1.8+deb13-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 18 × Intel® Core™ Ultra 5 250KF Plus
Memory: 32 GiB of RAM (31.1 GiB usable)
Graphics Processor: AMD Radeon Graphics
* What led up to the situation?
KDE Discover hangs at "Fetching updates" and eventually crashes when Proton VPN
with IPv6 enabled is connected. The problem is isolated to the kns-backend;
PackageKit and Flatpak backends work normally. IPv6 connections from
Discover/KIO to KDE Store remain stuck in SYN-SENT.
* What exactly did you do (or not do) that was effective (or
ineffective)?
With Proton VPN disconnected or Proton VPN enabled but with IPv6 disabled, KDE
Discover works normally.
With Proton VPN connected and IPv6 enabled, Discover hangs at "Fetching
updates" and eventually crashes. Testing individual backends shows that the
problem is specifically caused by kns-backend.
With the VPN connected:
plasma-discover --backends packagekit-backend,flatpak-backend
works normally, while:
plasma-discover --backends kns-backend
hangs.
The failing KNS initialization produces multiple messages such as:
invalid kns backend! "...knsrc" because: "Backend ... took too long to
initialize"
and eventually:
kf.newstuff.core: "Operation canceled"
qrc:/qt/qml/org/kde/discover/qml/DiscoverDrawer.qml:36:
TypeError: Cannot read property 'subcategories' of null
KCrash: Application 'plasma-discover' crashing...
Segmentation fault (core dumped)
Further investigation shows that, with the VPN connected and IPv6 enabled in
Proton:
curl -6 -I https://store.kde.org/
hangs.
ss -tpn shows Discover and its KIO HTTP worker attempting IPv6 HTTPS
connections that remain in SYN-SENT, for example:
SYN-SENT [2a07:b944::2:2]:37488 → [2a02:6ea0:c77a::48]:443 plasma-discover
SYN-SENT [2a07:b944::2:2]:50150 → [2a02:6ea0:c700::11]:443 kioworker
This suggests that KNS/KIO is unable to establish IPv6 connections while the
VPN is active.
* What was the outcome of this action?
Discover hangs while initializing the KNS backend / fetching updates. The KNS
backends eventually time out and Discover crashes.
With the VPN disconnected or IPv6 disabled, the same command works normally.
* What outcome did you expect instead?
KNS should initialize successfully, or gracefully fall back to IPv4 when IPv6
connectivity is unavailable. A failed IPv6 connection should not cause Discover
to hang indefinitely or crash.
* First reported here:
https://bugs.kde.org/show_bug.cgi?id=526022
-- System Information:
Debian Release: 13.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 7.1.8+deb13-amd64 (SMP w/18 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages discover depends on:
ii debconf [debconf-2.0] 1.5.91
ii libc6 2.41-12+deb13u4
ii libdiscover2 2.1.2-10.1
discover recommends no packages.
Versions of packages discover suggests:
ii sysvinit-utils [lsb-base] 3.14-4
-- debconf information excluded
