SUMMARY Kdeconnect on a desktop computer cannot send a file to other device STEPS TO REPRODUCE 1. Ensure the target device has receiving enabled for the sender 2. Open app capable of sharing a file via kdeconnect ( perhaps kdeconnect itself ) 3. Right click on a file and choose share or send to device 4. Choose the target device 5. Send OBSERVED RESULT The file does not arrive at the target device on the configured folder ( or any folder - no found ) There is no error reported EXPECTED RESULT The file should appear in the designated folder. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.15.9-201.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz Memory: 32 GiB of RAM (31.2 GiB usable) Graphics Processor: Intel® HD Graphics 530 Manufacturer: LENOVO Product Name: 10MLS0A400 System Version: ThinkCentre M910s ADDITIONAL INFORMATION Sending from a phone to another phone or to a computer works as expected. This is not a recent regression. I wa hoping a recent update would fix this. Side note - When configuring the destination file on a phone the default folder is Downloads. This folder not not exist generically ( well not on Pixels ). Either create the folder or customize the destination folder.
I have investigated further and it was only my main computer that couldn't send files to other devices using kde-connect. I monitored the system logs while attempting to send a file to another device. kdeconnectd[6174]: kdeconnect.core: CompositeUploadJob::startListening() - Error opening a port in range 1739 - 1764 I ran "ss --lnp" and found that there were already listeners on all the ports in that range. I killed kdeconnectd which then restarted. The ports were released and I was able to send files to other devices.
Created attachment 184952 [details] Busy ports Unable to send files via kdeconnect due to no ports available.
I see now that it was happening on another computer as well. It could still send files because it still had free ports but some were busy. The behaviour is inconsistent. The port is sometimes released after a transfer and sometimes not.
An actual file transfer is not required to busy a port. I can trigger the behaviour by simply clicking on "share file" in the kdeconnect desktop widget. Perhaps this is happening accidently during normal desktop activity.
Definitely happening accidently. If I clear all the ports and then repeatedly hover over the hambuger menu in the widget I can see the number of held ports grow.
I was wrong. It was a coimcidence that this was occurring while I hover the cursor over the widget. The number of held ports continues to grow without any user input happening. Some of it may be associated with notification processing in the widget.
Created attachment 185265 [details] Logs The attached logs show kdeconnect activity during a period in the early morning when there was no user activity.
After enabling debug logging I was able to see when a listening port was opened. kdeconnect.core: CompositeUploadJob::startListening() - listening on port: 1743 I found that sending a notification and sending a file both cause a listening port to be opened. This is the first network action for either sending a notification or a file. The sender and receiver had previously established an encrypted connection. One device intiated the connection to the other's port 1716. However from that point the two scenarios are very different. File transfer Sender sets up a listeing port ( 1739- 1764 ) Sender contacts the reciver over the previously established connection. Presumably informs the receiver of the sender's listening port. Receiver sends TLSv1.3 Hello package to the sender. using the senders listener port. Sender responds with Hello Receiver changes cipher spec. Sender sends several packages of data. Receivers responds with several TCP ACK and finally with FIN ACK. After checking with "ss -lnpt | grep kdeconnect" observed that the listening port had been removed. Send notification Sender creates a listening port. Sender sends two TLSv1.2 packets to the receiver over the previously established connection. The packet sniffer shows that the listening port is never used. ss -lnpt | grep kdeconnect reveals that the listener has not been removed. At some point file transfers and notification sending will start failing because all the ports 1739-1764 are in use.