@dpgeorge This PR replaces previous PR #16641. Linking here so we can retain the conversation history.

Code size report:

Thanks! The other PR was tagged with the RP2 port and for a release. @projectgus can you, or does someone else need to, move those designations over onto this PR?

Thanks! The other PR was tagged with the RP2 port and for a release. @projectgus can you, or does someone else need to, move those designations over onto this PR?

Have done. FWIW, for these kind of reasons it's almost always better to force-push to an existing PR branch rather than make a new PR. All good now, though.

Thanks! The other PR was tagged with the RP2 port and for a release. @projectgus can you, or does someone else need to, move those designations over onto this PR?

Have done. FWIW, for these kind of reasons it's almost always better to force-push to an existing PR branch rather than make a new PR. All good now, though.

Thanks, yes, that was my intention. However, still recovering from an illness and managed to get the original PR into a bad state via misapplication of rebase and force-push. I wanted a clean PR so decided it was better to start over in this case.

Thanks for getting back to this @mseminatore .

I tested the following cases:

• Pico 2 W in STA mode connected to local network, pinging it from a PC connected to the same network. Works well, both ipv6 and ipv4 addresses can be looked up (ping defaults to ipv6, used ping -4 pico2w.local to get the v4 address).
• Pico 2 W in AP mode, and a Pico W in STA mode connected to the Pico 2 W. The AP could lookup the address of the STA using socket.getaddrinfo('picow.local', 80).
• Same as above, STA connected to AP, but with the STA looking up the AP via socket.getaddrinfo('pico2w.local', 80). This did not work and I'm not sure why.

So it seems there's an issue with mDNS when in AP mode.

Regardless of that, IMO we can merge this PR as-is because it's an obvious improvement. Investigating and fixing the AP mDNS could take some time.

@projectgus @dpgeorge I have reproduced the issue with AP on a Pico W. I setup the Pico W as an AP and was unable to ping it from other local devices. I was able to connect to it, so the AP functionality is working.

Looking over the code a bit, I was not able to see where/why the AP code path might not work. Is there something unique about netif construction for AP mode?

Regardless of that, IMO we can merge this PR as-is because it's an obvious improvement. Investigating and fixing the AP mDNS could take some time.

I'm interested in continuing to help refine things, so tend to agree that this PR adds value even if there it is not fully working in AP mode.

If you want to try and debug it, you can use network.WLAN().config(trace=15) to enable ETH tracing on the Pico W (in either AP or STA mode).

Merged. Thanks for the contribution @mseminatore !

Things to do in follow up work:

• fix AP mDNS
• apply the same fix to stm32 and mimxrt (which also use cyw43), by factoring out common cyw43 configuration; @projectgus is working on this

Would it be possible to post sample code to illustrate this working? (I'm sure it will be trivial, but I'm also fairly sure I've done everything required and it isn't working for me).

As installed by Thonny, I'm using:

MicroPython v1.25.0 on 2025-04-15; Raspberry Pi Pico W with RP2040

Code (in a REPL):

import network
hostname = "something.local"    # I've tried this with and without the .local suffix
network.hostname(hostname)
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)
while not wlan.isconnected():
    time.sleep(1)
print("Connected!")

From a Pi with a wired connection to the same router (or a Mac with a wireless connection) I get variations on "Unknown host" when attempting to ping the Pico.

@ChrisLawther can you please try your code without setting the hostname and let us know if that works?

If I don't set the hostname I can see my router lists a device called PicoW, and I can ping it as a regular DNS name (i.e. no .local suffix). If I set the name before bringing the network up, I can then use that name instead.

That seems to be the initial DHCP interaction resulting in the DNS hostname being set, which I understood to be a completely different mechanism to mDNS.

Maybe I need to do some more reading. Or maybe the resulting regular DNS behaviour is actually fine and I've just been distracted by the "magical" aspect of mDNS.

@ChrisLawther I can't reproduce this myself, using the same setup (but no Thonny):

MicroPython v1.25.0 on 2025-04-15; Raspberry Pi Pico W with RP2040

Variation of your sample code:

import network, time
ssid = "myssid"
password = "mypassword"

hostname = "something"
network.hostname(hostname)
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect(ssid, password)
while not wlan.isconnected():
    time.sleep(1)
print("Connected!")

I'm running this as "mpremote run pr17057.py" but that shouldn't make much difference.

The main difference in the code is not setting .local on the hostname in the Python code, that's something the lookup uses as a signal that it should use mDNS rather than regular DNS.

On my Linux system:

❯ ping something.local
PING something.local (fe80::2acd:c1ff:fe05:b550%enp11s0) 56 data bytes
64 bytes from something.local (fe80::2acd:c1ff:fe05:b550%enp11s0): icmp_seq=1 ttl=255 time=1230 ms
64 bytes from something.local (fe80::2acd:c1ff:fe05:b550%enp11s0): icmp_seq=2 ttl=255 time=197 ms
^C
[...]
❯ ping -4 something.local
PING something.local (192.168.66.235) 56(84) bytes of data.
64 bytes from something.lan (192.168.66.235): icmp_seq=1 ttl=255 time=70.5 ms
64 bytes from something.lan (192.168.66.235): icmp_seq=2 ttl=255 time=91.5 ms
^C
[...]
❯ avahi-resolve-host-name something.local
something.local 192.168.66.235

Does mDNS work to lookup other hosts via .local? If not, the problem might be with the computer where you're trying to do the lookup, maybe a local firewall is blocking it?

That seems to be the initial DHCP interaction resulting in the DNS hostname being set, which I understood to be a completely different mechanism to mDNS.

Yes, that is probably a separate thing where your router makes the DHCP hostname available via regular DNS (without the .local suffix). I can get the same thing on my LAN by pinging something.lan (which resolves via DNS not mDNS).

The main difference in the code is not setting .local on the hostname in the Python code, that's something the lookup uses as a signal that it should use mDNS rather than regular DNS.

I did originally try both with and without the suffix. However, it is now working as expected so I must have been doing something subtly wrong. Thanks for confirming the correct omission(when setting) and inclusion (when pinging) of .local @projectgus

I did wonder whether it was my main machine "negative caching" the failure to look up the name when the pico was misconfigured, and continuing to report that failure even after applying a correct configuration, but I just tried that scenario and it's not that.

A sequence of operations that does result in the apparent failure is:

1. Misconfigure the pico (e.g. include the .local suffix)
2. Attempt to ping it - fails.
3. Correctly reconfigure the pico, but without power-cycling or hard-resetting it:
   • network.hostname() returns the correct name
   • still can't ping it (because the wifi connection was never reset, so it's actually still using the original configuration)

A call to machine.reset() before the reconfiguration produces the desired result. ✅
(My project will initially be configured as an AP, presenting a web interface to tell it the SSID+pass to connect to in future. I want to give the user the chance to set the mDNS name at the same time.)