Repository navigation
rp2/W5100S-EVB-PICO does not seem to send a hostname to DHCP server when getting address. #18024
Description
Port, board and/or hardware
rp2.W5100S-EVB-Pico (RP2040)
MicroPython version
MicroPython v1.26.0 on 2025-08-09; W5100S-EVB-Pico with RP2040
Reproduction
import network
import time
print('current hostname: {}'.format(network.hostname()))
nw = network.WIZNET5K()
nw.active(False)
nw.active(True)
while not nw.isconnected():
time.sleep(1)
print('hostname: {}'.format(network.hostname()))
Expected behaviour
Correctly prints the default hostname both times.
DNSmasq server should allocate address for that hostname, and be able to resolve hostname in normal way
Observed behaviour
While the hostname is shown as W5100S-EVB, dnsmasq cannot resolve the name, and in the leases file, no hostname is shown for the corresponding address.
Additional Information
If I use rp2/pico2_w port and perform the equivalent (which means connecting to an AP rather than plugging in a cable), I get the expected behaviour, so I believe it is something specific to hostname handling in the Wiznet NIC code.
Code of Conduct
Yes, I agree
Activity
SteveSpencer commentedon Sep 3, 2025
I have used wireshark to examine the DHCP request, and the hostname option is not being sent.
Since the code in lib/wiznet5k/Internet/DHCP/dhcp.c looks like it is setting it, albeit to a hardcoded value, I do not understand why there is no option-12 being put into the discover or request packet.
Obviously, there is no code in there to process the hostname in the reply, so it cannot be assigned by the DHCP server.
SteveSpencer commentedon Sep 4, 2025
Having done more investigations, it is a simple one-line fix to extmod/network_wiznet5k.c
Find the call to dhcp_start(&self->netif) in the wiznet_lwip_init function, and insert the following line above it:
netif_set_hostname(&self->netif, mod_network_hostname_data);Josverl commentedon Sep 5, 2025
Thanks for sharing the fix.
Would you be able to create a PR for this?
SteveSpencer commentedon Sep 7, 2025
For some reason, the fix seems to destabilize the network module - perhaps because it alters the response from the DHCP server. In any case, what seems to be happening is that while the board thinks it has negotiated a lease (as does the server), network communication is then very hit and miss, with the link effectively disappearing. I am no longer able to ping the board, while with 1.26, I can, once I have determined the board address (difficult with no hostname!).
I will continue to investigate.
I may also compare the preview build source with the released 1.26, in case something else related has changed.
SteveSpencer commentedon Sep 9, 2025
#18035 appears to be a major update to the wiznet board support, so it would seem to make sense to ask wiznet-grace to check and make this minor change, rather than wait for that to be accepted, and then make this change. Do you agree?