This chapter provides information to help you solve problems that you might encounter when you configure a DHCP server or client. The chapter also helps you with problems you might have in using DHCP after configuration is complete.The chapter includes the following information:Troubleshooting DHCP Server Problems Troubleshooting DHCP Client Configuration Problems See Chapter 14, Configuring the DHCP Service (Tasks) for information about configuring your DHCP server. SeeEnabling and Disabling a Solaris DHCP Client for information about configuring your DHCP client. The problems that you might encounter when you configure the server fall into the following categories:NIS+ Problems and the DHCP Data Store IP Address Allocation Errors in DHCP If you use NIS+ as the DHCP data store, problems that you might encounter can be categorized as follows:Cannot Select NIS+ as the DHCP Data Store NIS+ Is Not Adequately Configured for DHCP Data Store NIS+ Access Problems for the DHCP Data Store If you try to use NIS+ as your data store, DHCP Manager might not offer NIS+ as a choice for the data store. If you use the dhcpconfig command, you might see a message stating that NIS+ does not appear to be installed and running. Both these symptoms mean that NIS+ has not been configured for this server, although NIS+ might be in use on the network. Before you can select NIS+ as a data store, the server system must be configured as an NIS+ client.Before you set up the DHCP server system as an NIS+ client, the following statements must be true:The domain must have already been configured. The NIS+ domain's master server must be running. The master server's tables must be populated. The hosts table must have an entry for the new client system, the DHCP server system. Setting Up NIS+ Client Machines in System Administration Guide: Naming and Directory Services (NIS+) provides detailed information about configuring an NIS+ client. After you successfully use NIS+ with DHCP, you might encounter errors if changes are made to NIS+. The changes could introduce configuration problems. Use the following explanations of problems and solutions to help you determine the cause of configuration problems.Root object does not exist in the NIS+ domain. Type the following command: /usr/lib/nis/nisstatThis command displays statistics for the domain. If the root object does not exist, no statistics are returned.Set up the NIS+ domain using the System Administration Guide: Naming and Directory Services (NIS+). NIS+ is not used for passwd and publickey information. Type the following command to view the configuration file for the name service switch:cat /etc/nsswitch.confCheck the passwd and publickey entries for the “nisplus” keyword. Refer to the System Administration Guide: Naming and Directory Services (NIS+) for information about configuring the name service switch. The domain name is empty. Type the following command:domainnameIf the command lists an empty string, no domain name has been set for the domain. Use local files for your data store, or set up an NIS+ domain for your network. Refer to the System Administration Guide: Naming and Directory Services (NIS+). The NIS_COLD_START file does not exist. Type the following command on the server system to determine if the file exists:cat /var/nis/NIS_COLD_STARTUse local files for your data store, or create an NIS+ client. Refer to the System Administration Guide: Naming and Directory Services (NIS+). NIS+ access problems might cause error messages about incorrect DES credentials, or inadequate permissions to update NIS+ objects or tables. Use the following explanations of problems and solutions to determine the cause of NIS+ access errors you receive.The DHCP server system does not have create access to the org_dir object in the NIS+ domain. Type the following command:nisls -ld org_dirThe access rights are listed in the form r---rmcdrmcdr---, where the permissions apply respectively to nobody, owner, group, and world. The owner of the object is listed next.Normally, the org_dir directory object provides full rights to both the owner and the group. Full rights consist of read, modify, create, and destroy. The org_dir directory object provides only read access to the world and nobody classes.The DHCP server name must either be listed as the owner of the org_dir object, or be listed as a principal in the group. The group must have create access. List the group with the command: nisls -ldg org_dirUse the nischmod command to change the permissions for org_dir if necessary. For example, to add create access to the group, you would type the following command:nischmod g+c org_dirSee the nischmod1 man page for more information. The DHCP server does not have access rights to create a table under the org_dir object.Usually, this problem means the server system's principal name is not a member of the owning group for the org_dir object, or no owning group exists. Type this command to find the owning group name:niscat -o org_dirLook for a line that is similar to:Group : "admin.example.com."List the principal names in the group using the command:nisgrpadm -l groupnameFor example, this command lists the principal names of the group admin.example.com:nisgrpadm -l admin.example.comThe server system's name should be listed as an explicit member of the group or included as an implicit member of the group. If necessary, add the server system's name to the group using the nisgrpadm command.For example, to add the server name pacific to the group admin.example.com, you would type the following command:nisgrpadm -a admin.example.com pacific.example.comSee the nisgrpadm1 man page for more information. The DHCP server does not have valid Data Encryption Standard (DES) credentials in the NIS+ cred table. If there is a credential problem, an error message states that the user does not have DES credentials in the NIS+ name service. Use the nisaddcred command to add security credentials for the DHCP server system.The following example shows how to add DES credentials for the system mercury in the domain example.com:nisaddcred -p unix.mercury@example.com \ -P mercury.example.com. DES example.com.The command prompts for the root password, which is required to generate an encrypted secret key.See the nisaddcred1M man page for more information. When a client attempts to obtain or verify an IP address, you might see problems logged to syslog or in server debugging mode output. The following list of common error messages indicates the possible causes and solutions.There is no n.n.n.n dhcp-network table for DHCP client's network A client is requesting a specific IP address or seeking to extend a lease on its current IP address. The DHCP server cannot find the DHCP network table for that address. The DHCP network table might have been deleted mistakenly. You can recreate the network table by adding the network again using DHCP Manager or the dhcpconfig command. ICMP ECHO reply to OFFER candidate: n.n.n.n, disabling The IP address considered for offering to a DHCP client is already in use. This problem might occur if more than one DHCP server owns the address. The problem might also occur if an address was manually configured for a non-DHCP network client. Determine the proper ownership of the address. Correct either the DHCP server database or the host's network configuration. ICMP ECHO reply to OFFER candidate: n.n.n.n. No corresponding dhcp network record. The IP address considered for offering to a DHCP client does not have a record in a network table. This error indicates that the IP address record was deleted from the DHCP network table after the address was selected. This error can only happen in the brief period before the duplicate address check is completed. Use DHCP Manager or the pntadm command to view the DHCP network table. If the IP address is missing, create the address with DHCP Manager by choosing Create from the Edit menu on the Address tab. You can also use pntadm to create the IP address. DHCP network record for n.n.n.nis unavailable, ignoring request. The record for the requested IP address is not in the DHCP network table, so the server is dropping the request. Use DHCP Manager or the pntadm command to view the DHCP network table. If the IP address is missing, create the address with DHCP Manager by choosing Create from the Edit menu on the Address tab. You can also use pntadm to create the address. n.n.n.n currently marked as unusable. The requested IP address cannot be offered because the address has been marked in the network table as unusable. You can use DHCP Manager or the pntadm command to make the address usable. n.n.n.n was manually allocated. No dynamic address will be allocated. The client ID has been assigned a manually allocated address, and that address is marked as unusable. The server cannot allocate a different address to this client. You can use DHCP Manager or the pntadm command to make the address usable, or manually allocate a different address to the client. Manual allocation (n.n.n.n, client ID) has n other records. Should have 0. The client that has the specified client ID has been manually assigned more than one IP address. A client should be assigned only one address. The server selects the last manually assigned address that is found in the network table. Use DHCP Manager or the pntadm command to modify IP addresses to remove the additional manual allocations. No more IP addresses on n.n.n.nnetwork. All IP addresses currently managed by DHCP on the specified network have been allocated. Use DHCP Manager or the pntadm command to create new IP addresses for this network. Client: clientid lease on n.n.n.n expired. The lease was not negotiable and timed out. The client should automatically restart the protocol to obtain a new lease. Offer expired for client: n.n.n.n The server made an IP address offer to the client, but the client took too long to respond and the offer expired. The client should automatically issue another discover message. If this message also times out, increase the cache offer time out for the DHCP server. In DHCP Manager, choose Modify from the Service menu. Client: clientid REQUEST is missing requested IP option. The client's request did not specify the offered IP address, so the DHCP server ignored the request. This problem might occur if you use a third-party DHCP client that is not compliant with the updated DHCP protocol, RFC 2131. Update the client software. Client: clientid is trying to renew n.n.n.n, an IP address it has not leased. The IP address for this client in the DHCP network table does not match the IP address that the client specified in its renewal request. The DHCP server does not renew the lease. This problem might occur if you delete a client's record while the client is still using the IP address. Use DHCP Manager or the pntadm command to examine the network table, and correct the client's record, if necessary. The client ID should be bound to the specified IP address. If the client ID is not bound, edit the address properties to add the client ID. Client: clientid is trying to verify unrecorded address: n.n.n.n, ignored. The specified client has not been registered in the DHCP network table with this address, so the request is ignored by this DHCP server.Another DHCP server on the network might have assigned this client the address. However, you might also have deleted the client's record while the client was still using the IP address. Use DHCP Manager or the pntadm command to examine the network table on this server and any other DHCP servers on the network. Make corrections, if necessary.You can also do nothing and allow the lease to expire. The client automatically requests a new address lease.If you want the client to get a new lease immediately, restart the DHCP protocol on the client by typing the following commands:ifconfig interface dhcp release ifconfig interface dhcp start The problems that you might encounter with a DHCP client fall into the following categories:Problems Communicating With the DHCP Server Problems With Inaccurate DHCP Configuration Information This section describes problems that you might encounter as you add DHCP clients to the network.After you enable the client software and reboot the system, the client tries to reach the DHCP server to obtain its network configuration. If the client fails to reach the server, you might see error messages such as the following: DHCP or BOOTP server not responding Before you can determine the problem, you must gather diagnostic information from both the client and the server. To gather information, you can perform the following tasks:How to Run the DHCP Client in Debugging Mode How to Run the DHCP Server in Debugging Mode How to Use snoop to Monitor DHCP Network Traffic You can do these things separately or concurrently.The information that you gather can help you determine if the problem is with the client, server, or a relay agent. Then, you can find a solution.If the client is not a Solaris DHCP client, refer to the client's documentation for information about how to run the client in debugging mode. If you have a Solaris DHCP client, use the following steps. Become superuser on the DHCP client system. Kill the DHCP client daemon.# pkill -x dhcpagent Restart the daemon in debugging mode.# /sbin/dhcpagent -d1 -f &The -d switch puts the DHCP client in debugging mode with level 1 verbosity. The -f switch causes output to be sent to the console instead of to syslog. Configure the interface to start DHCP negotiation.# ifconfig interface dhcp startReplace interface with the name of the network interface of the client, such as ge0.When run in debugging mode, the client daemon displays messages to your screen while performing DHCP requests. See Output from DHCP Client in Debugging Mode for information about client debugging mode output. Become superuser on the server system. Stop the DHCP server temporarily.# svcadm disable -t svc:/network/dhcp-serverYou can also use DHCP Manager or dhcpconfig to stop the server. Restart the daemon in debugging mode.# /usr/lib/inet/in.dhcpd -d -vYou should also use any in.dhcpd command-line options that you normally use when you run the daemon. For example, if you run the daemon as a BOOTP relay agent, include the -r option with the in.dhcpd -d -v command.When run in debugging mode, the daemon displays messages to your screen while processing DHCP or BOOTP requests. See Output from the DHCP Server in Debugging Mode for information about server debugging mode output. Become superuser on the DHCP server system. Start snoop to begin tracing network traffic across the server's network interface.# /usr/sbin/snoop -d interface -o snoop-output-filename udp port 67 or udp port 68For example, you might type the following command:# /usr/sbin/snoop -d hme0 -o /tmp/snoop.output udp port 67 or udp port 68snoop continues to monitor the interface until you stop snoop by pressing Control-C after you have the information that you need. Boot the client system, or restart the dhcpagent on the client system.How to Run the DHCP Client in Debugging Mode describes how to restart dhcpagent. On the server system, use snoop to display the output file with the contents of network packets:# /usr/sbin/snoop -i snoop-output-filename -x0 -vFor example, you might type the following command:# /usr/sbin/snoop -i /tmp/snoop.output -x0 -v See DHCP snoop Output for information about interpreting the output. The following example shows normal output when a DHCP client in debugging mode sends its DHCP request and receives its configuration information from a DHCP server./sbin/dhcpagent: debug: set_packet_filter: set filter 0x27fc8 (DHCP filter) /sbin/dhcpagent: debug: init_ifs: initted interface hme0 /sbin/dhcpagent: debug: insert_ifs: hme0: sdumax 1500, optmax 1260, hwtype 1, hwlen 6 /sbin/dhcpagent: debug: insert_ifs: inserted interface hme0 /sbin/dhcpagent: debug: register_acknak: registered acknak id 5 /sbin/dhcpagent: debug: unregister_acknak: unregistered acknak id 5 /sbin/dhcpagent: debug: set_packet_filter: set filter 0x26018 (ARP reply filter) /sbin/dhcpagent: info: setting IP netmask on hme0 to 255.255.192.0 /sbin/dhcpagent: info: setting IP address on hme0 to 10.23.3.233 /sbin/dhcpagent: info: setting broadcast address on hme0 to 10.23.63.255 /sbin/dhcpagent: info: added default router 10.23.0.1 on hme0 /sbin/dhcpagent: debug: set_packet_filter: set filter 0x28054 (blackhole filter) /sbin/dhcpagent: debug: configure_if: bound ifsp->if_sock_ip_fd /sbin/dhcpagent: info: hme0 acquired lease, expires Tue Aug 10 16:18:33 2006 /sbin/dhcpagent: info: hme0 begins renewal at Tue Aug 10 15:49:44 2006 /sbin/dhcpagent: info: hme0 begins rebinding at Tue Aug 10 16:11:03 2006 If the client cannot reach the DHCP server, you might see debugging mode output that is similar to the output shown in the following example./sbin/dhcpagent: debug: set_packet_filter: set filter 0x27fc8 (DHCP filter) /sbin/dhcpagent: debug: init_ifs: initted interface hme0 /sbin/dhcpagent: debug: select_best: no valid OFFER/BOOTP reply /sbin/dhcpagent: debug: select_best: no valid OFFER/BOOTP reply /sbin/dhcpagent: debug: select_best: no valid OFFER/BOOTP reply If you see this message, the client request never reached the server, or the server cannot send a response to the client. Run snoop on the server as described in How to Use snoop to Monitor DHCP Network Traffic to determine if packets from the client have reached the server. Normal server debugging mode output shows server configuration information followed by information about each network interface as the daemon starts. After daemon startup, the debugging mode output shows information about requests the daemon processes. Example 17–3 shows debugging mode output for a DHCP server that has just started. The server extends the lease for a client that is using an address owned by another DHCP server that is not responding.Daemon Version: 3.1 Maximum relay hops: 4 Transaction logging to console enabled. Run mode is: DHCP Server Mode. Datastore: nisplus Path: org_dir.dhcp.test..:dhcp.test..:$ DHCP offer TTL: 10 Ethers compatibility enabled. BOOTP compatibility enabled. ICMP validation timeout: 1000 milliseconds, Attempts: 2. Monitor (0005/hme0) started... Thread Id: 0005 - Monitoring Interface: hme0 ***** MTU: 1500 Type: DLPI Broadcast: 10.21.255.255 Netmask: 255.255.0.0 Address: 10.21.0.2 Monitor (0006/nf0) started... Thread Id: 0006 - Monitoring Interface: nf0 ***** MTU: 4352 Type: DLPI Broadcast: 10.22.255.255 Netmask: 255.255.0.0 Address: 10.22.0.1 Monitor (0007/qfe0) started... Thread Id: 0007 - Monitoring Interface: qfe0 ***** MTU: 1500 Type: DLPI Broadcast: 10.23.63.255 Netmask: 255.255.192.0 Address: 10.23.0.1 Read 33 entries from DHCP macro database on Tue Aug 10 15:10:27 2006 Datagram received on network device: qfe0 Client: 0800201DBA3A is requesting verification of address owned by 10.21.0.4 Datagram received on network device: qfe0 Client: 0800201DBA3A is requesting verification of address owned by 10.21.0.4 Datagram received on network device: qfe0 Client: 0800201DBA3A is requesting verification of address owned by 10.21.0.4 Datagram received on network device: qfe0 Client: 0800201DBA3A maps to IP: 10.23.3.233 Unicasting datagram to 10.23.3.233 address. Adding ARP entry: 10.23.3.233 == 0800201DBA3A DHCP EXTEND 0934312543 0934316143 10.23.3.233 10.21.0.2 0800201DBA3A SUNW.Ultra-5_10 0800201DBA3A Example 17–4 shows debugging mode output from a DHCP daemon that starts as a BOOTP relay agent. The agent relays requests from a client to a DHCP server, and relays the server's responses to the client.Relay destination: 10.21.0.4 (blue-servr2) network: 10.21.0.0 Daemon Version: 3.1 Maximum relay hops: 4 Transaction logging to console enabled. Run mode is: Relay Agent Mode. Monitor (0005/hme0) started... Thread Id: 0005 - Monitoring Interface: hme0 ***** MTU: 1500 Type: DLPI Broadcast: 10.21.255.255 Netmask: 255.255.0.0 Address: 10.21.0.2 Monitor (0006/nf0) started... Thread Id: 0006 - Monitoring Interface: nf0 ***** MTU: 4352 Type: DLPI Broadcast: 10.22.255.255 Netmask: 255.255.0.0 Address: 10.22.0.1 Monitor (0007/qfe0) started... Thread Id: 0007 - Monitoring Interface: qfe0 ***** MTU: 1500 Type: DLPI Broadcast: 10.23.63.255 Netmask: 255.255.192.0 Address: 10.23.0.1 Relaying request 0800201DBA3A to 10.21.0.4, server port. BOOTP RELAY-SRVR 0934297685 0000000000 0.0.0.0 10.21.0.4 0800201DBA3A N/A 0800201DBA3A Packet received from relay agent: 10.23.0.1 Relaying reply to client 0800201DBA3A Unicasting datagram to 10.23.3.233 address. Adding ARP entry: 10.23.3.233 == 0800201DBA3A BOOTP RELAY-CLNT 0934297688 0000000000 10.23.0.1 10.23.3.233 0800201DBA3A N/A 0800201DBA3A Relaying request 0800201DBA3A to 10.21.0.4, server port. BOOTP RELAY-SRVR 0934297689 0000000000 0.0.0.0 10.21.0.4 0800201DBA3A N/A 0800201DBA3A Packet received from relay agent: 10.23.0.1 Relaying reply to client 0800201DBA3A Unicasting datagram to 10.23.3.233 address. Adding ARP entry: 10.23.3.233 == 0800201DBA3A If there is a problem with DHCP, the debugging mode output might display warnings or error messages. Use the following list of DHCP server error messages to find solutions.ICMP ECHO reply to OFFER candidate: ip_address disabling Before the DHCP server offers an IP address to a client, the server pings the address to verify that the address is not in use. If a client replies, the address is in use. Make sure the addresses that you configured are not already in use. You can use the ping command. See the ping1M man page for more information. No more IP addresses on network-address network. No IP addresses are available in the DHCP network table associated with the client's network. Create more IP addresses with DHCP Manager or the pntadm command. If the DHCP daemon is monitoring multiple subnets, be sure the additional addresses are for the subnet where the client is located. See Adding IP Addresses to the DHCP Service for more information. No more IP addresses for network-address network when you are running the DHCP daemon in BOOTP compatibility mode. BOOTP does not use a lease time, so the DHCP server looks for free addresses with the BOOTP flag set to allocate to BOOTP clients. Use DHCP Manager to allocate BOOTP addresses. See Supporting BOOTP Clients With the DHCP Service (Task Map). Request to access nonexistent per network database: database-name in datastore: datastore. During configuration of the DHCP server, a DHCP network table for a subnet was not created. Use DHCP Manager or the pntadm command to create the DHCP network table and new IP addresses. See Adding DHCP Networks. There is no table-name dhcp-network table for DHCP client's network. During configuration of the DHCP server, a DHCP network table for a subnet was not created. Use DHCP Manager or the pntadm command to create the DHCP network table and new IP addresses. See Adding DHCP Networks. Client using non_RFC1048 BOOTP cookie. A device on the network is trying to access an unsupported implementation of BOOTP. Ignore this message, unless you need to configure this device. If you want to support the device, see Supporting BOOTP Clients With the DHCP Service (Task Map) for more information. In the snoop output, you should see that packets are exchanged between the DHCP client system and the DHCP server system. The IP address for each system is indicated in each packet. IP addresses for any routers or relay agents in the packet's path are also included. If the systems do not exchange packets, the client system might not be able to contact the server system at all. The problem is then at a lower level. To evaluate snoop output, you must know what the expected behavior is. For example, you must know if the request should be going through a BOOTP relay agent. You must also know the MAC addresses and the IP address of the systems involved so that you can determine if those values are as expected. If there is more than one network interface, you must know the addresses of the network interfaces as well.The following example shows normal snoop output for a DHCP acknowledgement message sent from the DHCP server on blue-servr2 to a client whose MAC address is 8:0:20:8e:f3:7e. In the message, the server assigns the client the IP address 192.168.252.6 and the host name white-6. The message also includes a number of standard network options and several vendor-specific options for the client.ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 26 arrived at 14:43:19.14 ETHER: Packet size = 540 bytes ETHER: Destination = 8:0:20:8e:f3:7e, Sun ETHER: Source = 8:0:20:1e:31:c1, Sun ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 526 bytes IP: Identification = 64667 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 254 seconds/hops IP: Protocol = 17 (UDP) IP: Header checksum = 157a IP: Source address = 10.21.0.4, blue-servr2 IP: Destination address = 192.168.252.6, white-6 IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 67 UDP: Destination port = 68 (BOOTPC) UDP: Length = 506 UDP: Checksum = 5D4C UDP: DHCP: ----- Dynamic Host Configuration Protocol ----- DHCP: DHCP: Hardware address type (htype) = 1 (Ethernet (10Mb)) DHCP: Hardware address length (hlen) = 6 octets DHCP: Relay agent hops = 0 DHCP: Transaction ID = 0x2e210f17 DHCP: Time since boot = 0 seconds DHCP: Flags = 0x0000 DHCP: Client address (ciaddr) = 0.0.0.0 DHCP: Your client address (yiaddr) = 192.168.252.6 DHCP: Next server address (siaddr) = 10.21.0.2 DHCP: Relay agent address (giaddr) = 0.0.0.0 DHCP: Client hardware address (chaddr) = 08:00:20:11:E0:1B DHCP: DHCP: ----- (Options) field options ----- DHCP: DHCP: Message type = DHCPACK DHCP: DHCP Server Identifier = 10.21.0.4 DHCP: Subnet Mask = 255.255.255.0 DHCP: Router at = 192.168.252.1 DHCP: Broadcast Address = 192.168.252.255 DHCP: NISPLUS Domainname = dhcp.test DHCP: IP Address Lease Time = 3600 seconds DHCP: UTC Time Offset = -14400 seconds DHCP: RFC868 Time Servers at = 10.21.0.4 DHCP: DNS Domain Name = sem.example.com DHCP: DNS Servers at = 10.21.0.1 DHCP: Client Hostname = white-6 DHCP: Vendor-specific Options (166 total octets): DHCP: (02) 04 octets 0x8194AE1B (unprintable) DHCP: (03) 08 octets "pacific" DHCP: (10) 04 octets 0x8194AE1B (unprintable) DHCP: (11) 08 octets "pacific" DHCP: (15) 05 octets "xterm" DHCP: (04) 53 octets "/export/s2/base.s2s/latest/Solaris_8/Tools/Boot" DHCP: (12) 32 octets "/export/s2/base.s2s/latest" DHCP: (07) 27 octets "/platform/sun4u/kernel/unix" DHCP: (08) 07 octets "EST5EDT" 0: 0800 208e f37e 0800 201e 31c1 0800 4500 .. .ó~.. .1...E. 16: 020e fc9b 4000 fe11 157a ac15 0004 c0a8 ....@....z...... 32: fc06 0043 0044 01fa 5d4c 0201 0600 2e21 ...C.D..]L.....! 48: 0f17 0000 0000 0000 0000 c0a8 fc06 ac15 ................ 64: 0002 0000 0000 0800 2011 e01b 0000 0000 ........ ....... 80: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 96: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 112: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 128: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 144: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 176: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 192: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 208: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 224: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 240: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 256: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 272: 0000 0000 0000 6382 5363 3501 0536 04ac ......c.Sc5..6.. 288: 1500 0401 04ff ffff 0003 04c0 a8fc 011c ................ 304: 04c0 a8fc ff40 0964 6863 702e 7465 7374 .....@.dhcp.test 320: 3304 0000 0e10 0204 ffff c7c0 0404 ac15 3............... 336: 0004 0f10 736e 742e 6561 7374 2e73 756e ....sem.example. 352: 2e63 6f6d 0604 ac15 0001 0c07 7768 6974 com.........whit 368: 652d 362b a602 0481 94ae 1b03 0861 746c e-6+.........pac 384: 616e 7469 630a 0481 94ae 1b0b 0861 746c ific.........pac 400: 616e 7469 630f 0578 7465 726d 0435 2f65 ific...xterm.5/e 416: 7870 6f72 742f 7332 382f 6261 7365 2e73 xport/sx2/bcvf.s 432: 3238 735f 776f 732f 6c61 7465 7374 2f53 2xs_btf/latest/S 448: 6f6c 6172 6973 5f38 2f54 6f6f 6c73 2f42 olaris_x/Tools/B 464: 6f6f 740c 202f 6578 706f 7274 2f73 3238 oot. /export/s2x 480: 2f62 6173 652e 7332 3873 5f77 6f73 2f6c /bcvf.s2xs_btf/l 496: 6174 6573 7407 1b2f 706c 6174 666f 726d atest../platform 512: 2f73 756e 346d 2f6b 6572 6e65 6c2f 756e /sun4u/kernel/un 528: 6978 0807 4553 5435 4544 54ff ix..EST5EDT. If a DHCP client receives inaccurate information in its network configuration information, look at the DHCP server data. You must examine the option values in the macros that the DHCP server processes for this client. Examples of inaccurate information might be the wrong NIS domain name or router IP address.Use the following general guidelines to help you determine the source of the inaccurate information:Look at the macros defined on the server as described in How to View Macros Defined on a DHCP Server (DHCP Manager). Review the information in Order of Macro Processing, and determine which macros are processed automatically for this client. Look at the network table to determine what macro (if any) is assigned to the client's IP address as the configuration macro. See Working With IP Addresses in the DHCP Service (Task Map) for more information. Take note of any options that occur in more than one macro. Make sure the value that you want for an option is set in the last processed macro. Edit the appropriate macro or macros to assure that the correct value is passed to the client. See Modifying DHCP Macros. This section describes problems that you might experience with DHCP clients that supply their own host names to be registered with DNS.If your client is not a Solaris DHCP client, consult the client's documentation to determine how to configure the client to request a host name. For Solaris DHCP clients, see How to Enable a Solaris Client to Request a Specific Host Name. The following list includes describes possible problems a client might have in getting its requested hostname, and suggested solutions.Client accepted an offer from a DHCP server that does not issue DNS updates. If two DHCP servers are available to the client, the servers should both be configured to provide DNS updates. See Enabling Dynamic DNS Updates by a DHCP Server for information about configuring the DHCP server and the DNS server.To determine whether the DHCP server is configured to provide DNS updates:Determine the IP address of the client's DHCP server. On the client system, use snoop or another application for capturing network packets. See How to Use snoop to Monitor DHCP Network Traffic, and perform the procedure on the client instead of the server. In the snoop output, look for the DHCP Server Identifier to get the IP address of the server. Log in to the DHCP server system to verify that the system is configured to make DNS updates. Type the following command as superuser:dhcpconfig -PIf UPDATE_TIMEOUT is listed as a server parameter, the DHCP server is configured to make DNS updates. On the DNS server, look at the /etc/named.conf file. Find the allow-update keyword in the zone section of the appropriate domain. If the server allows DNS updates by the DHCP server, the DHCP server's IP address is listed in the allow-update keyword. Client is using FQDN option to specify host name. Solaris DHCP does not currently support the FQDN option because the option is not officially in the DHCP protocol. On the server, use snoop or another application for capturing network packets. See How to Use snoop to Monitor DHCP Network Traffic. In the snoop output, look for the FQDN option in a packet from the client.Configure the client to specify host name using Hostname option. Hostname is option code 12. Refer to client documentation for instructions.For a Solaris client, see How to Enable a Solaris Client to Request a Specific Host Name DHCP server that makes an address offer to the client does not know the client's DNS domain. On the DHCP server look for the DNSdmain option with a valid value. Set the DNSdmain option to the correct DNS domain name in a macro that is processed for this client. DNSdmain is usually contained in the network macro. See Modifying DHCP Macros for information about changing values of options in a macro. The host name requested by client corresponds to an IP address that is not managed by the DHCP server. The Solaris DHCP server does not perform DNS updates for IP addresses that the server does not manage. Check syslog for one of the following messages from the DHCP server:There is no n.n.n.n dhcp-network table for DHCP client's network. DHCP network record for n.n.n.n is unavailable, ignoring request. Configure the client to request a different name. See How to Enable a Solaris Client to Request a Specific Host Name. Choose a name that is mapped to an address managed by the DHCP server. You can see address mappings in DHCP Manager's Addresses tab. Alternatively, choose an address that is not mapped to any IP address. The host name requested by client corresponds to an IP address that is currently not available for use. The address might be in use, leased to another client, or under offer to another client. Check syslog for the following message from the DHCP server: ICMP ECHO reply to OFFER candidate: n.n.n.n.Configure the client to choose a name corresponding to a different IP address. Alternatively, reclaim the address from the client that uses the address. DNS server is not configured to accept updates from the DHCP server. Examine the /etc/named.conf file on the DNS server. Look for the DHCP server's IP address with the allow-update keyword in the appropriate zone section for the DHCP server's domain. If the IP address is not present, the DNS server is not configured to accept updates from the DHCP server.See How to Enable Dynamic DNS Updating for DHCP Clients for information about configuring the DNS server.If the DHCP server has multiple interfaces, you might need to configure the DNS server to accept updates from all of the DHCP server's addresses. Enable debugging on the DNS server to see whether the updates are reaching the DNS server. If the DNS server received update requests, examine the debugging mode output to determine why the updates did not occur. See the in.named.1M man page for information about DNS debugging mode. DNS updates might not have completed in the allotted time. DHCP servers do not return host names to clients if the DNS updates have not completed by the configured time limit. However, attempts to complete the DNS updates continue. Use the nslookup command to determine whether the updates completed successfully. See the nslookup1M man page.For example, suppose the DNS domain is hills.example.org, and the DNS server's IP address is 10.76.178.11. The host name that the client wants to register is cathedral. You could use the following command to determine if cathedral has been registered with that DNS server:nslookup cathedral.hills.example.org 10.76.178.11If the updates completed successfully, but not in the allotted time, you need to increase the time out value. See How to Enable Dynamic DNS Updating for DHCP Clients. In this procedure, you should increase the number of seconds to wait for a response from the DNS server before timing out.