Bug 514470 - KDE Connect does not automatically rediscover peers after waking from s2idle (modern standby) until manual user interaction
Summary: KDE Connect does not automatically rediscover peers after waking from s2idle ...
Status: REPORTED
Alias: None
Product: kdeconnect
Classification: Applications
Component: desktop-application (other bugs)
Version First Reported In: 23.08.5
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Albert Vaca Cintora
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-11 21:29 UTC by cptia2
Modified: 2026-01-22 09:47 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cptia2 2026-01-11 21:29:31 UTC
Description

After resuming from suspend using s2idle (modern standby), KDE Connect does not automatically rediscover peer devices on the local network.
The devices become visible again only after manual user interaction, such as:
- opening KDE Connect settings,
- triggering a refresh,
- a trigger on a neighbor kdeconnect app doesn't have any effect.
This behavior did not occur before enabling aggressive power optimizations, and does not occur after a cold boot.

Expected behavior

After resuming from suspend (s2idle), KDE Connect should automatically:
- restart its discovery mechanism,
- re-advertise the device,
- rediscover peers without any manual action.

Actual behavior

- After resume from s2idle: KDE Connect daemon is running / Network is up / Firewall allows traffic
- No passive discovery occurs
- Devices remain invisible indefinitely
- Discovery resumes only after manual UI interaction


Steps to reproduce

1 Boot system normally
2 Verify KDE Connect devices are visible
3 Suspend system: "systemctl suspend"
4 Wake system from s2idle
5 Wait 1–5 minutes
➡️ Result: devices are not rediscovered
➡️ Workaround: open KDE Connect settings or trigger refresh

Tests already performed
✅ NetworkManager reconnects properly
✅ Wi-Fi is active and stable
✅ No wake source issue
✅ Firewall unchanged
✅ Issue reproducible across reboots
❌ systemd system-sleep scripts ineffective
❌ Autostart scripts ineffective
❌ system-level resume hooks ineffective

Conclusion:
➡️ Discovery does not restart automatically at the user-session level
Comment 1 cptia2 2026-01-11 21:31:10 UTC
Operating System: Kubuntu 24.04
KDE Plasma Version: 5.27.12
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.13
Kernel Version: 6.14.0-37-generic (64-bit)
Graphics Platform: X11
Processors: 8 × AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx
Memory: 12.6 Gio of RAM
Graphics Processor: AMD Radeon Vega Mobile Gfx
Manufacturer: GMKtec
Product Name: NucBox_G10
Comment 2 rutger 2026-01-22 09:47:51 UTC
I'm experiencing the same issue on openSUSE Tumbleweed Slowroll with KDE Connect 25.12.0.
Lenovo P16s

Symptoms:
* After wake from sleep, devices are not rediscovered automatically
* Discovery is broken in both directions (laptop can't find phone, phone can't find laptop) 
* Manual refresh (kdeconnect-cli --refresh) does not help
* However, a simple ICMP ping to the phone's IP address immediately restores the connection

Workaround:
Created a system sleep hook that pings the paired device on resume:                                                
                                                                                                                   
[/usr/lib/systemd/system-sleep/kdeconnect-wake.sh] (permissions!)
#!/bin/bash                                                                                                        
if [ "$1" = "post" ]; then                                                                                         
    sleep 3                                                                                                        
    sudo -u $USER ping -c 1 <PHONE_IP>                                                                             
fi                                                                                                                 

This suggests the issue may be related to how the UDP broadcast discovery is (not) reinitiated after resume, rather than general network connectivity.