https://bugs.kde.org/show_bug.cgi?id=508301
--- Comment #8 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
