LWIP mDNS interface on pico port

[omogenot]

Hi,

First of all, congrats for the tremendous work you guys have achieved !

I'm quite new to Micropython stuff, but succeeded however to compile it for a W5500_EVB_PICO board, and it's working like a charm. I even understood how to freeze some of my modules in the firmware to save RAM space.

As far as I can see in the rp2/lwip_inc/lwipopts.h file, there are two constants:

#define LWIP_DNS_SUPPORT_MDNS_QUERIES   1
#define LWIP_MDNS_RESPONDER             1

that supposedly implies some mDNS support to the lwip driver. This is confirmed by the fact that the port 5353 is busy as you cannot bind a socket to it. So far, so good. However, I do not see any API/Object/Function when doing an "import lwip" or any other module to take advantage of this mDNS support and publish my pico IP and services.

How can I do? Or shall these constants be put to 0 by default and I will have to write my own mDNS functions?

I thank you in advance for your advices.

Olivier.

[jimmo]

How can I do? Or shall these constants be put to 0 by default and I will have to write my own mDNS functions?

@omogenot the simple answer for right now is that yes you should disable these flags and then implement mDNS in Python. https://github.com/cbrand/micropython-mdns might be helpful.

In more detail, on rp2 the lwip mdns features are enabled by default because on the Pico W board the wlan driver supports setting a hostname, which it also advertises via LWIP's mDNS. (Ok it doesn't quite support configuring it, but it does set a default hostname, see https://github.com/micropython/micropython/issues/8906). The wiznet LAN driver doesn't support this at all yet, so on rp2 boards that don't use the cyw43 wlan driver we should probably disable those lwip mdns flags by default until it does so as not to block the port.

But yes, longer term this should be more configurable from Python (e.g. modlwip or something...not sure).

[omogenot]

Hi,

Thanks for the update. I therefore modified the file extmod/network_wiznet5k.c, stealing code from cyw43 driver to add at line 64: #include "lwip/apps/mdns.h"

and at line 520:

    #if LWIP_MDNS_RESPONDER
    // TODO better to call after IP address is set
    char mdns_hostname[9];
    memcpy(&mdns_hostname[0], "PICO_W5K", 8);
    mdns_hostname[8] = '\0';
    mdns_resp_add_netif(&self->netif, mdns_hostname, 60);
    #endif

Et voilà ! Now I can see my pico board when I do a ping pico_w5k.local . Now I will try to expand the 5k driver to add a more versatile hostname management and eventually mDNS service registration/unregistration access. If I succeed I will try to do a PR for that (although I'm not really up to speed with this kind of git procedure I must admit).

Olivier.

[omogenot]

Hi,

I wrote the necessary code in the network_wiznet5k.c file to support mDNS hostname handling, and mDNS service add, remove. During this process, I noticed that the wiznet5k files are duplicated in the tree. As far as I can see, the one located in lib/wiznet5k are the latest and "linked" to WIZNET development branch (i.e. [wiznet5k @ 0803fc5]), whereas a similar set of files is located in drivers/wiznet5k and seems very old :

Original source: https://github.com/Wiznet/W5500_EVB/tree/master/ioLibrary Taken on: 30 August 2014

Shall not this older version of files be removed, making sure that some builds which could be dependent on these can use the newer ones instead?

Apparently, the only port relying on this old version is stm32. Can anyone try to use lib/wiznet5k instead of drivers/wiznet5k in ports/stm32/Makefile and ports/stm32/network_wiznet5k.c files? I have no STM32 platform to test.

[ShadowLNC]

Pico W board the wlan driver supports setting a hostname, which it also advertises via LWIP's mDNS

I'm a little confused regarding the intended behaviour on a Pico W. With the MicroPython standard build, mDNS doesn't appear to work - I cannot ping its hostname via a .local address, and Windows does not resolve it unless I add a dot to the end of the name (e.g. ping pico. - so it's treated as a FQDN - which appears to be resolving via my router's DNS rather than mDNS).

I'm not sure if I need to be doing something special or if the only way to achieve device (not service) discovery is to install micropython-mdns and disable the native resolver? Is this something that should be looked at in #10957 or #11450, or is it intended behaviour, or should I file a new ticket?