After a webserver load run the Wi-Fi data path stopped passing traffic while the association
still reported healthy.
Board side: wifi.radio.connected True, ap_info RSSI -52 dBm on the expected channel,
ipv4_address still the leased address. Outbound TCP to a public IP and UDP to the DHCP
gateway both failed with OSError(116) ETIMEDOUT, having worked minutes earlier in the same
REPL session.
Host side: ARP incomplete, No route to host.
A CircuitPython soft reset did not clear it. The board rebooted, re-associated, took the same
IP and was still dead. Only commander device reset recovered it, after which outbound TCP
worked immediately.
Attribution: the test server leaked its listening socket on the interrupt path across two
runs, which is a plausible contributor, and runs after that was fixed did not wedge. So this
may be resource exhaustion rather than a radio fault.
The reportable part does not depend on which resource ran out. There is no way to observe this
state from Python. Every status API reports healthy, so application code has no signal to act
on and no recovery short of a hardware reset. Resource exhaustion should either surface through
wifi.radio.connected or an error on socket creation, or be recoverable by a soft reset.
Right now it is neither.
After a webserver load run the Wi-Fi data path stopped passing traffic while the association
still reported healthy.
Board side:
wifi.radio.connectedTrue,ap_infoRSSI -52 dBm on the expected channel,ipv4_addressstill the leased address. Outbound TCP to a public IP and UDP to the DHCPgateway both failed with
OSError(116)ETIMEDOUT, having worked minutes earlier in the sameREPL session.
Host side: ARP incomplete,
No route to host.A CircuitPython soft reset did not clear it. The board rebooted, re-associated, took the same
IP and was still dead. Only
commander device resetrecovered it, after which outbound TCPworked immediately.
Attribution: the test server leaked its listening socket on the interrupt path across two
runs, which is a plausible contributor, and runs after that was fixed did not wedge. So this
may be resource exhaustion rather than a radio fault.
The reportable part does not depend on which resource ran out. There is no way to observe this
state from Python. Every status API reports healthy, so application code has no signal to act
on and no recovery short of a hardware reset. Resource exhaustion should either surface through
wifi.radio.connectedor an error on socket creation, or be recoverable by a soft reset.Right now it is neither.