Skip to content

rp2/W5100S-EVB-PICO does not seem to send a hostname to DHCP server when getting address. #18024

Description

@SteveSpencer

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

  1. SteveSpencer commented on Sep 3, 2025

    @SteveSpencer
    Author

    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.

  2. SteveSpencer commented on Sep 4, 2025

    @SteveSpencer
    Author

    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);

  3. Josverl commented on Sep 5, 2025

    @Josverl
    SponsorContributor

    Find the call to dhcp_start(&self->netif) in the wiznet_lwip_init function, and insert the following line above it:\nnetif_set_hostname(&self->netif, mod_network_hostname_data);

    Thanks for sharing the fix.
    Would you be able to create a PR for this?

  4. added
    extmodRelates to extmod/ directory in source
    on Sep 5, 2025
  5. SteveSpencer commented on Sep 7, 2025

    @SteveSpencer
    Author

    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.

  6. SteveSpencer commented on Sep 9, 2025

    @SteveSpencer
    Author

    #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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugextmodRelates to extmod/ directory in source

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions