ipv4_address_ap not available immediately

[stanelie]

CircuitPython version

Adafruit CircuitPython 9.2.0 on 2024-10-28; Waveshare ESP32-S3-Zero with ESP32S3

Code/REPL

import wifi
import ipaddress

ip_address_str = 0

ipv4 = ipaddress.IPv4Address("2.0.0.2")
netmask = ipaddress.IPv4Address("255.0.0.0")
gateway = ipaddress.IPv4Address("2.0.0.1")

def create_wifi_AP():
    wifi.radio.set_ipv4_address_ap(ipv4=ipv4, netmask=netmask, gateway=gateway)
    wifi.radio.start_ap("potato", "barbecue_chips", channel=1, max_connections=4)
    banana = str(wifi.radio.ipv4_address_ap)
    
create_wifi_AP()
ip_address_str = wifi.radio.ipv4_address_ap
print(f"my IP addr: {ip_address_str}" )

Behavior

If I run this code, it prints out the correct IP address in the console.
However, if I comment out the line 13 (the line that starts with banana), it prints out "my IP addr: None", the ipv4_address_ap is empty.

Description

Is this a bug? Or expected behavior? I was trying to get the ip address from the wifi radio and it took me a while to figure this out. Maybe there is something that I don't get...

Additional information

No response

[anecdata]

I ran the code as-is and got None. Then I removed the banana line and replaced it with a time.sleep(1) and got the AP IP address. I suspect there is a slight delay in how long it takes for the AP IP address to become accessible.

[stanelie]

That might be it, I will test. Thanks!

[stanelie]

Correct, it works for me as well.
Can this be added to the documentation?

[stanelie]

I tried time.sleep(0.01), it also works.

[anecdata]

Let's leave this issue open, there may be a fix possible in the software, so that the call to set the address doesn't return until the address is valid. iirc, there was a similar issue for Station that was fixed like that.

[anecdata]

Maybe an explicit call to esp_netif_dhcps_get_status() before returning from wifi.radio.set_ipv4_address_ap()? But what to do if it's not yet started? Check in a loop for some max time and raise an exception if it's still not started?

iirc, wifi.radio.ap_info.rssi had the same issue. It wasn't valid right away after a wifi connection. It was up to user code to wait and check. But maybe that was fixed.