Linux dhcp client boot process with packets traffic

Hi Everybody,

I would like to know the entire network packets exchange, sequence between a linux dhcp client workstation & dhcp server as client comes up starting from OS booting stage as network service starts to the time client gets dhcp IP address. This would be in a typical LAN environment.

Thanks in advance

The client doesn't really have much at all to do before DHCP happens. Without an IP address, all it can do is broadcast or non-IP communication.

Here's a dump of packets between a client and my DHCP server at work as it boots. There were also some IPv6 packets in there but they're irrelevant since we don't actually use IPv6 at present.

# The first non-ipv6 packet.
# The client, 00:08:c7:77:9a:a2, broadcasts a DHCP request across the
# entire network segment.
10:14:29.584192 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:08:c7:77:9a:a2 (oui Unknown), length 300

# Our DHCP server, 00:23:54:d9:7f, gives a reply targeted specifically at
# 00:08:c7:77:9a:a2, to tell it to become IP 192.168.0.131.
# There may also be info such as default gateway, DNS servers,
# and PXE boot paths embedded in the reply.
10:14:29.584332 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype IPv4 (0x0800), length 342: xxxx.xxxx.xxx.bootps > 192.168.0.131.bootpc: BOOTP/DHCP, Reply, length 300

# Here the client requests again for good measure, and gets the same reply.
10:14:29.586406 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 351: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:08:c7:77:9a:a2 (oui Unknown), length 309
10:14:29.587720 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype IPv4 (0x0800), length 342: xxxx.xxxx.xxx.bootps > 192.168.0.131.bootpc: BOOTP/DHCP, Reply, length 300

# Here the client, 00:08:c7:77:9a:a2, broadcasts an ARP who-has request
# across the segment to check if the DHCP server has given us a boneheaded
# occupied IP address.  Some DHCP clients, like windows ones, don't seem to
# check this, causing IP address conflicts should the DHCP server get
# rebooted.
#
# The downside to this doublethink is time wasted.  A process that
# hypothetically could be nearly instant can take many seconds when the
# client is paranoid.
10:14:29.590811 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 0.0.0.0
10:14:30.748326 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 0.0.0.0
10:14:32.670568 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 0.0.0.0

# About 5 seconds after the DHCP server sent its DHCP reply to the client,
# it sends an ARP request directly to the client's MAC address asking what
# IP address it has.
10:14:34.586710 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype ARP (0x0806), length 42: arp who-has 192.168.0.131 tell xxx.xxx.xxx.xxx

# ...and does so again a second later.  The client missed the last one, busy contemplating the
# mysteries of life or something.
10:14:35.586665 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype ARP (0x0806), length 42: arp who-has 192.168.0.131 tell xxxx.xxxx.xxx

# The client sends an ARP reply directed to the DHCP server finally.
10:14:35.586921 00:08:c7:77:9a:a2 (oui Unknown) > 00:23:54:d9:7f:4e (oui Unknown), ethertype ARP (0x0806), length 60: arp reply 192.168.0.131 is-at 00:08:c7:77:9a:a2 (oui Unknown)

# This particular interface on the client is configured for two IP addresses:
# one gets set by DHCP, the other is statically set to 192.168.0.2.
#
# To be polite, the client broadcasts an ARP request asking if anyone else
# has 192.168.0.2.
10:14:36.023579 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.2 (Broadcast) tell 0.0.0.0
10:14:36.866266 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 192.168.0.131

# After one second, having received no answer, it asks again.
10:14:37.023771 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.2 (Broadcast) tell 0.0.0.0

# After here ARP requests are still sent to/from it from time to time but the interface is obviously already up.

Hi,

Thanks for the help, appreciate it.