diff --git a/docs/BRINGUP.md b/docs/BRINGUP.md
index d0db129..d20cc4d 100644
--- a/docs/BRINGUP.md
+++ b/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
diff --git a/docs/CAMPAIGN-LOG.md b/docs/CAMPAIGN-LOG.md
index 64506fc..ad1ceb7 100644
--- a/docs/CAMPAIGN-LOG.md
+++ b/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