ID:
GSO_OKКатегория: Маршруты и сетевой стек Статус в RKNHardering 2.10.0: Нативный producer есть, но строка теряется при текущем разборе UI Роль в вердикте: Реестр/совместимость
Эта страница описывает фактическую реализацию RKNHardering 2.10.0. Здесь отдельно указано, что можно сделать без root, что требует root, а также где способ только уменьшает один сигнал, но не скрывает VPN целиком.
UDP_SEGMENT=1200 принят, затем sendto() 4800 bytes на loopback:53 возвращает успех. В native result kind не имеет detail, поэтому parser получает gso_ok только если строка сериализована с разделителем; текущий C++ добавляет именно gso_ok без |, а deep parseRow() требует kind и непустой detail после второго separator. После prefix это vdet|gso_ok, поэтому текущий Kotlin parser отбрасывает строку.
На C++ уровне — успешные setsockopt и sendto. На UI уровне версии 2.10.0 producer фактически не доходит до finding из-за формата без detail.
Если строка не отображается, это не означает GSO failure: это текущая несовместимость формата producer/parser. После исправления сигнал должен оставаться информационным.
Как строка влияет на отчёт: ID сохранён в каталоге и UI, однако текущая версия 2.10.0 не формирует отдельную положительную строку этого kind. Обычно рядом работает более конкретный сигнал.
Кроме parser gap, loopback GSO не измеряет VPN path и не подтверждает hardware offload. Сам success не является антидетектом.
Важно оценивать эту строку вместе с соседними сигналами. Один чистый API не перекрывает Java Binder, libc, raw netlink/syscall, procfs/sysfs, локальные сокеты и серверные признаки одновременно.
Ничего не меняйте ради отсутствующей UI-строки. Для разработки исправьте C++ на gso_ok|sent=4800 либо разрешите empty detail в parser и добавьте unit test.
Root не требуется и не должен использоваться. Не патчите kernel только для появления диагностической строки.
rg -n 'gso_ok|parseRow|indexOf' app/src/main/cpp/native_signs_probe.cpp app/src/main/java/com/notcvnt/rknhardering/checker/VpnNativeDetectorChecker.kt
После исправления запустите checker unit test и реальное устройство с поддержкой UDP_SEGMENT.
После любого изменения сделайте force-stop RKNHardering и VPN-клиента, запустите их заново и повторите полный scan. Для Zygisk/Xposed/kernel-модулей обычно нужна перезагрузка. Сравнивайте не только эту строку, но и соседние сигналы: частичный hook часто создаёт несогласованность между API.
Сама проба выполняется с обычными правами приложения и не запрашивает root. ADB-команды ниже служат только для ориентира: adb shell работает под другим UID и может видеть больше или меньше, чем процесс приложения. Решающий тест — повторный запуск самой проверки после force-stop.
Изменение parser влияет на все malformed deep rows; добавьте тест, чтобы не принимать пустые/повреждённые kinds без разбора.
Откатите только code change, если тесты/telemetry ухудшились. На устройстве постоянных изменений нет.
Реестр/совместимость. Проверено по C++ строке без separator/detail и Kotlin parseRow() с sep <= 0/blank rejection. ID остаётся каталогизированным.
Статус стороннего решения не переносится автоматически на это устройство. Заявление разработчика модуля — это исходная гипотеза; подтверждением служит повторяемый результат RKNHardering на конкретной версии Android, прошивки и ядра.
native_signs_probe.cpp — нативная реализация проб.VpnNativeDetectorChecker.kt — deep VPN verdict и confidence.NativeSignalCatalog.kt — категория, slug и mapping строк.NativeSignalId.kt — полный реестр ID.Связанные сигналы: gso-failed, gso-send-failed, general-diagnostics.