DHCP Server not responding to container DHCP DISCOVER packets (netavark/Podman clients)

[th3cube]

Issue Description

Technitium DHCP server receives but does not respond to DHCP DISCOVER packets from containerized DHCP clients (specifically Podman with netavark DHCP proxy), while the same packets work perfectly with ISC Kea DHCP server.

Environment

Technituim Server

• Technitium DNS Server Version: 13.6
• OS: Linux Debian 12.11 (no docker install)

Podman Server

• Container Runtime: Podman version 5.4.2 with netavark backend
• Network Configuration: macvlan with DHCP IPAM driver

Problem

Technitium DHCP server successfully serves IP addresses to standard network clients (phones, laptops) but completely ignores DHCP DISCOVER requests from container clients using netavark DHCP proxy.

Working with Kea DHCP:

16:48:42.875778 - DHCP DISCOVER (client)
16:48:42.878489 - DHCP OFFER (Kea server responds in 3ms)
16:48:42.879243 - DHCP REQUEST (client accepts)
16:48:42.882588 - DHCP ACK (Kea confirms)

Failing with Technitium DHCP:

17:28:09.304504 - DHCP DISCOVER (client)
17:28:13.304607 - DHCP DISCOVER (client retry)
(No response from Technitium server)

Technitium works with iPhone:

17:06:41.808887 - DHCP REQUEST (iPhone)
17:06:41.810548 - DHCP ACK (Technitium responds in 2ms)

Packet Analysis

Container DHCP DISCOVER packet (ignored by Technitium):

Client-Ethernet-Address 00:1f:3c:12:34:56
sname "59d59d3022e1"
DHCP-Message (53): Discover
Client-ID (61), length 65: "59d59d3022e174cb18779369e8b74288b6b6c1fe5da1e5e0a0aee92a3ec03f90"
Hostname (12): "59d59d3022e1"
Parameter-Request (55): Hostname, Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name, MTU, NTP

iPhone DHCP REQUEST packet (responded to by Technitium):

Client-Ethernet-Address 22:7a:xx:xx:xx:xx
DHCP-Message (53): Request
Client-ID (61), length 7: ether 22:7a:xx:xx:xx:xx
Hostname (12): "iPhone"

Configuration Verified

DHCP Scope Configuration:

• Available IPs: 100+
• Scope Status: Enabled
• "Ignore Client Identifier (Option 61)": Enabled
• "Block Locally Administered MAC Addresses": Disabled

Troubleshooting:

• Tried both locally and globally administered MAC addresses
• DHCP service restarted
• Client-ID option ignored (enabled in settings)
• Network connectivity verified (packets reach server)
• Scope has available IP addresses
• Same network segment as working clients
• No DHCP relay agents
• Tested with different container hostnames

Expected Behavior

Technitium DHCP should respond to container DHCP DISCOVER packets with DHCP OFFER, similar to how it responds to iPhone requests and how Kea DHCP handles the same packets.

Actual Behavior

Technitium DHCP completely ignores container DHCP DISCOVER packets, causing container networking to fail with timeout errors:

Jun 09 16:38:40 podman netavark[33524]: [ERROR mozim::client] Timeout: Timeout

Steps to Reproduce

1. Configure Technitium DHCP with a standard scope
2. Enable "Ignore Client Identifier (Option 61)" option
3. Create Podman macvlan network with DHCP IPAM:

   podman network create --driver macvlan --ipam-driver dhcp --opt parent=eth0 test-network
   

4. Run container: podman run --network=test-network alpine
5. Observe DHCP timeout vs successful lease with other DHCP servers

Compatibility Issue ?

Kea DHCP handles the same packets without issues, suggesting Technitium may have stricter validation that's rejecting valid DHCP DISCOVER packets.

Key Differences in Packet Format

Field	Container (Failing)	iPhone (Working)
DHCP Message Type	DISCOVER	REQUEST
Client-ID Length	65 characters	7 characters
Client-ID Format	Hash string	ether MAC
SNAME Field	Container ID	None
MAC Address Type	Both local/global tested	Vendor MAC

[ShreyasZare]

Thanks for the post. The info provided is not sufficient to debug the issue. Have you checked the log file from the Logs section on the admin panel? Does it have any DHCP related logs when the client attempts to get a lease? Please share any logs you see here.

I would also request that you run tcpdump -i any -w file.pcap on the server on which DHCP server is running and attempt to get a lease for the client. Share this pcap file over email to [email protected]. Also share a screenshot of the DHCP Scope so that the scope config is also known to help debug the issue.