SUMMARY Unable to send files to other devices using KDE Connect STEPS TO REPRODUCE 1. Send file with KDE Connect (plasmoid, context menu and cli tested) OBSERVED RESULT - File does not get sent to the device. - No output with GUI methods. CLI specifies that the file was shared: `Shared file://<file path>` EXPECTED RESULT - File should have appeared in the destination device's configured share folder SOFTWARE/OS VERSIONS (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION Error in journalctl: `kdeconnect.core: CompositeUploadJob::startListening() - Error opening a port in range 1739 - 1764` All the ports in this range are already in use by kdeconnect for other uses: ``` PORT NODE NAME 1739 TCP *:webaccess (LISTEN) 1740 TCP *:encore (LISTEN) 1741 TCP *:cisco-net-mgmt (LISTEN) 1742 TCP *:3Com-nsd (LISTEN) 1743 TCP *:cinegrfx-lm (LISTEN) 1744 TCP *:ncpm-ft (LISTEN) 1745 TCP *:remote-winsock (LISTEN) 1746 TCP *:ftrapid-1 (LISTEN) 1747 TCP *:ftrapid-2 (LISTEN) 1748 TCP *:oracle-em1 (LISTEN) 1749 TCP *:aspen-services (LISTEN) 1750 TCP *:sslp (LISTEN) 1751 TCP *:swiftnet (LISTEN) 1752 TCP *:lofr-lm (LISTEN) 1753 TCP *:predatar-comms (LISTEN) 1754 TCP *:oracle-em2 (LISTEN) 1755 TCP *:ms-streaming (LISTEN) 1756 TCP *:capfast-lmd (LISTEN) 1757 TCP *:cnhrp (LISTEN) 1758 TCP *:tftp-mcast (LISTEN) 1759 TCP *:spss-lm (LISTEN) 1760 TCP *:www-ldap-gw (LISTEN) 1761 TCP *:cft-0 (LISTEN) 1762 TCP *:cft-1 (LISTEN) 1763 TCP *:cft-2 (LISTEN) 1764 TCP *:cft-3 (LISTEN) ```
Update: Disabling a bunch of the services in the preferences config fixed this. I need to do further testing to make sure but it might just be that there's too many services it is trying to run and because sending a file needs a new port opened at the time of sending it, it runs out. I'll leave it to the devs or anyone else to close the thread if they feel this doesn't need any action. It's still technically an issue and isn't a "fix". Hopefully this leaves enough paper trail for the next person so they know to disable all the unnecessary features.
(In reply to Anish Murthy from comment #1) > Update: Disabling a bunch of the services in the preferences config fixed > this. I need to do further testing to make sure but it might just be that > there's too many services it is trying to run and because sending a file > needs a new port opened at the time of sending it, it runs out. I'll leave > it to the devs or anyone else to close the thread if they feel this doesn't > need any action. > > It's still technically an issue and isn't a "fix". Hopefully this leaves > enough paper trail for the next person so they know to disable all the > unnecessary features. Edit: This is not correct. This did nothing. The file transfer worked because I restarted the PC and these services did not yet start again. I did not do anything that would have triggered all of these services to start from my knowledge. I only used it to transfer some zip files, and notifications from my phone.
The protocols listed in your log are not actually related to KDE Connect, so the output there is a bit misleading. For example, `tftp-mcast` just happens to be associated with port 1758, which is in the 1739-1764 range used by KDE Connect. The fact that these ports are in LISTEN indicates the local device is waiting for a remote device to accept a file transfer. I would expect these to timeout eventually, but it's also curious that the remote device isn't connecting at all. I assume that at least one file transfer works? If not, this probably a firewall or network configuration problem. If not, you might need to collect debug logs from the other device (presumably Android).
Created attachment 184636 [details] Output of lsof command for relevant ports
(In reply to Andy Holmes from comment #3) > The protocols listed in your log are not actually related to KDE Connect, so > the output there is a bit misleading. For example, `tftp-mcast` just happens > to be associated with port 1758, which is in the 1739-1764 range used by KDE > Connect. > > The fact that these ports are in LISTEN indicates the local device is > waiting for a remote device to accept a file transfer. I would expect these > to timeout eventually, but it's also curious that the remote device isn't > connecting at all. > > I assume that at least one file transfer works? If not, this probably a > firewall or network configuration problem. If not, you might need to collect > debug logs from the other device (presumably Android). I am able to send files when the device first starts and all these protocols haven't started listening yet. When I run psof, I see that they're all listed as from the command `kdeconnec` with the same process number. I'm unsure of how much I'm supposed to hide, but I've attached a screenshot. Let me know if I need to add any other info.
(In reply to Anish Murthy from comment #5) > (In reply to Andy Holmes from comment #3) > > The protocols listed in your log are not actually related to KDE Connect, so > > the output there is a bit misleading. For example, `tftp-mcast` just happens > > to be associated with port 1758, which is in the 1739-1764 range used by KDE > > Connect. > > > > The fact that these ports are in LISTEN indicates the local device is > > waiting for a remote device to accept a file transfer. I would expect these > > to timeout eventually, but it's also curious that the remote device isn't > > connecting at all. > > > > I assume that at least one file transfer works? If not, this probably a > > firewall or network configuration problem. If not, you might need to collect > > debug logs from the other device (presumably Android). > > I am able to send files when the device first starts and all these protocols > haven't started listening yet. > When I run psof, I see that they're all listed as from the command > `kdeconnec` with the same process number. I'm unsure of how much I'm > supposed to hide, but I've attached a screenshot. Let me know if I need to > add any other info. The command was `sudo lsof -i :1739-1764`. I miswrote psof in the last comment.
(In reply to Anish Murthy from comment #5) > > I am able to send files when the device first starts and all these protocols > haven't started listening yet. > When I run psof, I see that they're all listed as from the command > `kdeconnec` with the same process number. I'm unsure of how much I'm > supposed to hide, but I've attached a screenshot. Let me know if I need to > add any other info. You'll probably need to get logs from the other device. The information from `lsof` tells you KDE Connect is opening all ports for uploads, but not why the other side is not attempting to connect to any of them.