TCP/IP and Data Communications Administration Guide

Troubleshooting a DHCP Client

When troubleshooting a DHCP client, you must understand certain issues about configuring the client and client-server communication. DHCP may fail to configure the client properly, either because DHCP could not communicate with a server, or because, although configuration responses were received, they were incorrect. Problems can also occur later in the life of a DHCP lease if the client cannot renew its IP addresses.

Client Cannot Communicate With the Server

When a client and a server cannot communicate with each other, the consequences depend on whether or not the client has a configuration cached from an earlier DHCP transaction. If it has, and if the lease is still valid, the client will use the cached data to configure the interface.

However, because the client has received no outside confirmation that this configuration is valid, there is no guarantee that the IP address, router address, and other information are valid. If the interface is connected to a network other than the one on which the configuration was received, one of two things can happen. Either errors may appear when other network services are started, or it may be impossible to communicate with other hosts on the network.

On the other hand, if no cache with an unexpired lease exists, the interface is not configured.

DHCP Configurations Received Are Invalid

Configurations can be invalid for two reasons:

  1. The client determines by ARP that the IP address offered to it is in use elsewhere. In this case, the client will send a DHCPDECLINE message to the server. If the server offers more than two bad addresses, dhcpagent fails.

  2. The client gets offers, but when it tries to confirm them, the server sends a DHCPNAK message instead of a confirmation. If the client receives DHCPNAK messages more than twice, dhcpagent fails. This indicates a malfunctioning server.

Isolate the Problem to the Client or Server

Perform the following actions to isolate the problem to either the client or the server machine.

Problem

The DHCP server machine is not working.

Verification: Log in to another machine on the same subnet as the client, and use the ping command to try to reach the server.

Solution: Diagnose the problem on the server machine.

Problem

The DHCP server is not running.

Verification: Log in to the server and enter the command:


ps -ef | grep dhcp

Solution:

  1. Stop and restart the DHCP server.

  2. Enter the command:


    /etc/init.d/dhcp stop 
    

  3. Wait about 10 seconds. Then enter the command:


    /etc/init.d/dhcp start 
    

Problem

The boot process hangs during DHCP.

Verification: The interface is marked primary, but no valid DHCP transaction has occurred.

Solution: Interrupt DHCP by typing control-C. The boot continues.


Note -

Although booting continues, the host may be incorrectly configured for the networks to which it is attached.


Client Cannot Reach DHCP Server

Problem

After configuring the DHCP client software and rebooting the client, you are unable to reach a server on the network from the client. All DHCP network commands fail and you see messages that the client is trying to reach the DHCP server and failing.

Typical error messages include:


DHCP or BOOTP server not responding


A request to access nonexistent dhcp_network database: databasename in datastore: datastore.


No more IP addresses for network_address network.

Verification: To pinpoint exactly what the problem is, perform the following actions.

  1. Run the client in debug mode.

  2. Attempt to configure the interface manually to verify that the hardware is functioning.

  3. Run the DHCP server in debug mode.

  4. Use snoop to trace messages sent between the DHCP server and client.

  5. Find out if the problem is on the client or server machines.

  6. Look at the error message and choose a solution from the information below.

Run Client in Debug Mode

Run the client in debug mode. Refer to the documentation for the product you are running.

Solaris 2 Client:

  1. Invoke:


    /sbin/dhcpagent -d3
    

DOS Client

On a PC-NFS DOS client:

  1. Edit the AUTOEXEC.BAT file by replacing SNCLIENT with SNCLIENT /D.

  2. Reboot the client.

Configure the Interface Manually

After dhcpagent has been started in debug mode, you can try to configure an interface manually by typing:


ifconfig interface_name auto_dhcp

Packets that are sent, and any that are received, will be displayed.

Run the Server in Debug Mode

  1. Log in to the root account on a DHCP server on the same subnet as the client.

  2. Kill and restart the DHCP server in debug mode. For example:


    /etc/init.d/dhcp stop
    /usr/lib/inet/in.dhcpd -d -v
    
    Or, if the i option is present, enter the command in the following format:

    /usr/lib/inet/in.dhcpd -i interface_names -d -v
    

Use snoop to Monitor Network Traffic

  1. Log in to the root account on a DHCP server or BOOTP relay agent on the same subnet as the client.

  2. Use the snoop command to trace network traffic. For example:


    snoop -o /tmp/output udp port 67 or udp port 68
    
    or

    snoop -o /tmp/output udp port bootps or udp port bootpc
    
    plus the per-interface argument, if there is one.

  3. Boot the client and watch the network messages on the server.

  4. Type:


    snoop -i /tmp/output -x 0 -v
    
    to view the packet traces.

Look up Error Messages

Look at the output from running the in.dhcpd command in debug mode and use the error message or condition you see to find a solution from the information below.

Problem

You see one of the following error messages:


Datagram received on network device: le0


ICMP ECHO reply to OFFER candidate: ip_address disabling

Verification: Before the DHCP server offers an IP address to a client, it verifies that the IP address is not in use by pinging the IP address. If a client replies, the IP address is in use.

Solution: Make sure the IP addresses you configured are not already in use.

Problem

You see the following error message:


No more IP addresses for network_address network

Verification: There are no available IP addresses in the client's dhcp_network table.

Solution: Use the dhcpconfig command to allocate more IP addresses. If the DHCP daemon is monitoring multiple subnets, be sure the additional IP addresses are for the subnet where the client is located.

Problem

There is a bad client id: id_name in the dhcp_network database.

Verification: The client ID (MAC address) in the dhcp_network table is incorrect.

Solution: If you are using Ethernet, the client ID is 01 followed by the Ethernet address. Make sure that all letters in this address are capitalized. A 00 means the address has not been assigned.

Problem

You see the following error message:


Request to access nonexistent dhcp_network database: database_name in datastore: nisplus_datastore.

Verification: The dhcpconfig script did not create a dhcp_network table for a subnet during the configuration of the DHCP server. This can happen if you set up an isolated LAN, such as a server and two clients, as a test network.

Solution: Use the dhcpconfig command to initialize the dhcp_network table and new IP addresses.

Problem

You receive the error message:


Client client_id is trying to verify unrecorded address ip_address, ignored.

Verification: There are two possible reasons for getting this message:

  1. You can receive this message if your dhcp_network tables have been deleted. If you are using only the Solaris 2 DHCP server, then this is typically the reason.

  2. You can receive it if you are not using NIS+ for datastore, so information is not shared. Make sure that the server is sharing data.

If you have a group of heterogenous servers, then ignore this message.

Solution: Remove old cache files on the client by typing:


ifconfig interface_name dhcp release

Problem

DHCP is started, but some required network services will not start.

Verification: The DHCP server is not supplying the configurations required.

Solution: Find out why the server does not send the parameters that are required. Configure the server to do so.

Problem

DHCP is started, but certain network services, such as NIS and NIS+, report errors or hang. The host cannot communicate with other hosts on the network.

Verification: The dhcpagent command was unable to communicate with DHCP (presumably because DHCP was unavailable) and has used cached data.

Solution: Remove the cache. Type:


ifconfig interface_name dhcp release

Since removing the cache does not solve the problem of getting the proper configuration, the host may have to be configured by hand. At boot time, DHCP should be disabled by removing the trigger file by typing:


rm /etc/dhcp.interface_name

Problem

The client boots and works correctly, but the following message appears:


DHCP renewal on interface_name failed

Verification: DHCP is working, but dhcpagent cannot contact the server to extend the lease.

Solution: Find out why the server is not responding now. This could be because the router value configured in the dhcptab is incorrect or out of date for the client network.

Problem

Messages about failed DHCP renewals are received. Then the following message appears on the console:


DHCP lease expired on interface_name: interface is now down

Network services may hang at this point.

Verification: The lease has expired. The client has not been able to extend the lease after several attempts.

Solution: Find out why the server is not responding. Reboot the client.

Some Clients Do Not Boot From DHCP Server in BOOTP Compatability Mode

Problem

The DHCP daemon is running in BOOTP compatibility mode (-b option).

Verification: BOOTP does not use a lease time. The DHCP server looks for free addresses with the BOOTP flag set to allocate the BOOTP clients.

Solution: Allocate BOOTP addresses. Use dhcpconfig to change the daemon options.

Diagnose NIS+ Configuration Problems

Use the information below to fix errors in the configuration of the NIS+ name service that prevent the client from accessing a server during boot.

Problem

No name service is configured for the client in the dhcptab table.

Verification: Log in to the server and type the command:


dhtadm -P | grep ip_address

Check for entries such as NISdmain, DNSdmain, and NISservs. Make sure the addresses entered for them are correct. For example:


# dhtadm -P | grep 129.148.3.129.148.3.m:Subnet=255.255.255.0:Router=129.148.3.11: 
Broadcast=129.148.3.255:NISdmain="island.ocean":NISservs=129.148.3.3:


Note -

The line above actually appears on one line, instead of being broken into two.


Solution: Use dhtadm to change any incorrect addresses.

Problem

You are using NIS+ and the server is not running in NIS+ compatibility mode. NIS+ tables do not have read rights for the Nobody category, so NIS clients cannot access the information stored there.

Verification: Run the command:


nisls -l org_dir
to show permissions of .r---rmcdrmcdr---

Check whether the Y option is set for the rpc.nisd daemon. For example:


ps -deaf | grep nis

Solution:

  1. Log in to the NIS+ server as root.

  2. Enter the command:


    /usr/lib/nis/nisserver -r -Y -d domainname
    

Problem

An incorrect default router prevents the client from reaching a server on another network.

Verification: Make sure the router symbol definition in the dhcptab table is actually a router.

Solution: Use dhtadm to correct the route symbol in the table.

Problem

You are running NIS+ but DNS forwarding is not turned on for NIS clients.

Verification: Use the command:


ps -ef | grep rpc.nisd

A -B option means that NIS is running with DNS forwarding turned on. For example:


/usr/sbin/rpc.nisd -B

Solution: Start the NIS+ server in NIS compatibility mode with DNS forwarding enabled. For example:


/usr/sbin/rpc.nisd -YB

Diagnose Name Service Configuration Problems

Use the information below to fix errors in the configuration of the NIS name services that prevent the client from accessing a server during boot.

Problem

An incorrect default router prevents the client from reaching a server on another network.

Verification: Make sure the router symbol definition in the dhcptab table is actually a router. If there are problems with the default router, make corrections with server-based tools.

Solution: Use dhtadm to correct the route symbol in the table.

Problem

No name service is configured for the client in the dhcptab table. For clients, the name service must be DNS, NIS, or NIS+, and appropriate parameters must be provided to each client.

Verification: Check the network-specific macro relating to the client's configuration.

  1. Log in to the server and type the command:


    dhtadm -P
    

  2. Look for an entry that matches your client's network.

    Solution: Use dhtadm to correct the client's macro for the name service:

    If this is the first client on the network:

  1. Use dhtadm to correct the entries.

  2. Then type:


    /etc/init.d/dhcp stop, 
    /etc/rc3.d/S34dhcp start
    
    on the server and reboot the client.


    Note -

    The server does not dictate the name service choice to the client. The server only provides the relevant information. The client chooses its name service.


Macro Change Not Propagated to Client

You have changed one or more macros for a client with dhtadm, but the changes are not evident on your machine. For example, you changed the client's router, but the client is still using the old router.

Use the information below to solve the problem of changed client macros not showing up on the DHCP server.

Problem

The DHCP server was not reinitialized to read your changes to the dhcptab table. This must be done every time you change a macro definition.

Solution: Use the rescan option-set with dhcpconfig, or:

Reinitialize the DHCP server:

  1. Log in to the DHCP server as root.

  2. Enter:


    /etc/init.d/dhcp stop
    

  3. Restart the DHCP daemon by entering:


    /etc/init.d/dhcp start