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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
