Troubleshooting Mystery DHCP Requests on Linux Network

Overview

Problem Description

Repeated DHCP requests from unknown MAC address appearing in dnsmasq logs with the following characteristics:

• Rapid DHCP ACK/REQUEST cycle (every 2-8 seconds)
• MAC address with locally administered prefix (98:17:3c:1d:4c:52)
• Device never responds to ping or SSH
• Not visible in ARP tables
• Appears and disappears on seemingly random schedule

Initial Symptoms

Dec 22 21:28:23 dnsmasq-dhcp[1062]: DHCPACK(enp1s0) 192.168.0.170 98:17:3c:1d:4c:52 
Dec 22 21:28:25 dnsmasq-dhcp[1062]: DHCPREQUEST(enp1s0) 192.168.0.170 98:17:3c:1d:4c:52 
Dec 22 21:28:25 dnsmasq-dhcp[1062]: DHCPACK(enp1s0) 192.168.0.170 98:17:3c:1d:4c:52

Investigation Steps

Step 1: Check Logs and Lease Files

# Check when device last appeared
grep "98:17:3c:1d:4c:52" /var/log/dnsmasq.log | tail -1

# Check DHCP lease file
grep "98:17:3c" /var/lib/misc/dnsmasq.leases

Finding: Device shows in leases with * * for hostname and client ID (highly unusual)

Step 2: Monitor Network Traffic

# Capture all traffic from the MAC address
sudo tcpdump -i enp1s0 -n -vvv 'ether host 98:17:3c:1d:4c:52'

# Watch for DHCP specific traffic
sudo tcpdump -i enp1s0 -n -vvv -e '(port 67 or port 68) and ether host 98:17:3c:1d:4c:52'

Finding: Device receives PXE boot configuration but never attempts TFTP download

Step 3: Analyze Network Behavior

# Monitor all traffic from assigned IP
sudo tcpdump -i enp1s0 -n 'host 192.168.0.170' -c 50

# Check if device is reachable
ping 192.168.0.170
sudo nmap -sS -Pn 192.168.0.170

Finding: Device makes DNS queries for app.govee.com and time.google.com

Step 4: Identify Device Pattern

Key observations from packet capture:

• NULL Unnumbered frames being sent
• ARP requests for wrong subnet (192.168.1.80)
• DNS lookups for Govee services
• Gratuitous ARP for itself
• Gateway ARP requests fail

Root Cause Discovery

The device was identified as a Govee greenhouse monitor with weak WiFi signal:

1. Device located far from access point
2. Gets DHCP (broadcast traffic more resilient)
3. Cannot maintain stable connection for unicast traffic
4. Continuously restarts network stack trying to reconnect

Diagnostic Confirmation

# From router - intermittent ping responses confirm weak signal
ping 192.168.0.170
# Output shows some replies with high latency, many timeouts

# Rapid monitoring to catch working moments
while true; do 
  ping -c 1 -W 1 192.168.0.170 && echo "ALIVE at $(date)" && break
  sleep 0.5
done

Solution

Temporary Fix

• Move device closer to access point to confirm signal issue

Permanent Solutions

1. Install outdoor WiFi access point
   • Ubiquiti UniFi outdoor models
   • TP-Link EAP225-Outdoor
2. Add WiFi extender/repeater midway to device location
3. Use directional antenna on existing AP
4. Install powerline adapter if power available at remote location

Lessons Learned

• Locally administered MAC addresses (bit 2 set in first octet) often indicate:
  • Virtual interfaces
  • MAC randomization for privacy
  • IoT devices in special modes
• Rapid DHCP cycling typically indicates:
  • Network boot attempts
  • Weak WiFi signal
  • Corrupted firmware
  • Boot loops
• PXE boot responses don’t always mean intentional netboot
• Check physical location and signal strength for IoT devices before assuming malicious activity

Quick Reference For Commands Used

# Monitor specific MAC address
tcpdump -i enp1s0 -n 'ether host XX:XX:XX:XX:XX:XX'

# Check DHCP leases
cat /var/lib/misc/dnsmasq.leases

# Watch DHCP traffic
tcpdump -i enp1s0 -n 'port 67 or port 68'

# Check for PXE configuration
grep -E "pxe|tftp|dhcp-boot" /etc/dnsmasq.conf

# Monitor TFTP attempts
journalctl -u dnsmasq | grep -E "tftp|TFTP"