IPv4 address can persist well after wifi AP connection is lost

[anecdata]

CircuitPython version

Adafruit CircuitPython 8.0.0-beta.1 on 2022-10-01; Raspberry Pi Pico W with rp2040

Code/REPL

try:
    with requests.get(TEXT_URL) as r:
    print(f"{r.status_code} {r.reason.decode()} {r.content}")
except OSError as e:
    # Pico W becomes disconnected:
    # OSError: [Errno 2] No such file/directory
    print(f"{e} IPv4={wifi.radio.ipv4_address}")

Behavior

Filing this issue here too, from:
micropython#9505

This snippet

print(f"Connected?", end=" ")
wifi.radio.connect(secrets["ssid"], secrets["password"])
print(f"{wifi.radio.ipv4_address}")

typically gives:
Connected? 192.168.6.199
Connection to an AP succeeds silently, but connection can be checked by seeing if there is an IPv4 address.

The code snippet further up, when successful, will give:
200 OK b'This is a test of Adafruit WiFi!\nIf you can read this, its working :)

When the device has become disconnected from the wifi AP, the snippet will give:
[Errno 2] No such file/directory IPv4=192.168.6.199

From prior testing on Pico W (MicroPython issue 9455), when OSError: [Errno 2] No such file/directory occurs, it indicates disconnection from the AP and no ICMP / UDP / TCP operations are possible.

The device still has an IPv4 despite no connection to the AP. In the current espressif API, an IPv4 address exists if and only if there is a connection to the AP. Whenever it is unconnected to an AP, wifi.radio.ipv4_address will give None.

Description

With the default No Powersave in beta.1 for the Pico W, connections are robust. However, connections do get dropped from time to time for a variety of reasons. The Pico W IP address behavior is different from the espressif behavior.

Additional information

I think we should try to decide as this port evolves how closely espressif and raspberrypi ports should match in terms of the wifi API. The drivers are different, but I don't know how difficult that may make it to match behaviors, though it would be ideal if code ran interchangeably on both.

Addendum: good news... jimmo is working on this as part of some driver fixes, we can keep an eye on the issue linked above

[anecdata]

I think this is essentially closed by 7075, but I can leave it open to test that IP address goes away upon disconnection (if / when that gets implemented). See discussion around:
#7075 (review)

[anecdata]

Tested forcing disconnection by setting power management with very aggressive parameters. IPv4 address shows None several minutes after a successful connection + IP transactions. First re-attempt at an IP transaction after Ipv4 = None gets the expected Errno 2, but code can successfully re-connect and perform IP transactions. Rinse, repeat.

Closing, fixed by #7075. There may be nuances, but the code in this area is changing rapidly, so anything new that arises should be a separate issue.