Files
utun2/tests/stream_netns/TESTED.md
T

65 lines
8.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Проверки 2026-10-11
Дополнение 2026-10-12: резервный STUN по IP/netif.
`python3 tests/stream_netns/run.py --stun-only --output /tmp/stun-interface-netns-01` — PASS.
Настоящие RFC5780-серверы, отдельный тестовый порт и две рабочие подписанные записи одного IP/netif:
n03 STUN EIM/OPEN -> ETCP EIM/OPEN;
n14 STUN EIM/CONTACT_REQUIRED -> ETCP EIM/CONTACT_REQUIRED;
n05 STUN DEPENDENT/CONTACT_REQUIRED -> ETCP DEPENDENT/UNKNOWN.
Без пиров и с одним наблюдателем выбирается STUN; независимый помощник позволяет выбрать ETCP.
Mapped порт пробы не рекламируется для рабочего сокета. Главный namespace не изменён;
`/tmp/stun-interface-netns-01/host-check.json`, `stun-result.json`, `result.json`.
Финальные проверки после исправления порядка остановки и сохранения истории портов при reload:
`make -C tests check -j4` — 145 passed, 0 failed, 0 skipped (`/tmp/stun-fallback-final-check.log`).
В отдельной ASAN-сборке `test_stun_nat`, `test_nat_detection`, `test_route_ping`
прошли с `detect_leaks=1:halt_on_error=1`: ошибок памяти/утечек нет
(`/tmp/stun-fallback-asan-test_stun_nat.log`, `/tmp/stun-fallback-asan-test_nat_detection.log`,
`/tmp/stun-fallback-asan-test_route_ping.log`). Проверены группировка, TTL/refresh,
удаление представителя, reload, подпись/SQLite source, приоритет частичного ETCP и cleanup.
Пять проверок изоляции прошли. IPv6 STUN остаётся отдельным этапом.
Стенд: 16 процессов uTun, 10 NAT-клиентов, 3 страны. Основной network namespace не изменился во всех перечисленных запусках.
Результаты прежних стриминговых прогонов ниже подтверждали сетевые правила шлюзов
и доставку данных. Они не проверяли правильность классификации NAT внутри uTun.
Новая проверка владельца endpoint: `--nat-only --tcp`, артефакты
`/tmp/nat-owner-netns-02/nat-result.json`. Проверены все 16 UDP-профилей и 16 TCP-профилей:
6 UNCHANGED/OPEN, 4 EIM/OPEN, 2 EIM/CONTACT_REQUIRED, 4 DEPENDENT/UNKNOWN;
TCP: 6 публичных OPEN, 10 UNKNOWN/no_listener. Точные внешние адреса совпали с ожидаемыми.
Полная проверка с новым детектором:
`python3 tests/stream_netns/run.py --nat-check --publisher n05 --tcp --duration 75 --rate 2000000 --faults --fault-duration 15 --output /tmp/nat-owner-stream-integration-02`.
PASS: сначала все 16 UDP/TCP-профилей, затем реальные JOIN/Merkle/BGP, 4041 пачка,
перегрузка WAN, recovery, две отписки и END у оставшихся 13 подписчиков.
Ошибок payload/checksum/порядка нет, GAP полностью учитывается. Главный namespace неизменён.
`make -C tests check -j4`: 144 passed, 0 failed, 0 skipped (`/tmp/nat-owner-regressions-02.log`).
В отдельной копии исходников собраны ядро и целевые `test_nat_detection` / `test_route_ping`
с одинаковыми ASAN-флагами. Оба теста прошли с `ASAN_OPTIONS=detect_leaks=1:halt_on_error=1`;
ошибок памяти и утечек нет (`/tmp/nat-owner-asan-detector.log`, `/tmp/nat-owner-asan-route.log`).
Калибровка дополнена переходом «незапрошенный вход → исходящий контакт → вход».
`/tmp/nat-owner-calibration-before-guard` воспроизвёл блокировку последующего UDP
для restricted NAT даже без uTun. После фильтрации запрещённого входа до conntrack
`/tmp/nat-owner-calibration-after-guard` прошёл. Главный namespace не изменился.
| Сценарий | Команда из корня репозитория | Результат |
| --- | --- | --- |
| Публичный UDP-источник, длинный прогон и перегрузка | `python3 tests/stream_netns/run.py --duration 120 --rate 2000000 --faults --output /tmp/stream-netns-final-01` | PASS: 5996 пачек, 3 оборота timestamp, вытеснение из кольца, WAN recovery, unsubscribe, END |
| Источник за строгим NAT, только TCP | `python3 tests/stream_netns/run.py --publisher n05 --tcp-only --duration 20 --output /tmp/stream-netns-tcp-only-fixed-01` | PASS: 608 пачек, END у всех 15 получателей; после исправления раннего END |
| Источник за строгим NAT, чистые mappings/conntrack, UDP+TCP | `python3 tests/stream_netns/run.py --publisher n05 --tcp --duration 75 --rate 2000000 --faults --fault-duration 15 --output /tmp/stream-netns-clean-nat-fixed-01` | PASS: 4172 пачки, 2 оборота timestamp, 946 вытесненных пачек у источника; после обоих исправлений |
В последнем запуске median LAN RTT: A=2,64 мс, B=2,72 мс, C=2,54 мс; WAN A–B=51,79 мс, A–C=100,85 мс, B–C=150,31 мс. Все 10 NAT-профилей прошли отдельную проверку. После калибровки создана новая сеть без ее conntrack/mappings.
У источника в последнем запуске сохранено 33 550 400 байт подписанных блоков при capacity 33 554 300 байт (в пределах 32 MiB). Все оставшиеся после unsubscribe 13 получателей дошли до cursor=4172 и получили подписанный END. Ошибок checksum/порядка/повторной DATA нет. GAP и увеличенные задержки при перегрузке отражены в `summary.csv` и `samples.jsonl`; PASS не означает доставку без пропусков.
Обнаружены и исправлены два дефекта:
1. END первого поставщика выключал оптимизатор до дочитывания неполной FEC-пачки. Проверка до исправления: `/tmp/stream-netns-early-end-before-02.log`; после: `/tmp/stream-netns-early-end-after.log`.
2. Restart через отстающего поставщика повторно выдавал DATA той же эпохи. Прогон `/tmp/stream-netns-clean-nat-01` зафиксировал seq=2864 при ожидаемом 2865 с верным checksum. Исправление сохраняет уже выданный cursor и отложенный GAP; регрессии: `/tmp/stream-netns-restart-before.log` и `/tmp/stream-netns-restart-after-02.log`.
После последнего исправления `make -C tests check -j4`: **144 passed, 0 failed, 0 skipped** (`/tmp/stream-netns-final-unit-check.log`). `test_stream_service` включает ранний END, старый bootstrap после restart, два restart до GAP и проверку отсутствия оставшихся отслеживаемых аллокаций. Пять проверок изоляции `test_isolation.py` прошли; C-агент проверен с `-Wall -Wextra -Wformat=2` без предупреждений.
Файлы `/tmp` — результаты конкретных запусков; при очистке системы они могут быть удалены. Команды выше позволяют воспроизвести сценарии с новым каталогом `--output`; распределение потерь и расписание процессов могут менять количество GAP и задержки.