Bug 446238

Summary: UDP broadcast to port 1716 is oversized due to featureitis. the UDP payload size is 1900, the ethernet MTU is 1500
Product: [Applications] kdeconnect Reporter: Riegler Bernhard <riegler.b>
Component: android-applicationAssignee: Albert Vaca Cintora <albertvaka>
Status: CONFIRMED ---    
Severity: normal CC: coot, kaos.ocs, nebras30
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Android   
OS: Android 11.x   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: pcap file

Description Riegler Bernhard 2021-11-29 13:11:53 UTC 
SUMMARY
***
tracing the ethernet frames with wireshark on Ubuntu 20.04 LTS shows UDP broadcast to port 1716 with a payload size of about 1900.
I have a PF (personal firewall) in Ubuntu (native Linux subsystem nftables) with a "stateless config"
all ethernet frames not having either TCP or UDP header is dropped for security.
the UDP broadcast to port 1716 gets split into two IPv4 fragments (payload is above MTU=1500).
my PF is dropping IPv4 fragments.
It seems that adding features has brought the payload size above MTU=1500. (my assumption)
think about IoT with small HW and a limited IPv4 code (without IPv4 fragments, without IPv4 options)
UDP must be simple. e.g. UDP DNS limits the 512 Bytes payload. IPv4 hat only a size of 576 Bytes.
***


STEPS TO REPRODUCE
1. I use wireshark, just trace on the ethernet wire or WLAN and check the UDP broadcast to UDP port 1716 
2. 
3. 

OBSERVED RESULT
you see two IPv4 fragments, the first has the UDP header, the second not

EXPECTED RESULT
there needs to be a major rethinking of the "feature broadcast" to stay inside the limits of the infrastructure.
the MTU=1500 - 20Bytes IPv4 - 8Bytes UDP needs a hard limit of 1472 Bytes for the feature broadcast.
All OS platforms needs to adapt to a version2 of the "feature broadcast"

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Marcin Szamotulski 2022-03-14 11:33:43 UTC 
Created attachment 147491 [details]
pcap file

The bug can be observed in the attached pcap file.  Protocol content is truncated at the 1500 bytes, which is standard MTU size on many systems.
Comment 2 Marcin Szamotulski 2022-03-14 11:35:08 UTC 
Comment on attachment 147491 [details]
pcap file

The attachment shows the problem, the protocol data is truncated at 1500 bytes (common MTU size).
Comment 3 benoit 2022-06-05 19:22:03 UTC 
*** Bug 419617 has been marked as a duplicate of this bug. ***
Comment 4 Riegler Bernhard 2022-06-06 07:36:25 UTC 
just my thoughts for a fix.
the UDP payload is "XML hypertext"
bring this hypertext into a dictionary of limited words and index this word-list
just transmit on the LAN the index of the features. this should give a UDP payload below the UDP limit of 1472 Bytes.
no more IPv4 fragments after this version2 of the "feature broadcast".
Comment 5 nebrassy 2025-10-16 20:35:19 UTC 
This is still an issue, especially on enterprise networks which limit udp packets a lot more

The solution is very simple, the initial discovery packet is too large because kdeconnect sends all incomingcapabilities and outgoingcapabilities in it, which is unnecessary, I've created a simple code to intercept and modify the packet just removing everything in incomingcapabilities and outgoingcapabilities and everything works fine.
Comment 6 Albert Vaca Cintora 2025-10-18 23:14:01 UTC 
This is solved with protocol version 8, but we still send the extra info in the UDP packet for backwards compatibility with protocol version 7. When we drop support for that, we can shrink the UDP packets down.