Why dnsmasq Ignores DHCPDISCOVER Packets That tcpdump Can See

If tcpdump shows DHCPDISCOVER packets arriving on your interface but dnsmasq never reacts — not even with log-dhcp enabled — the packets are almost certainly not making it into dnsmasq's UDP socket, even though they are visible at the capture layer. tcpdump taps the network stack below most of the filtering that governs whether a userspace process ever receives a packet, so "tcpdump sees it" and "the daemon sees it" are two very different statements. This article walks through the usual suspects in order of likelihood.

Why tcpdump sees packets that dnsmasq does not

tcpdump uses a raw packet capture mechanism that receives frames at a low level of the network stack, essentially cloning everything that touches the interface. A DHCP server like dnsmasq, by contrast, binds a normal UDP socket on port 67 and only receives packets that the kernel delivers to that socket. Between those two points sit several filters:

• Interface addressing — the kernel decides which sockets see a packet partly based on the addresses assigned to the receiving interface.
• Socket binding and conflicts — only one process can hold the DHCP socket; a competitor may have silently won it.
• Bridge and virtual switch configuration — on hypervisors, packets can appear on a tap device without being properly delivered on the bridge the server is attached to.

Any of these can produce the exact symptom: visible in tcpdump, invisible to dnsmasq, no log lines at all.

Cause 1: no usable IPv4 address on the serving interface

This is the most common misconfiguration. dnsmasq can only offer DHCP leases on an interface that carries a static IPv4 address in the subnet being served. If the interface has no address, only a link-local address, or an address in a different subnet, dnsmasq will quietly ignore discovers on it. Crucially, it does this silently — even log-dhcp only logs packets it actually processes.

Check the interface on the server:

ip addr show eth1

If nothing in 10.114.114.0/24 is listed, assign a fixed address in that subnet but outside your dynamic pool, for example 10.114.114.1/24, and restart dnsmasq. The restart matters: dnsmasq binds its sockets at startup, so if it was launched before the address existed, it may never pick the interface up correctly. Starting the daemon after the interface is fully configured is a habit worth enforcing in your boot order.

Cause 2: another process holds port 67

DHCP requires an exclusive socket on UDP port 67. If a second DHCP server is running — another dnsmasq instance, a full DHCP daemon, or something spawned by a network management service — it may hold the socket while your intended instance still starts up and logs its banner normally, looking perfectly healthy.

Verify who actually owns the port:

ss -ulnp sport = :67

The process ID shown here is the one receiving packets. If it is not the PID of the dnsmasq instance you configured, stop the other daemon or consolidate configurations. Also check for duplicate dnsmasq processes with ps aux | grep dnsmasq — a distro's default service can start one automatically alongside your hand-rolled instance.

Cause 3: virtualization bridge misconfiguration

If the server and client are virtual machines on a hypervisor such as Proxmox, verify that the VM's network device is actually attached to the bridge you think it is. A mismatch between the bridge a client's NIC is connected to and the bridge on the server side can produce bizarre results: broadcast traffic occasionally leaking across in one direction — which tcpdump happily displays — without any real, consistent delivery path. If broadcasts seem to arrive intermittently or stop after a host reboot, treat this as a strong hint.

On Proxmox, compare the vmbr assigned to the server VM's network interface with the one the client uses; both must reference the same bridge, and that bridge must correspond to the physical or internal network carrying the traffic. Fixing the bridge assignment typically resolves the problem immediately, and the DHCP log entries appear right away.

Cause 4: interface naming and state

Two smaller but real pitfalls:

• The packet may be arriving on a different interface than the one you think — a bridge member port, a VLAN subinterface, or a renamed device. Match the interface= directive exactly against the device where tcpdump captures the traffic.
• The interface must be in state UP. dnsmasq binds exclusively to the named interface and will not serve on one that is down.

A systematic troubleshooting sequence

1. Run ip addr show <interface> and confirm a static IPv4 address in the DHCP subnet exists.
2. Run ss -ulnp sport = :67 and confirm the right process owns the socket.
3. Confirm the interface name in the dnsmasq config matches reality and the link is up.
4. On a hypervisor, audit the bridge assignment for both client and server VMs.
5. Add log-queries and log-dhcp, restart dnsmasq after all network configuration is complete, and watch the log live with journalctl -fu dnsmasq or your equivalent.

Note that a firewall is rarely the culprit here: UDP 67 broadcast traffic to a locally bound socket is usually permitted by default, and if it were dropped you would more likely see it in firewall counters. Still, if everything above checks out, inspecting rules with iptables -L -v -n or nft list ruleset is a reasonable last step.

Frequently Asked Questions

Does dnsmasq log dropped or ignored DHCP packets?

No. log-dhcp only logs packets dnsmasq actually processes. Packets filtered out before reaching the socket, or ignored due to missing interface addressing, produce no log output at all — which is why silence in the log does not mean the packet never arrived on the machine.

Why does the server need an IP address in the DHCP subnet at all?

dnsmasq determines which range and options to offer based on the interface a request arrived on, and it uses the interface's own address to construct the server identifier and the subnet context. Without an address in the subnet, it has no basis for serving that interface.

Can I put the server's address inside the DHCP pool?

You should not. The pool range is handed out to clients, so a static server address inside it will eventually collide with a leased address. Place the server's address in the same subnet but outside the pool — for instance, at the low end of the range.

The client shows "broadcasting discover" repeatedly and gives up. What does that tell me?

It confirms the client never receives an offer, so the failure is on the server path — delivery, socket, or server-side filtering — not on the client's side. It does not distinguish between the causes listed above, so work through them in order.

tcpdump showed the packets, then they stopped appearing entirely. What changed?

Intermittent visibility of broadcasts with no functioning DHCP exchange is a classic sign of a virtualization bridge problem, where packets leak between bridges rather than being delivered properly. If the traffic vanishes after a host or VM restart, check the bridge assignments on both VMs.

Should dnsmasq be started before or after the network comes up?

After. dnsmasq binds its sockets when it starts and does not reliably adapt if the interface is later reconfigured. Ensure your boot sequence brings interfaces and their addresses up before launching dnsmasq, or add a restart of dnsmasq to your network configuration hook.