03 IT support · DHCP · Packet evidence
DHCP failure isolation
A controlled DHCP run separates a missing offer, incorrect lease options, and two servers answering the same transaction.
- Issue
- Did the client receive no offer, accept incorrect network options, or choose between two DHCP servers?
- Decisive evidence
- The captures show three distinct conditions: no offer returned, incorrect router and DNS options, and two servers answering one transaction.E01
- Result
- The packet sequence separates no response, incorrect lease options, and two responding servers.
- Boundary
- This is an isolated Linux service and client lab.Full limit
- Completion
- Complete within stated scope
- Execution
- Isolated ARM64 Linux packet lab
- Review
- Analyzer replay and manifest review
- Evidence
- Selected evidence on this page
- Kea DHCP
- BusyBox udhcpc
- TShark
- Linux namespaces
Project scope
What was built and checked.
Project record: Isolated service and client states, each packet exchange, the DHCP fields that distinguish the failures, and a post-correction capture.
Interactive view
Read the exchange before changing the service.
The same client symptom can stop at a different packet or complete with the wrong options.
One server completes the four-message exchange with the reviewed router and DNS values.
- 01DiscoverClient asks for a leasenormal
- 02OfferServer proposes an addressnormal
- 03RequestClient selects an offernormal
- 04ACKServer confirms optionsnormal
The Discover leaves the client, but no server Offer returns.
- 01DiscoverClient asks for a leasenormal
- 02OfferServer proposes an addressfailed
- 03RequestClient selects an offerunknown
- 04ACKServer confirms optionsunknown
The exchange completes, but the router and DNS fields differ from the expected service state.
- 01DiscoverClient asks for a leasenormal
- 02OfferServer proposes an addresschanged
- 03RequestClient selects an offernormal
- 04ACKServer confirms optionschanged
Two Offers answer one transaction, identifying a competing service rather than a silent server.
- 01DiscoverClient asks for a leasenormal
- 02OfferServer proposes an addresschanged
- 03RequestClient selects an offerchanged
- 04ACKServer confirms optionsunknown
Packet workflow
Read the exchange before changing the service.
- 01
Capture the complete client exchange inside an isolated lab with no default route.
- 02
Change one server condition at a time.
- 03
Read the message type, transaction, server identifier, router, and DNS fields.
- 04
Restore the intended service state and capture a new expected four-message exchange.
Evidence from the lab
The checks used to reach the conclusion.
Selected outputs from the lab. Sensitive and unnecessary details are omitted.
Finding types : none
DORA : complete
Router : 198.51.100.1
DNS : 198.51.100.10Finding : no_offer
Discover : present
Offer : absent
Capture state : completeDORA : complete
Observed router : 198.51.100.254
Observed DNS : 192.0.2.53
Finding : incorrect_optionFull evidence archive2 additional artifacts+
Offer servers : 198.51.100.2, 198.51.100.3
Selected : 198.51.100.2
Findings : competing_offers, incorrect_optionFinding types : none
DORA : complete
Selected : 198.51.100.2
Router / DNS : expectedResult and limits
What changed, and what this lab does not prove.
Result
The captured exchanges separated an absent response, a completed lease with incorrect options, and a transaction with two responding servers. A clean repeat restored one expected offer with the reviewed router and DNS values.
Limit
This is an isolated Linux service and client lab. Public downloads are sanitized analyzer records derived from private captures. It does not claim Windows client behavior, relay testing, or production DHCP administration.
Claims and evidence