https://bugs.kde.org/show_bug.cgi?id=502570
Bug ID: 502570
Summary: Background network activity completely stops if KDE
connect is running
Classification: Applications
Product: kdeconnect
Version: unspecified
Platform: Android
OS: Android 14.x
Status: REPORTED
Severity: grave
Priority: NOR
Component: android-application
Assignee: albertv...@gmail.com
Reporter: a.h.ismail....@gmail.com
CC: andrew.g.r.hol...@gmail.com
Target Milestone: ---
SUMMARY
If KDE Connect is running, the Android system apparently blocks any new TCP or
UDP connection but leaves existing ones connected (unsure, it seems some fail
while others stay). The problem disappears when KDE connect is stopped. I'm not
sure if this is a KDE connect fault or some misbehavior by Android 15, probably
a mix of both.
As a result, the device acts as if it was offline whenever the screen is off,
which is a major usability issue.
STEPS TO REPRODUCE
1. Have an Android 15 device
2. Start KDE connect
3. Turn off the display and try any online related activity like sending a
message to the locked phone
OBSERVED RESULT
No message is received, no matter how long you wait. When you power the
display, Android shows an '!' next to WiFi which returns to arrows in a few
seconds and networking works again.
EXPECTED RESULT
The network should always work, only limited by Android power saving features.
SOFTWARE/OS VERSIONS
KDE connect: 1.33.3
Android 15 (OneUI 7.0)
(I picked Android 14 in the report as it is the most recent in the menu, but
the issue is with Android 15)
ADDITIONAL INFORMATION
For easier reproducibility, you can try iperf3 running as a server on the
phone's terminal. Client is a laptop running Debian:
KDE connect disabled, screen off:
```
$ iperf3 -c 192.168.0.10 -u --connect-timeout 3000
Connecting to host 192.168.0.10, port 5201
[ 5] local 192.168.0.12 port 33368 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 1.00-2.00 sec 127 KBytes 1.04 Mbits/sec 91
[ 5] 2.00-3.00 sec 129 KBytes 1.05 Mbits/sec 90
[ 5] 3.00-4.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 90
[ 5] 5.00-6.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 6.00-7.00 sec 127 KBytes 1.04 Mbits/sec 90
[ 5] 7.00-8.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 90
[ 5] 9.00-10.00 sec 129 KBytes 1.05 Mbits/sec 91
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total
Datagrams
[ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/906 (0%)
sender
[ 5] 0.00-10.03 sec 969 KBytes 791 Kbits/sec 10.283 ms 221/906 (24%)
receiver
iperf Done.
```
KDE connect active, screen is on:
```
$ iperf3 -c 192.168.0.10 -u --connect-timeout 3000
Connecting to host 192.168.0.10, port 5201
[ 5] local 192.168.0.12 port 57485 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 1.00-2.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 2.00-3.00 sec 127 KBytes 1.04 Mbits/sec 90
[ 5] 3.00-4.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 90
[ 5] 5.00-6.00 sec 129 KBytes 1.06 Mbits/sec 91
[ 5] 6.00-7.00 sec 127 KBytes 1.04 Mbits/sec 90
[ 5] 7.00-8.00 sec 129 KBytes 1.05 Mbits/sec 91
[ 5] 8.00-9.00 sec 127 KBytes 1.04 Mbits/sec 90
[ 5] 9.00-10.00 sec 129 KBytes 1.05 Mbits/sec 91
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total
Datagrams
[ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/906 (0%)
sender
[ 5] 0.00-10.09 sec 1.23 MBytes 1.02 Mbits/sec 17.091 ms 13/906 (1.4%)
receiver
```
KDE connect active, screen off:
```
$ iperf3 -c 192.168.0.10 -u --connect-timeout 3000
iperf3: error - unable to connect to server - server may have stopped running
or use a different port, firewall issue, etc.: Connection timed out
```
It should be noted that a single iperf3 test runs normally if the test started
while the screen is on then switched off, but it would get stuck not declaring
results until the phone screen is turned on again (probably waiting to
establish another connection for signaling end with the server). Also, the
device remains connected to WiFi (screen off+KDE connect) and replies to ARP
ping normally, but refuses Transport layer connections in both directions.
--
You are receiving this mail because:
You are watching all bug changes.
