Bug 446963

Summary:	KDEconnect v1.18 on Android12: TCP connection to server port 1716 violates TCP rules for segment size and termination sequence
Product:	[Applications] kdeconnect	Reporter:	Riegler Bernhard <riegler.b>
Component:	android-application	Assignee:	Albert Vaca Cintora <albertvaka>
Status:	REPORTED ---
Severity:	normal	CC:	valdikss
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Android
OS:	Android 11.x
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Riegler Bernhard 2021-12-14 09:15:05 UTC

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

Comment 1 valdikss 2022-09-15 14:06:05 UTC

>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?

Comment 2 Riegler Bernhard 2022-09-15 16:05:36 UTC

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.