================================================================================
Matter-over-Wi-Fi commissioning fails to complete ("Setting up" / "Unable to add
accessory") - root-cause investigation
Matter Light Bulb, NCS v3.3.4, nrf54lm20dk/nrf54lm20a/cpuapp + nrf7002eb2
Snippet: nrf70-driver-debug.  Captured: 2026-10-15
================================================================================

EXECUTIVE SUMMARY
-----------------
The originally reported "nRF70 Wi-Fi TX stall" is NOT a Wi-Fi TX problem. We ruled
that out, ruled out net_buf exhaustion, found and fixed one real config bug on our
side (IPv6 PKTINFO), and have now isolated the remaining failure to Matter
operational mDNS: the device joins Wi-Fi and goes operational, but the operational
mDNS announcement fails to send ("Failed to advertise records: 46") on every
attempt, so the controller (HomePod mini / Apple Home) never completes CASE over
Wi-Fi and commissioning does not finalize.

WHAT WAS RULED OUT (with evidence)
----------------------------------
1. nRF70 Wi-Fi TX stall - NO.
   While the device was "No Response", ICMPv6 ping to LAN peers succeeded both
   ways (3/3 replies, ~50-87 ms). net stats showed Send Drops: 0 and
   tx_stats 0 showed 0 outstanding / 0 pending on all ACs. Wi-Fi TX works.
   (See net_stall_capture.log.)

2. net_buf / net_pkt pool exhaustion - NO.
   Rebuilt with CONFIG_NET_BUF_POOL_USAGE=y. During the failure there were
   0 "Failed to allocate net_pkt" events. Pools are not exhausted.

CONFIG BUG FOUND AND FIXED (IPv6 PKTINFO)
-----------------------------------------
Symptom: repeated  <err> chip: [IN]IPV6_PKTINFO failed: 109  (EPROTONOSUPPORT),
and operational mDNS failing after Wi-Fi connect.

Root cause: CONFIG_NET_CONTEXT_RECV_PKTINFO was not set in the build. In
zephyr/subsys/net/lib/sockets/sockets_inet.c the ZSOCK_IPV6_RECVPKTINFO setsockopt
case is gated on CONFIG_NET_IPV6 && CONFIG_NET_CONTEXT_RECV_PKTINFO; when the
latter is unset the option is rejected, which is the 109 that CHIP minimal mDNS
hits when enabling pktinfo on its multicast socket.

Fix applied: -Dlight_bulb_CONFIG_NET_CONTEXT_RECV_PKTINFO=y
Result: IPV6_PKTINFO failed: 109 is GONE (0 occurrences after the fix, confirmed
at runtime). This is a real improvement and should likely be enabled by default
for Matter-over-Wi-Fi on this target.

REMAINING DEFECT (operational mDNS announcement)
------------------------------------------------
Even with PKTINFO fixed, commissioning still does not complete. Every attempt
shows, at the Wi-Fi -> operational transition:

   [DIS] Advertise operational node CCC10070EA402D1F-<nodeid>
   [DIS] Responding with _matter._tcp.local
   [DIS] Responding with <instance>._matter._tcp.local
   [DIS] Responding with F4CE3600B6C8.local
   [DIS] Responding with _ICCC10070EA402D1F._sub._matter._tcp.local
   [DIS] CHIP minimal mDNS configured as 'Operational device'
   <err> chip: [DIS]Failed to advertise records: 46        <-- EVERY TIME
   [DIS] mDNS service published: _matter._tcp
   [SVR]Operational advertising enabled
   [SVR]Server initialization complete
   [DIS] Updating services using commissioning mode 0      <-- device IS operational

Device side therefore reaches operational state (commissioning mode 0, server
init complete), but:
 - From a PC on the same /64 (dns-sd -B _matter._tcp), the operational instances
   are visible in the PTR browse but do NOT resolve (dns-sd -L returns no SRV/
   AAAA). The announcement/response path is not delivering a usable record.
 - The controller never establishes CASE over Wi-Fi; it stays on the BLE PASE
   session (endless CHIPoBLE "len 3" keep-alives), then Apple Home reports
   "Setting up" indefinitely or "Unable to add accessory".

"Failed to advertise records: 46" reproduces on 100% of attempts at the exact
operational-advertise step. This is the prime suspect for the non-completion.

ENVIRONMENT NOTES (not the root cause, but relevant)
----------------------------------------------------
 - Build is IPv6-only: net ipv4 -> "IPv4 support: disabled".
 - The Wi-Fi /64 carries TWO IPv6 ULA prefixes (fd0a:3084:611b:1::/64 and
   fdc0:cb91:39c6:4fe0::/64); multi-prefix networks can complicate Matter
   operational AAAA selection.
 - A HomePod mini is the Matter controller/border device; it was rebooted to
   flush its mDNS cache. Stale _matter._tcp PTR records for the fabric persist
   on the LAN (cached elsewhere) but do not resolve; they appear inert.

REPRODUCTION
------------
1. Factory-reset device (matter device factoryreset).
2. Apple Home -> Add Accessory -> scan QR (MT:6FCJ142C00KA0648G00).
3. PASE over BLE succeeds, device joins Wi-Fi "Netanel" (RSSI ~-45), goes
   operational, but hits "Failed to advertise records: 46"; controller never
   finishes. Repeats identically every time.

QUESTIONS FOR NORDIC
--------------------
1. Should CONFIG_NET_CONTEXT_RECV_PKTINFO be enabled by default for the Matter
   light_bulb sample on nrf54lm20dk + nrf7002 (Matter-over-Wi-Fi)? It is required
   for CHIP minimal mDNS and is currently off.
2. What does "Failed to advertise records: 46" indicate in the NCS v3.3.4 CHIP
   DNSSD / Zephyr mDNS multicast send path, and why does the operational
   announcement fail to produce a resolvable SRV/AAAA record? This is the
   remaining blocker to commissioning completion.

ATTACHED LOGS
-------------
   clean_commission.log   - latest clean attempt (PKTINFO fixed, HW reset,
                            HomePod rebooted): shows Wi-Fi join + operational +
                            the recurring "Failed to advertise records: 46".
   pktinfo_commission.log - first attempt with PKTINFO fix (PKTINFO error gone).
   net_stall_capture.log  - earlier: ping works + net stats + tx_stats (rules out
                            Wi-Fi TX stall).
   net_baseline_healthy.log - working-state baseline.
================================================================================
