q 8d7721c775 B7: add network time bootstrap and persistent B7C cache

B7A: QMI DMS time vs VNIIFTRI NTP (DMS = UTC - 0.28 s, sigma 1 ms; NITZ = DMS
truncated to 1 s). B7B: a 1970 -> 2026 date -s step is harmless for the modem
stack. B7C: aurora-modem probes DMS/NITZ along the start flow and steps
CLOCK_REALTIME once at the first valid sample (REG registered/attached), never
RTC; background SNTP check (query only) after START OK. 3/3 class-A cold boots
PASS (residual +0.04/+0.36/+0.84 s), cache 14fe453a written (B7C_WRITE_VERIFIED)
and verified by a normal power-on (V1, +0.26 s).

Also publishes the prerequisite R2 (boot-hang / lk eMMC investigation, T4
telnet baseline that B7C builds on) and R3 (autonomous cold boot, NCM loss)
material, and extends tools/publish-sanitize.py to r2/, r3/, b7/.
Binary images, initramfs, busybox and raw logs stay out (see b7/*/SHA256SUMS).

2026-10-02 20:18:25 +03:00

3.1 KiB

Raw Permalink Blame History

R3B — temporary loss of USB-NCM host 172.16.42.2 in steady state: PASS

2026-10-02, same boot as R3A (class A, START OK at uptime 75 s). CH340 TX disconnected, UART passive. No UART input, no reboot, no manual action on the modem (only read-only telnet snapshots and a read-only observer in /run/r3b).

Fault injection (480s, NetworkManager)

Host time	Action
12:10:01–12:10:31	baseline 30 s
12:10:31.670	`nmcli con down uuid 34c357f3…` (aurora-ncm) → device disconnected, 172.16.42.2 gone
12:11:31.733	`nmcli con up uuid 34c357f3…` → connected 12:11:31.966
12:11:31.977	ping 172.16.42.1 OK on the first try
12:11:32–12:12:31	60 s observation, then post snapshot
NM did not reactivate aurora-ncm on its own during the 60 s outage (r3b-nm-monitor.txt).

Answers

usb0 ping lost was never logged. The board observer saw host=DOWN at uptime 856.8 (≈3 s after con down), but lifecycle.log stayed at 35 lines (pre/post identical). The check exists only inside start (reg_sm), and the controller has exited after START OK.
Nothing happened on the modem side: no state change (BEARER_CONNECTED throughout), no bearer teardown, no MM restart (pid 1655), no rmtfs restart (pid 1056), no aurora-modem process (am_procs=0), no MSS reset, no rollback. usb0 kept 172.16.42.1/24 and carrier=1.
After con up everything came back by itself: 172.16.42.2 present, ping 172.16.42.1 OK at once, telnet works (post snapshot). No new START OK, which is expected because the bearer never dropped.

Data

Board observer: 88 samples at ~2–3 s (uptime 813–990): 20 before, 19 during the outage, 49 after. LTE ping via wwan0 → 77.88.8.8 OK in 88/88; MM connected/lte/home, bearer1 connected=yes in all 18 mmcli samples; wwan0 10.41.212.24/28 unchanged.
Host ping 172.16.42.1: 93 OK → 20 lost (outage) → 114 OK.
Post snapshot: controller BEARER_CONNECTED, ping wwan0 77.88.8.8 3/3 and 1.1.1.1 3/3, DNS 10.10.22.3 OK, FAIL/rollback/lost 0, dmesg-errs 0, eMMC writes 0, dmesg has no new usb/ncm/wwan/remoteproc messages after boot (only r3b-obs lines).
Kmsg markers on passive UART: host=DOWN 12:10:34.4, host=up 12:11:33.3.

Notes

Secondary bearer DNS 194.186.191.1 timed out again (same as R3A); 10.10.22.3 works.
wwan0 operstate unknown is normal for this raw-IP p2p link (flags UP, LOWER_UP).
Not covered: NCM loss during start (uptime ≈9–23 s, reg_sm ping check). That path rolls back with a full stop and has no auto retry → R3B2, needs a separate GO.
Before the run, the board observer launch failed twice (busybox has no nohup, and the first mmcli call took > 6 s). Fixed by setsid + trap '' HUP + timeout 8 mmcli. No NCM injection happened in those attempts; their files are in aborted-1/.

Files

r3b-actions.txt, r3b-run.out, r3b-pre-snapshot.txt, r3b-post-snapshot.txt, r3b-board-obs.sh, r3b-board-obs.log, r3b-obs-start.txt, r3b-obs-fetch.txt, r3b-host-ping.txt, r3b-nm-monitor.txt, r3b-uart.log (copy of logs/uart/r3b-20261002-120858.log), r3b-uart-markers.txt; scripts r3/r3b/.

3.1 KiB Raw Permalink Blame History Unescape Escape