Why DHCP fails and how to track packets with tcpdump

Why do devices lose their IP address on the network?

When a computer, smartphone, or server joins a local network, it needs an IP address to communicate with other devices. This digital number acts just like the postal address of your house. The service responsible for distributing these addresses is the DHCP server, which stands for Dynamic Host Configuration Protocol. In practice, it works like an efficient clerk who greets newcomers and hands out a valid identification badge for a set period. If this process fails, the device remains isolated, displaying that dreaded limited connectivity warning.

There are several reasons for this mechanism to break down in daily operations. It could be a poorly connected network cable, an incorrect VLAN configuration preventing traffic from crossing physical barriers, or even a complete exhaustion of available addresses on the router. When this happens, the operating system tries to guess an address by generating a temporary IP, but internet browsing remains inaccessible. To go beyond mere guesswork and find the root cause, we need to inspect the invisible traffic flowing through the cables using command-line tools.

Understanding the DORA cycle behind IP assignment

Before launching any diagnostic tool, it helps to understand the rapid conversation happening in fractions of a second between the new machine and the server. This flow is known by the acronym DORA, which summarizes four sequential stages. The first is Discover, where the newly arrived computer shouts across the network asking if any DHCP server is available. Since it still lacks an address, this shout is sent as a broadcast, meaning it targets every possible listener in the same digital room.

The second stage is Offer, the moment the server replies by offering an available IP. Next, the computer sends a Request, formally accepting that specific offer and asking to register the name. Finally, the server returns an Acknowledge, stamping the contract and confirming that the IP now officially belongs to that device. If any of these messages gets lost along the way, the broken cycle means the IP never reaches its destination.

How to capture DHCP traffic using the tcpdump command

When a computer fails to receive an IP, we need to put on our detective hat and analyze data packets in real time. This is where tcpdump comes in, a classic Linux program designed to listen to network traffic directly from the terminal. In practice, it acts like a high-precision microphone attached to the network card, recording everything coming in and going out. Before moving forward, it is also useful to recall how traffic behaves in other layers, a topic we explore when we trace IP packets and routes on Linux with traceroute to understand data paths.

To start monitoring DHCP messages without getting lost among thousands of unrelated web packets, we apply a filter targeting the standard protocol ports, 67 and 68. The basic command to start listening on your primary network interface, usually called eth0 or wlan0, requires administrator privileges. Typing the correct instruction in the terminal filters out everyday browsing noise and focuses strictly on IP address negotiations.

sudo tcpdump -i eth0 -n -v port 67 or port 68

In this command, the flag -i defines which network card to listen to, -n stops the program from wasting time trying to translate IP addresses into domain names, and -v adds a useful level of detail on the screen. Running this line while restarting your client device's network card will display the DORA messages scrolling across your terminal with impressive clarity.

Interpreting packets and spotting where the flow stalls

With tcpdump running and generating text lines on screen, the secret is recognizing the footprints left by each stage of the DORA cycle. When the client triggers the Discover, you will see a line indicating a packet moving from 0.0.0.0 toward 255.255.255.255, which represents the universal broadcast channel. If you see this request leaving but no response arriving shortly after, the problem clearly lies within the DHCP server or an intervening firewall block.

If the server replies with an Offer, but the client ignores it and repeats the Discover, the issue might be an IP conflict on the network where another device is already using the offered number. This meticulous check prevents you from spending hours randomly swapping cables or rebooting gear. For complex environments, it pays to cross-reference this data with other layer diagnostics, much like when we track lost network packets with Wireshark for detailed graphical analysis of the same events.

To explore these architectural concepts further in production, see our related technical analysis on How to test AMS1117 voltage regulator with multimeter.

Final thoughts on local network troubleshooting

Mastering DHCP packet tracking with tcpdump turns a frustrating and invisible problem into a logical, fully solvable puzzle. Instead of accepting connection failures as an unsolvable mystery, you get to see precisely which message was lost along the path between the computer and the server. This skill saves precious time in corporate networks, home labs, or infrastructure environments.

Understanding the inner workings of the DORA protocol and using smart terminal filters puts you in absolute control of your infrastructure. Practice these commands in a controlled setting, observe normal packet behavior on a healthy connection, and build the muscle memory needed to act quickly when the network decides to fail.