Preface
A straightforward DHCP troubleshooting case from Wireshark Sharkfest 2018’s “Point and ShootPacket” session. In Case 1, CATV Box, some hotel customers experienced normal startup of their CATV boxes, while others faced issues with boxes failing to start properly. This case highlights how DHCP problems can impact device connectivity in network environments.
For troubleshooting, the user captured two pcap files, one DHCP_SUCCESS and one DHCP_FAIL.
Problem Information
The basic information of the packet trace file is as follows:
λ capinfos 1_DHCP_*.pcap
File name: 1_DHCP_FAIL.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Number of packets: 6
File size: 2768 bytes
Data size: 2648 bytes
Capture duration: 4.421288 seconds
First packet time: 2014-01-17 10:45:26.485101
Last packet time: 2014-01-17 10:45:30.906389
Data byte rate: 598 bytes/s
Data bit rate: 4791 bits/s
Average packet size: 441.33 bytes
Average packet rate: 1 packets/s
SHA256: b16f09cd9fa72a2ea48ba46a5fa4afbbd6ea28f0053030843eef67e64447155d
RIPEMD160: 2ac9a830a3d8f8de6307dc444090da18ec695393
SHA1: c1e9422e185b5d2c1245810daa9851b70241221f
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 6
File name: 1_DHCP_SUCCESS.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Number of packets: 8
File size: 3930 bytes
Data size: 3778 bytes
Capture duration: 29.458387 seconds
First packet time: 2014-01-17 10:33:21.418832
Last packet time: 2014-01-17 10:33:50.877219
Data byte rate: 128 bytes/s
Data bit rate: 1025 bits/s
Average packet size: 472.25 bytes
Average packet rate: 0 packets/s
SHA256: 246baf09a06cdd9e6e62d9258a97c1997dd344973cfb225de118fd03b2b22b8c
RIPEMD160: 7249ed096edeaf41089b570405e3dcd8c8c9614c
SHA1: 9dd22cb49e6c606233f9ecd1d324557d6658b478
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 8The DHCP FAIL file was captured by Tcpdump without truncation, with only 6 packets captured, 4.4 seconds captured, and an average rate of 4791 bps; the DHCP SUCCESS file was also captured by Tcpdump without truncation, with 8 packets captured, 29.4 seconds captured, and an average rate of 1025 bps. In addition, there is no information in the expert information. In general, the packet tracking files should have been anonymized and accurately filtered, and only the packets related to the DHCP problem were retained.
Problem Analysis
In network protocol fault analysis, a frequently used method is the comparison method. By comparing the packet capture files during normal operation and those during the problem period , the problem can sometimes be quickly discovered. This case uses this method.
First, expand the DHCP SUCCESS packet information, as follows:
We can see that there are two complete and successful DHCP working processes, both of which went through the standard four stages of DHCP: Discover – Offer – Request – ACK.
The minor issue with the client and server IPs can be ignored here . The server is sometimes 192.168.2.1, sometimes 192.168.2.3, and the client IP is also 192.168.2.2. This may be because the packet trace file is not anonymized well enough.
At the same time, in the Info column, it is marked Transaction ID, what is Transaction ID?
In the DHCP message format, there is a 4-byte xid field, described as Transaction ID is a random number chosen by the client and used by the client and server to associate messages and responses between the two.
RFC 2131 The client generates and records a random transaction identifier and inserts that identifier into the ‘xid’ field. The server inserts the ‘xid’ field from the DHCPDISCOVER message into the ‘xid’ field of the DHCPOFFER message and sends the DHCPOFFER message to the requesting client.
It can be seen that each standard DHCP interaction process has the same DHCP Transaction ID.
λ tshark -r 1_DHCP_SUCCESS.pcap -T fields -e dhcp.id | uniq
0xfb0c077c
0xe1cb5e63
Now let’s look at the DHCP FAIL packet information, as follows:
We can see two failed DHCP interaction processes. After analyzing the successful cases, we can see that the problem obviously occurs in the DHCP Transaction ID . The Transaction ID carried in the two DHCP Offer messages returned by the DHCP server 192.168.100.1 is different from that generated by the client. This will cause the client to silently discard these data packets, and naturally it will not be able to obtain an IP address for communication.
If the ‘xid’ of an arriving DHCPOFFER message does not match the ‘xid’ of the most recent DHCPDISCOVER message, the DHCPOFFER message must be silently discarded. Any arriving DHCPACK messages must be silently discarded.
λ tshark -r 1_DHCP_FAIL.pcap -T fields -e frame.number -e dhcp.option.dhcp -e dhcp.id
1 1 0xea928400
2 2 0xd03e6d43
3 5 0x8044fd8d
4 1 0xea928400
5 2 0x402ddad8
6 5 0x402ddad8Summary of the problem
Of course, the ultimate cause of the problem is the incorrect behavior of the DHCP server (broadband router), such as some IOT devices using imperfect DHCP software implementation.