extmod,rp2: Keep LWIP timer running if lwip poll_sockets() is called. - #18805

@dpgeorge Unfortunately I still don't really know how we handle this for a hypothetical future "non-blocking getaddrinfo()" as previous discussed. Probably for this we would need to reference count pending DNS queries and use this as an extra condition for keeping the timer alive.

EDIT: However there are other problems with a hypothetical async version, such as the current code assumes at most one outstanding DNS query. So can probably tackle if/when we write the async version.

Code size report:

Reference:  tests/extmod_hardware/machine_pwm.py: Add alif pin config. [95b3e72]
Comparison: extmod,rp2: Keep LWIP timer running if lwip poll_sockets() is called. [merge of bfc69db]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +8 +0.001% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.42%. Comparing base (95b3e72) to head (bfc69db).
⚠️ Report is 4 commits behind head on master.

@@           Coverage Diff           @@
##           master   #18805   +/-   ##
=======================================
  Coverage   98.42%   98.42%           
=======================================
  Files         174      174           
  Lines       22331    22331           
=======================================
  Hits        21980    21980           
  Misses        351      351           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for fixing this. The solution here looks good, although it would have been ideal if we could have somehow queried lwIP's active UDPs like we do with TCPs. But as you say, that won't work because of permanent UDP pbufs 😞

So I think the approach here is the next best thing.

Regarding tests: I realised that multi tests can work just fine with only a single instance, and could write the following "multi" test:

import socket, network

def instance0():
    wlan = network.WLAN()
    wlan.active(0)

    try:
        socket.getaddrinfo('micropython.org', 80)
    except OSError as er:
        print(repr(er))

    wlan.active(1)

    try:
        socket.getaddrinfo('micropython.org', 80)
    except OSError as er:
        print(repr(er))

    wlan.active(0)

You can run that with ./run-multitests.py -t a0 multi_wlan/getaddrinfo.py and it'll work. Without the fix here it will time out. With the fix it will run to completion and print two OSError's. Unfortunately the first one is -6 if the interface was never activated, but -2 if it has been activated (and hence the netif registered with lwIP). So it needs some tweaking to make it a proper test, but I think this is an acceptable way to test this, because the test needs network.WLAN but not an active connection (so multi_wlan/ seems like the best place for it).

Thanks for the thorough analysis and the cleaner fix, @projectgus. I agree #18805 is the right root-cause fix — keeping the timer alive so DNS timeouts actually work is much better than working around it at the getaddrinfo level. The +8 vs +64 byte difference speaks for itself too.

On the fast-failure question — my use case is a 24/7 IoT device where WiFi drops and reconnects periodically. Application-level retry logic (priority queue with exponential backoff) handles reconnection. From that perspective, fast-failing DNS when WiFi is known-down is genuinely useful: waiting ~14s for lwIP's internal DNS timeout when there's no link wastes time the application could spend reconnecting WiFi. But I can see how on a device with a flaky WiFi signal, the link might recover mid-DNS-timeout, and lwIP's retries could succeed without the application needing to know.

The idea of clearing DNS server settings on wlan.disconnect() / wlan.active(False) is appealing. It would mean dns_gethostbyname() sees no DNS servers and returns ERR_ARG immediately — fast failure without needing netif checks in getaddrinfo(), and the cleanup is semantically correct (disconnected = no DNS config). DHCP release would be the cleanest version of this since it clears DNS servers, IP, gateway, and netmask all at once.

If you go that route, the combination of #18805 (timer stays alive → DNS timeouts work) plus DNS cleanup on disconnect (→ fast failure when interface is explicitly taken down) would cover both the indefinite-hang bug and the "don't waste 14s when WiFi is gone" scenario cleanly. Happy to close #18801 in favour of that approach.

Thanks @dpgeorge, have added the test code you suggested to the PR and verified it fails on rp2 without this fix, and passes on both rp2 and esp32 ports otherwise.

Thanks @paul-matthews for the feedback. Will have a look at adding a fix so DNS is cleared when Wi-Fi disconnects from the MicroPython side. It's hard to know what to do if Wi-Fi disconnects (perhaps temporarily) from the other side, @dpgeorge is keen to add a non-blocking getaddrinfo variant and that might be the best in the long term (i.e. if you detect Wi-Fi disconnected while waiting for a DNS response then your application can abort whatever it's doing and go back to wait for Wi-Fi to connect.)

I'll look at putting up a PR to handle the case of failing immediately if the Python code has disconnected or deactivated the interface, though.