Measure a parent-switch recovery window

Steps

Screens captured against Contiki-NG Cooja Contiki-NG release/v4.9 c20b12cd, Cooja 4.8 (2022071901), Temurin 17.0.20.1, image sha256:b14d5afb0a2a852d9e72bbed607ead03f6ccc5f4d4dee44f0799110be2f4b609 on 2026-09-10; the tool may have moved on — the text steps are the contract.

1. 1 Step 1

   Do

   Open the CSC. The GUI pauses at about 89 s. Trace target mote 5’s current arrows toward root 1.

   You will see

   Before the fault, target 5 uses parent 3, then root 1.

   Why it matters

   Keep a before-state record; a final successful path alone cannot establish what changed or how long recovery took.

2. 2 Step 2

   Do

   At the first pause, filter Mote output for ^-- Preferred parent|^-- Rank:. Record the baseline snapshot.

   You will see

   At 85.065 s, target 5 reports parent fe80::203:3:3:3 and Rank 422.

   Why it matters

   The baseline names the actual parent and metric state before the ScriptRunner chooses which relay to remove.

3. 3 Step 3

   Do

   Click Start/Pause once and let the GUI reach its second pause near 150 s. Inspect target 5 in Network.

   You will see

   The script moves the actual preferred relay 3 to (300,300) at 90.065 s. Target 5 now reaches the root through relay 2. Relay 3 is outside the shown viewport.

   Why it matters

   The intervention removes a real radio path. The new arrow is a real default-route annotation, not a drawn replacement.

4. 4 Step 4

   Do

   At the second pause, use the parent/Rank filter again and compare both snapshots. Read the change timestamp in expected-output.txt.

   You will see

   The 140.065 s snapshot reports parent 2 and Rank 420. The first new-parent annotation occurs at 100.760728 s, 10.695728 s after removal.

   Why it matters

   Route-state recovery and packet recovery are different events. Record both rather than calling the whole interval instantaneous convergence.

5. 5 Step 5

   Do

   Filter for Received ping reply. Check the root-initiated test after the parent change.

   You will see

   The root receives a reply from target 5 with ttl 63 and delay 71 ms. During the fault window, the log records 12 target requests sent, 10 received, and 10 replies received by the target.

   Why it matters

   The first recovered uplink appears at 110.644856 s and reply at 110.711112 s. Those bound application recovery later than the parent change.

6. 6 Step 6

   Do

   Click Start/Pause again. The relay returns at 210.065 s; the run stops at 300 s. Reapply the parent/Rank filter.

   You will see

   At 260.065 s, target 5 still prefers relay 2, with Rank 395. It does not return to relay 3 during this observation window.

   Why it matters

   Restoring physical reachability does not force the original parent back. Retention, link freshness and hysteresis must be observed, not assumed.

7. 7 Step 7

   Do

   Filter for Received ping reply and check the second reply. Complete the README forwarding worksheet and six-part recovery record.

   You will see

   The final root-to-target ping has ttl 63 and delay 101 ms. The script passes only after a parent change, repeated target uplink/reply successes, and both downward pings.

   Why it matters

   Accept the tested target path with its loss window and limits. Nodes 3 and 6 do not have active parent annotations at the end; this is not proof that the entire mesh recovered.