SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. start a fresh wireshark measurement on LAN where the TCPconnection flows. 2. control on Ubuntu20.04LTS platform with GSconnect. turn on server process for TCPport 1716 3. monitor the wireshark measurement and wait for the idle "TCP keep-alive", now turn off the server process TCPport 1716 OBSERVED RESULT there is a direct UDP datagram from server to client with the UDPsize bug 446238 already reported for UDP broadcast. (this accounts to the Ubuntu side, GSconnect) next is a TCPconnection started from Android12 KDEconnect_v1.18, both sides report in the SYN segment TCP MSS=1460 next is a TCP violation sending a TCP payload of 1860 bytes. the data pattern seems to be the same as in UDP broadcast reported in bug 446238. this is a size bug in TCP knowing the MSS=1460 value. next is setup off TLS payload. turning off the server process on Ubuntu GSconnect results in following TCP activity on this TCP connection. TLS closes connection (Ubuntu sends an TLS Alert) TCP closes connection with FIN,ACK flags (sender is Ubuntu) Android12 KDEconnect sends just an ACK back. here is the second TCP bug. Android12 KDEconnect should send a) "graceful TCP termination" with FIN,ACK or at least b) rough TCP RESET for the TCPconnection. the Ubuntu side TCP state machine is stuck in TCPstate FIN_WAIT_2 EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
>next is a TCPconnection started from Android12 KDEconnect_v1.18, both sides report in the SYN segment TCP MSS=1460 >next is a TCP violation sending a TCP payload of 1860 bytes. This should not be possible. Wireshark has protocol reassembling enabled by default, as well as the network card driver could use Generic Receive Offload. Are you sure of your observations? Care to provide .pcaps?
you are correct. I was tricked by looking at the data content in wireshark, which is the same as UDP just before. the TCP segments are correct just after the 3-way handshake. (MSS=1460) I cannot tell if the wireshark config was wrong or the TCP-offloading to HW was switched on (LRO) but the TCP finish behaviour is still valid. the android side (KDEconnect) send TCP ACK flag, but no FIN or RST flag.