ID:
UDP_PMTU_OKCategory: Routes and network stack Status in RKNHardering 2.10.0: Active check Role in the verdict: Low
This page describes the actual implementation in RKNHardering 2.10.0. It distinguishes what can be done without root, what requires root, and where a mitigation only reduces one signal without hiding the VPN as a whole.
The probe creates a UDP socket and performs one sendto() call with a 1500-byte buffer to loopback DNS port 53. If the return value is greater than 0, it emits udp_pmtu_ok; no receiver or listener is required. The line is low-confidence informational data.
The kernel accepted a local 1500-byte UDP datagram on the send path.
Success shows only that the loopback send path accepted the datagram. It does not measure the external route PMTU, fragmentation, or delivery to a DNS service.
How the line affects the report: The line is informational or diagnostic. It is useful for comparing runs, but does not by itself prove the presence of a VPN or tampering.
The loopback MTU is normally far higher than the physical MTU. A successful UDP send does not confirm delivery. The PMTU label overstates the informational value.
This line must be evaluated together with neighboring signals. A clean result from a single API does not simultaneously cover Java Binder, libc, raw netlink/syscalls, procfs/sysfs, local sockets, and server-side indicators.
For a diagnostic signal, do not try to “fix” anything at first. Record a baseline on the same device without the VPN, then repeat the test with the VPN under the same network, temperature, and load conditions. Only a reproducible difference between the two series is useful for analysis. A single MTU, timing, or GSO value is not evidence.
A root module can alter this indicator, but tuning it to a particular number can easily disrupt TCP/UDP, DNS, calls, or power consumption. VPNHide Next claims to filter several indirect parameters, but those capabilities must be tested separately from basic interface hiding. Do not enable the maximum set of kernel hooks before obtaining a clean baseline and a working rollback procedure. Do not block loopback UDP/53 merely to change the result: that creates udp-pmtu-fail and may disrupt local DNS.
adb shell ip link show lo
adb shell 'cat /sys/class/net/lo/mtu 2>/dev/null'
On a normal kernel, expect the send to succeed regardless of whether a listener exists.
After any change, force-stop both RKNHardering and the VPN client, start them again, and repeat the full scan. Zygisk, Xposed, and kernel modules usually require a reboot. Compare not only this line but also neighboring signals: a partial hook often creates inconsistencies between APIs.
The probe itself runs with ordinary app permissions and does not request root. The ADB commands below are for orientation only: adb shell runs under a different UID and may see either more or less than the app process. The decisive test is to run the check again after a force-stop.
Firewall or SELinux experiments involving loopback DNS may break name resolution for apps.
Remove the temporary loopback or firewall rule and restart netd, the VPN, or the device.
Low. Verified from the fixed 1500-byte loopback send; informational.
The status of a third-party solution does not automatically carry over to this device. A module developer’s claim is only the initial hypothesis; confirmation requires a reproducible RKNHardering result on the specific Android version, firmware, and kernel.
native_signs_probe.cpp — native probe implementation.VpnNativeDetectorChecker.kt — deep VPN verdict and confidence.NativeSignalId.kt — complete ID registry.NativeSignalCatalog.kt — category, slug, and line mapping.Related signals: udp-pmtu-fail, normal-pmtu, backpressure.