https://bugs.kde.org/show_bug.cgi?id=524483
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] OS|Linux |All --- Comment #2 from [email protected] --- I'm hitting exactly this on **Windows**, which suggests the bug is not Linux-specific. Same desktop log, same Android log, same indefinite hang. Desktop (`QT_LOGGING_RULES=kdeconnect.*=true`): kdeconnect.plugin.share: File transfer kdeconnect.core: FileTransferJob Downloading payload to QUrl("file:///C:/Users/<user>/Downloads/test_from_phone.txt") size: 19 Android: I SharePlugin: Intent contains files to share I KDE/LanLink: Using port 1739 E LanLink : Socket for payload in packet kdeconnect.share.request timed out. The other end didn't fetch the payload. **One data point that may help narrow it down: no TCP SYN is ever emitted.** I polled `netstat -ano` every 2 seconds across the whole 10-second window and there is **no connection to port 1739 in any state**, not even `SYN_SENT`. So `socket->connectToHostEncrypted(address, port, QIODevice::ReadWrite)` in `LanDeviceLink::dataReceived()` (`core/backends/lan/landevicelink.cpp:147`) seems to fail silently — no packet on the wire, no error surfaced. That would explain the indefinite hang rather than a timeout: in `FileTransferJob::doStart()` (`core/filetransferjob.cpp:77-81`) the socket never becomes readable, so `readyRead` never fires and `startTransfer()` is never reached. Note the desktop clearly *does* receive and parse the packet — the filename is correct and `size: 19` matches my 19-byte test file exactly, and `payloadTransferInfo` must be non-empty for that code path to run at all. **The phone side is demonstrably fine.** While a transfer was pending, I connected to port 1739 manually using the desktop's own `certificate.pem`/`privateKey.pem`, with exactly the verification kdeconnectd applies (`setPeerVerifyMode(VerifyPeer)` + `setPeerVerifyName(deviceId)`): ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT) ctx.load_verify_locations('phone_cert.pem') ctx.verify_mode = ssl.CERT_REQUIRED ctx.check_hostname = True ctx.load_cert_chain('certificate.pem', 'privateKey.pem') s = socket.create_connection(('<phone-ip>', 1739), timeout= w = ctx.wrap_socket(s, server_hostname='<deviceId>') print(w.recv(200)) # -> b'hello from android\n' It returned the payload on the first attempt. The payload servethe CN check are all working — everything kdeconnectd needs isin place, it just never opens the connection. **Also ruled out here:** - Network/firewall: had the phone listen on an unrelated port (19999) and connected to it from the desktop successfully; inbound desktop→phone connections are fine. - Pairing/certificates: fully unpaired, removed stale device directories, re-paired. deviceId, trusted_devices key and certificate CN all match. - Destination directory: tried the default Downloads folder andlves correctly either way. (And the connection is initiated in`dataReceived()` before SharePlugin runs, so it can't be the cause.) - Payload size: 19-byte file, far below `MAX_PACKET_SIZE`. **Direction matrix** — only one cell fails: | Direction | Type | Result | |---|---|---| | Phone → Desktop | plain text (no payload) | works | | Desktop → Phone | file | works | | Phone → Phone | file | works | | **Phone → Desktop** | **file (payload)** | **fails** | The working desktop→phone direction uses `UploadJob` with a listening `QTcpServer` instead of an outbound `connectToHostEncrypted()`, consistent with the failure being specific to initiating the outbound TLS connectio **Possibly relevant:** the original report and my setup both ru operating systems and different distributions/builds. Giventhat `landevicelink.cpp` and `filetransferjob.cpp` have had no functional changes since this was filed, a Qt-side regression in `QSslSocket::connectToHostEncrypted()` might be worth ruling oursion handy to test against. **My versions:** - Windows 10.0.26200 - KDE Connect desktop built 2026-09-12, Qt 6.11.1 - KDE Connect Android 1.35.16, protocol version 8 - Android 12 (MuMu emulator in bridged mode, same /23 LAN as the desktop, reachable normally — verified with the port 19999 test above) -- You are receiving this mail because: You are watching all bug changes.
