docs: the second DHCPv6 responder (CAMPAIGN-LOG, BRINGUP item 21)

The missing GUA was not the firewall: its DHCPv6 server advertises an
address, but an access point on the bench VLAN still runs RA and DHCPv6
in server mode, its Advertise with nothing to give arrives first, and
busybox udhcpc6 keeps the first Advertise it sees. Dev 20260824201945
carries patch 0015 and the last stray dmesg line is gone.

Docs only; no catalog consequence.

docs/BRINGUP.md

@@ -1555,13 +1555,16 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
     Bench-validated on dev 20260824200726 (CAMPAIGN-LOG 2026-08-24, second
     round): the three lines are gone, the kernel is UP at 996 MHz on the
     performance governor, Wi-Fi is up on the two-file firmware set, every
-    port answers over IPv6 on the board's ULA, the export runs. Two things
-    remain from it: the DHCPv6 server answers NoAddrsAvail and the GUA
-    prefix is not autonomous, so the board holds no GUA until the network
-    side hands one out (the client is running and asking); and with no NVS
-    on the rootfs the firmware loader logs the missing file at ERR level,
-    which patch 0015 (wlcore asks for the optional file the quiet way)
-    removes on the next build. Then the item-16 drill and the campaign.
+    port answers over IPv6 on the board's ULA, the export runs. Dev
+    20260824201945 adds patch 0015 (wlcore asks for its optional NVS the
+    quiet way) and the last stray dmesg line is gone. The missing GUA is a
+    network matter, diagnosed (CAMPAIGN-LOG 2026-08-24, "the second DHCPv6
+    responder"): the firewall advertises an address, but an access point on
+    the bench VLAN still runs its own RA and DHCPv6 server, its Advertise
+    arrives first with nothing to give, and busybox's `udhcpc6` stays with
+    the first Advertise it sees. Disabling RA and DHCPv6 on that access
+    point (as on the other two) is the fix; nothing on the board changes.
+    Then the item-16 drill and the campaign.
 
 **Deliberately not gated:** an armed GRBL job after an underrun cuts at the
 stale origin unless homing is required (GRBL mode permits unhomed cutting; the

docs/CAMPAIGN-LOG.md

@@ -3852,6 +3852,26 @@ when records exist, and after the cold boot there were none. Memory
 Owed: the NVS line (patch 0015, next build), the item-16 drill on this
 kernel, the campaign. Bench left clean.
 
+## 2026-08-24: the second DHCPv6 responder
+
+Dev 20260824201945 (patch 0015 in): the NVS loader line is gone; the
+rest of the second round holds. The missing GUA was not the firewall's
+doing. Its DHCPv6 server was enabled, in Managed RA mode, with a pool on
+the delegated /64, and a packet capture on the bench VLAN showed it
+answering the board's Solicit with an address 1.3 ms later. The board's
+Request went to a different server-ID (a UUID) with `NoAddrsAvail`
+echoed back. A raw sniff on the board's own link named the other party:
+one of the VLAN's three OpenWrt access points still ran its LAN-side
+defaults, RA in server mode (its own ULA prefix with SLAAC, M and O
+flags, itself as DNS) and a DHCPv6 server with nothing to hand out. Its
+unicast Advertise beat the firewall's, and busybox's `udhcpc6` keeps the
+first Advertise it sees and keeps Requesting from that server, which is
+where the "IA_NA option is too short" line came from (an IA_NA carrying
+only a status code). The other two access points have RA, DHCPv6 and
+NDP-Proxy disabled, which is the setting that belongs on all three. The
+ULA the board carried all along was that access point's. Nothing on the
+board needs to change; the network side owns the fix.
+
 ## Superseded status notes
 
 ### Shared machine services — remaining polish, as listed 2026-08-13