Re: interpretting DHCP Client messages
Emma writes:
> I'm curious to know what's actually happening when I pull up my
> wireless ethernet connection. Below is what I do and then what I
> see. I don't understand what the DHCPOFFERS received means. This
> seems to be the longest part of the connection.
Hi Emma,
This is from http://www.ietf.org/rfc/rfc2131.txt and while I was going
to paraphrase it, a hefty copy and paste seems best:
The following summary of the protocol exchanges between clients and
servers refers to the DHCP messages described in table 2. The
timeline diagram in figure 3 shows the timing relationships in a
typical client-server interaction. If the client already knows its
address, some steps may be omitted; this abbreviated interaction is
described in section 3.2.
1. The client broadcasts a DHCPDISCOVER message on its local physical
subnet. The DHCPDISCOVER message MAY include options that suggest
values for the network address and lease duration. BOOTP relay
agents may pass the message on to DHCP servers not on the same
physical subnet.
2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other
configuration parameters in DHCP options). Servers need not
reserve the offered network address, although the protocol will
work more efficiently if the server avoids allocating the offered
network address to another client. When allocating a new address,
servers SHOULD check that the offered network address is not
already in use; e.g., the server may probe the offered address
with an ICMP Echo Request. Servers SHOULD be implemented so that
network administrators MAY choose to disable probes of newly
allocated addresses. The server transmits the DHCPOFFER message
to the client, using the BOOTP relay agent if necessary.
Table 2: DHCP messages
Message Use
------- ---
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPOFFER - Server to client in response to DHCPDISCOVER with
offer of configuration parameters.
DHCPREQUEST - Client message to servers either (a) requesting
offered parameters from one server and implicitly
declining offers from all others, (b) confirming
correctness of previously allocated address after,
e.g., system reboot, or (c) extending the lease on a
particular network address.
DHCPACK - Server to client with configuration parameters,
including committed network address.
DHCPNAK - Server to client indicating client's notion of network
address is incorrect (e.g., client has moved to new
subnet) or client's lease as expired
DHCPDECLINE - Client to server indicating network address is already
in use.
DHCPRELEASE - Client to server relinquishing network address and
cancelling remaining lease.
DHCPINFORM - Client to server, asking only for local configuration
parameters; client already has externally configured
network address.
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
> debian:/home/emmajane# ifup eth0
> Internet Software Consortium DHCP Client 2.0pl5
> Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
> All rights reserved.
>
> Please contribute if you find this software useful.
> For info, please visit http://www.isc.org/dhcp-contrib.html
>
> Listening on LPF/eth0/00:00:e2:8d:22:8b
> Sending on LPF/eth0/00:00:e2:8d:22:8b
> Sending on Socket/fallback/fallback-net
> DHCPREQUEST on eth0 to 255.255.255.255 port 67
> DHCPREQUEST on eth0 to 255.255.255.255 port 67
Possibly trying to extend its lease.
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Trying to gain a new lease on an IP address. The response may also
include DNS servers, a gateway router's IP address, etc.
> No DHCPOFFERS received.
Fails to obtain a new lease.
> Trying recorded lease 192.168.1.100
Goes back to an older, recorded lease.
> PING 192.168.1.1 (192.168.1.1): 56 data bytes
>
> --- 192.168.1.1 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max = 5.8/5.8/5.8 ms
> bound: renewal in 43013 seconds.
[ moved text from letter ]
> Is there a way to optomize this so that it takes less time?
You could possibly instruct the DHCP client to use a longer lease
time which may or may not work depending on how the network
administrator has the DHCP server set up. From the looks of things, it
appears there may be *no* DHCP server up, or if there is one, it is
not replying in a method your DHCP client is able to read.
In my opinion, the best way to troubleshoot this is to run tcpdump
on another virtual console and watch what happens as your DHCP client
sends out DHCPDISCOVER messages. It could be that the DHCP server is
responding, but your client isn't reading it for some reason.
There are alternative DHCP clients as well, such as pump and
dhcpcd. I personally have had the most success with dhcpcd and, in
general, consider it a better DHCP client.
HTH, Elizabeth
Reply to: