Debugging Pico W DHCP problems

[gridstop]

I'm curious if there's a way to get any extra debug info out of the CYW43 drivers. I've tried both the stable 1.20 and the latest nightly, and my Pico W's routinely get stuck in WLAN.status() == 2, which is CYW43_LINK_NOIP. Grabbing packet dumps off the router shows nothing unusual, the DHCP request comes in and the offer goes out to the Pico W, but the status just doesn't progress to LINK_UP (3). Sometimes it's stuck for a while, sometimes it's stuck indefinitely, sometimes it goes straight to state 3. When it gets stuck for more than 10-15 seconds it never progresses, even though it keeps sending DHCP requests forever. The only solution is to completely power down the Pico W and hope it works on the next try. I'd say the wifi is able to connect and get an IP about 20-30% of the time, though sometimes I've gone hours without being able to get an IP.

I found that even though the wifi chip can be power cycled using GPIO23, you can't actually do that without locking things up next time you try to talk to the chip, even just to toggle the LED that is connected via the wifi chip. My only guess now would be to power off the wifi, trigger the watchdog, and hope that things come up in a working state after the power cycle.

So just curious if there's any way to enable any of the LWIP library diagnostic stuff, I see the rp2 port just #defines LWIP_PLATFORM_DIAG(x) to empty string, for example. Not sure if there's any hope of getting that output through the REPL terminal, and then if I could define LWIP_DEBUG somehow in the build, I could maybe get some idea of what is happening.

[scruss]

it's a long shot, but: is your network.country() set appropriately?

[gridstop]

EDIT: I thought adding the country code had fixed it for a while, but it seems to just be going in waves. It worked 20+ times in a row, and now has failed more than a dozen times in a row. I still could really use any advice on getting more debug information. There's just nothing observable from the Wifi Access Point, the problem is all on I guess the receive side of the Pico W wifi chip/stack. I've tried three different boards as well, no improvement.

[gridstop]

For reference, I'm running this snippet:

import network
import time
from auth import *

def x():
    network.country('US')
    wlan = network.WLAN(network.STA_IF)
    wlan.active(True)
    while wlan.status() != 3:
        wlan.connect(WIFI_SSID, WIFI_PASSWORD)
        time.sleep(20)
        print('Got status {}...'.format(wlan.status()))
    return wlan.status(), wlan.ifconfig()

I've also tried having the wlan.connect call just once before the loop, that seems to be much less reliable.

When it works I usually see this:

>>> x()
Got status 2...
Got status 3...
(3, ('10.0.5.3', '255.255.255.0', '10.0.5.1', '10.0.5.1'))

Sometimes there is a single error status like -2 first.

But often I just get stuck in status 2 forever even with the country code:

>>> x()
Got status 2...
Got status 2...
Got status 2...
Got status 2...
Got status 2...
(forever)

[scruss]

Your code snippet connects first time, every time for me.

WLAN.scan() returns a decent RSSI for the AP you're trying to connect to? In your routine, wlan.status('rssi') would also return the RSSI from the connected AP.

[gridstop]

RSSI values are in the -49 to -55 range, which to my understanding is pretty strong.

The only unusual thing I can think of at all about my AP is there are a couple SSID's on the same radio, because they map to different VLANs/subnets. But they have different SSIDs & BSSIDs so I don't think it should be getting confused, unless there's something low down in the CYW43 firmware or software stack that can't handle it.

Another odd thing I noticed with scan() is the tuple it returns, the documentation at https://docs.micropython.org/en/latest/library/network.WLAN.html says the last item is a 'hidden' boolean, which is not true for the cyw43. It's some kind of incrementing count of duplicate calls to the scan callback.

micropython/extmod/network_cyw43.c

Line 157 in 813d559

t->items[5] = MP_OBJ_NEW_SMALL_INT(MP_OBJ_SMALL_INT_VALUE(t->items[5]) + 1);

In my case I get a variety of random values of this from 1-3.