---
title: "Network issues / questions for LWIP and Wiznet"
url: "https://maker.wiznet.io/jakelee/projects/network-issues-questions-for-lwip-and-wiznet/"
markdown_url: "https://maker.wiznet.io/jakelee/projects/network-issues-questions-for-lwip-and-wiznet/md"
type: "UCC: User Created Content"
author: "Steve Spencer"
author_url: "https://forums.raspberrypi.com/viewtopic.php?t=391565"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Steve Spencer"
original_url: "https://forums.raspberrypi.com/viewtopic.php?t=391565"
published: "2025-09-18"
language: "en"
likes: 0
views: 1186
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# Network issues / questions for LWIP and Wiznet

> Discussion on Raspberry Pi Forum regarding using MicroPython on WIZnet Pico boards and issues with DHCP behavior.

Original author: Steve Spencer (source: https://forums.raspberrypi.com/viewtopic.php?t=391565)

## Article

## 📝 Summary: Network Issues / Questions for LWIP and Wiznet

**Context:**

User **SteveSpencer** is using MicroPython on Wiznet-equipped boards (e.g. **W5100S-EVB-PICO**) with RP2040 (Pico) for projects.

They also use Pico W / Pico 2 W boards as comparators.

The issue arises around DHCP behavior—specifically the setting of a **hostname** in DHCP requests, and processing of hostname returned by the DHCP server.

---

## 🔍 What the Discussion Found

**LWIP & Native Wiznet Stack Configuration**

It was confirmed that MicroPython builds for Wiznet boards have LWIP enabled.

However, even with LWIP enabled, some DHCP options—especially “hostname” (DHCP option 12)—are **not included in DHCP request packets.Lack of Hostname Handling**

The board does **not set a hostname** in DHCP discover/message.

It also **does not process** the hostname supplied by the DHCP server when IP is assigned. Users using `dnsmasq` with `dhcp-host` entries (to assign hostnames via DHCP) saw that their Wiznet board wasn’t recognized by this hostname in the LAN.

**A Proposed Fix / Workaround**

SteveSpencer edited `extmod/network_wiznet5k.c` in the MicroPython source: added a line `netif_set_hostname(&self->netif, mod_network_hostname_data);` just before `dhcp_start(&self->netif)`. This forces setting the hostname in LWIP before DHCP starts.

After this change, the hostname appears in DHCP server / LAN as expected.

**Broader Observations and Limitations**

The issue isn't unique to the Wiznet-stack; similar behavior is seen on Pico W / Pico 2 W. So some of this may be limitations or bugs in LWIP or how MicroPython builds enable/distribute certain features.

There was talk of upcoming code changes: Wiznet is preparing a newer “WIZNET6K” driver / update, which may improve matching behavior, or provide clearer build options to toggle between the onboard (native) IP stack vs the LWIP stack.

---

## ✔ Key Takeaways & Implications

**For Users / Developers:**

If hostname in network / LAN discovery matters, current behavior (without patch) may cause confusion — the device won’t appear under the expected name.

Static or custom DNS / DHCP setups (e.g. with `dnsmasq`) may depend on the hostname being set properly; so this bug or missing behavior affects usability in managed LANs.

Workarounds exist via modifying the MicroPython driver; users who are comfortable building firmware or custom drivers can apply them.

**For WIZnet / MicroPython / Firmware Teams:**

There's a visible gap: although LWIP is enabled, not all DHCP options are properly handled or forwarded (hostname option is missing).

Opportunity to officially patch or include the hostname behavior in future releases.

Clarity in builds / configuration: enabling LWIP, enabling DHCP option12 (hostname), controlling which stack is used should be clearly documented / exposed.

The “WIZNET6K” updates mentioned may present a chance to address these issues systematically.

---

Source: https://maker.wiznet.io/jakelee/projects/network-issues-questions-for-lwip-and-wiznet/