Some problems with DHCP

federico.ballarini · January 10, 2026, 7:25pm

Hi all,

probably it’s not directly related to NethSecurity since I have more than 40 installed without any problems, but I need your help/opinion.

I have a site where some devices (LAN tickets printer and digital signage monitor in particular) at first boot don’t get the connection. The first is via LAN and the monitor via WiFi.

On the firewall I get lot of this kind of row:

00:00:05.992051 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:07.032015 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:08.072038 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:13.981772 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:15.032028 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:16.072040 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:17.126629 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:18.152043 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:19.192048 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:20.246791 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:21.272049 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:22.312036 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:23.393607 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:24.472004 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:25.512000 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28
00:00:26.975671 eth0  Out ARP, Request who-has 192.168.206.231 tell fw.mydomain.com, length 28

On the WiFi device I noticed two things:

if I connect to my phone hotspot it works like a charm
it seems connected but without the ip address

Could be a problem on the switch? Some settings I can arrange?
Has anyone already had this problem?

Thank you in advance!

antonin.chadima · January 11, 2026, 5:29am

The posted ARP request is a standard DHCP conflict-detection before the DHCP server sends a DHCP OFFER.
The funny thing is the fw.mydomain.com part, but this is maybe only a reverse DNS resolution done by the logger, because originally this should contain the IP address of the firewall.

Much more useful would be logs/tcpdump from the clients with the DHCP problem.
It looks like, the client connects to the WiFi, but doesn’t get a DHCP lease.
So you should log/tcpdump the DHCP communication.

DHCP DISCOVER (Client ➔ Server)
Server-Side Conflict Detection (Server) - your logs from the firewall?
DHCP OFFER (Server ➔ Client)
DHCP REQUEST (Client ➔ Server)
DHCP ACK (Server ➔ Client)
Client-Side DAD (Client)

And this must fail in some step in your case…

MadPatrick · January 11, 2026, 8:56am

Hi,

Maybe not related, but maybe itis

I see recently log line in my VMkernel.log about ARP

2026-01-10T21:51:25.906Z In(182) vmkernel: cpu1:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x3020)
2026-01-10T21:51:36.068Z In(182) vmkernel: cpu0:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x3020)
2026-01-10T22:49:15.642Z In(182) vmkernel: cpu3:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x3020)
2026-01-10T23:51:31.803Z In(182) vmkernel: cpu2:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T00:49:07.851Z In(182) vmkernel: cpu1:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x3020)
2026-01-11T01:08:26.452Z In(182) vmkernel: cpu3:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x3020)
2026-01-11T05:54:56.059Z In(182) vmkernel: cpu0:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T05:54:58.105Z In(182) vmkernel: cpu0:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T05:55:02.182Z In(182) vmkernel: cpu3:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T05:55:08.262Z In(182) vmkernel: cpu1:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T05:55:16.444Z In(182) vmkernel: cpu3:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x100)
2026-01-11T05:55:26.632Z In(182) vmkernel: cpu0:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T05:55:38.707Z In(182) vmkernel: cpu2:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T05:55:53.057Z In(182) vmkernel: cpu3:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x0)
2026-01-11T06:08:18.119Z In(182) vmkernel: cpu3:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x3020)
2026-01-11T06:46:58.527Z In(182) vmkernel: cpu1:1049059)Tcpip_Vmk: 123: arp: unknown hardware address format (0x3020)

i’ve no clue where it is coming from, but maybe the is a connection with this problem?

antonin.chadima · January 12, 2026, 4:24pm

if the logs you have posted and your problem correlates
then the DHCP dialog ends somewhere after phase “Check”
even after OFFER and REQUEST went OK
without ACK you don’t have DNS, gateway etc.
so you really need exact logs like from tcpdump

Step	Packet Name	Direction	Meaning
D	DISCOVER	Client to Server	“I need an IP!”
Check	ARP Request	Server to Network	“Is this IP free?” (Your log)
O	OFFER	Server to Client	“Take 192.168.x.x”
R	REQUEST	Client to Server	“I’ll take it!”
A	ACK	Server to Client	“Confirmed. Here is the config.”

antonin.chadima · January 12, 2026, 4:41pm

The hardware address format (HTYPE) is a 16-bit number located in the ARP packet header.
It is the very first item in the ARP packet.
If ESXi reads something other than what it expects at this first position, it throws exactly this error.

Hardware address format defines the type of physical network (Link Layer) being used.
The ARP protocol was designed to be universal, not just for Ethernet.
These values are officially defined by the IANA organization:

Value (Dec)	Value (Hex)	Meaning	Note
1	0x0001	Ethernet (10Mb)	This is the standard. 99.9% of today’s traffic. ESXi expects this.
6	0x0006	IEEE 802 Networks	Older standards, Token Ring.
15	0x000F	Frame Relay	Older WAN technology.
32	0x0020	InfiniBand	High-speed interconnect (HPC clusters).

In your case on this fist position was 0x0 (reserved), 0x100 (ARPHRD_PPP) or 0x3020 (garbage).

Possible causes:
Software error in a VM (sending PPP packets to the LAN).
Aggressive network scan (sending empty/null headers).
Network card/driver error (sending corrupted data - garbage).
Corrupted ARP packets from the ARP broadcaster.

If everything looks OK, ignore these logs, VMware has dropped these packets.
Otherwise you have to use tcpdump (and pktcap-uw) to find the source of these packets.

herman32 · February 27, 2026, 5:36pm

This really looks like a DHCP issue, not NethSecurity itself.

Those ARP “who-has” messages usually mean the firewall is trying to reach an IP that isn’t responding. And since the WiFi device shows connected but no IP, that confirms DHCP isn’t completing.

The fact that it works fine on your phone hotspot is the big clue — the devices themselves are fine.

check: DHCP scope (enough free IPs available?)No duplicate IP already in use (especially 192.168.206.231). Switch config (VLAN mismatch, port isolation, or STP delay). DHCP snooping enabled on the switch by mistake

If both wired and WiFi devices fail only at first boot, I’d strongly suspect the switch (VLAN or spanning tree delay).