This section outlines techniques that can help you diagnose
and correct common problems with the BOOTP and TFTP servers.
Helpful Configuration
Changes |
 |
To make troubleshooting easier, configure your system as follows:
Ensure syslogd is configured to log daemon information messages
to the file /var/adm/syslog/syslog.log. To check this configuration, make sure /etc/syslog.conf includes one of the following lines:
*.info /var/adm/syslog/syslog.log |
or
daemon.info /var/adm/syslog/syslog.log |
Configure bootpd to start with debug logging set to level 2. This logging
level causes bootpd to log useful debugging messages about how it
is replying to BOOTP clients. Follow these steps to set the debug
log level:
Add the -d 2 option to the bootpd line in /etc/inetd.conf:
bootps dgram udp wait root /usr/lbin/bootpd bootpd -d 2 |
Reconfigure inetd with the following command:
Kill any bootpd daemon that is still running on your system. For example,
$ /usr/bin/ps -e | /usr/bin/grep bootpd
429 ? 0:00 bootpd
$ /usr/bin/kill 429 |
Common bootpd Problems |
|
If you experience a problem with bootpd, read through this section for possible remedies.
The problems listed in this section are ordered by symptom.
To view the information that bootpd places in the bootreply, enable a broadcast bootreply
by adding the ba tap to the client's /etc/bootptab entry. Use the bootpquery command to emulate the client's bootrequest:
bootpquery client_link_address -s servername |
bootpquery prints the reply it receives from the server,
which allows you to examine the information supplied to the client.
Remove the ba tag from the configuration entry once you've
verified the correctness of the bootreply.
Symptom:
The server's system log file /var/adm/syslog/syslog.log does not contain any log messages from /usr/lbin/bootpd showing that the server started. A ps -ef listing does not show a running /usr/lbin/bootpd.
Cause:
The server may not be started or it may not be receiving the
client's bootrequest.
Action:
Make sure that /etc/inetd.conf is configured correctly as documented earlier
in this chapter.
Ensure that you have reconfigured inetd with the command inetd -c.
Check inetd's logging in /var/adm/syslog/syslog.log to ensure inetd is configured to start bootpd.
Verify that the server will start by using the bootpquery command.
Check whether the client is on the same network
as the BOOTP server. If the client is not on the same network, ensure
that intervening BOOTP servers are configured to relay bootrequest broadcasts.
Symptom:
The system log /var/adm/syslog/syslog.log contains one of the following messages:
hardware address not found: hardware_address |
IP address not found: ip_address |
Cause:
bootpd does not have an entry in /etc/bootptab for this client's hardware address or
IP address.
Action:
Check the system log
for any indication of syntax errors for the client's configuration
entry. Correct the entry in /etc/bootptab and reboot the BOOTP client.
Ensure that the hardware address you specified for
the ha tag matches the hardware address that /usr/lbin/bootpd said it could not find. Correct the tag and reboot
the BOOTP client.
Ensure the hardware type tag ht has the correct value for the client. For example,
if you have specified ether but the client is reporting ieee in its bootrequest, bootpd will reject the request. Correct the tag and reboot
the BOOTP client.
Symptom:
The system log /var/adm/syslog/syslog.log contains a message that looks like this:
requested file not found: filename |
Cause:
The client specified filename as the boot file in its bootrequest, but bootpd could not find the file in the tftp directory.
Action:
Make sure that you have
configured tftpd with the entry in /etc/passwd for the user tftp.
Ensure that the requested file is present in the tftp directory, which is usually /home/tftpdir or in the directory specified with the tftpd command. If it is not, place the file in the directory
and reboot the BOOTP client. If the requested file exists in the
directory, be sure it is readable by the user tftp. (See “Common tftpd Problems”.)
Symptom:
The system log /var/adm/syslog/syslog.log contains the following message:
cannot route reply to client's_IP_address |
Cause:
The IP address you have specified for the client is one which
the server's system cannot reach directly.
Action:
Ensure you have specified
the correct IP address for the client in /etc/bootptab. Correct the entry and reboot the BOOTP client.
If the server is to reply directly to the client,
it must reside on the same network or subnet as the client. If the
client resides on another network, ensure that intervening servers
are configured to relay the bootrequests.
Ensure the IP address you have chosen for the client
is a valid IP address for the server's network.
Symptom:
The system log contains one or more of the following error
messages:
duplicate hardware address: link_address |
syntax error in entry for host hostname |
unknown symbol in entry for host hostname |
bad IP address for host hostname |
bad subnet mask for host hostname |
bad time offset for host hostname |
bad vendor magic cookie for host hostname |
bad reply broadcast address for host hostname |
Cause:
Any of these error messages means there are errors in the
configuration file entry for the client.
Action:
See “Error Logging” for an explanation of the
error message. Correct the appropriate field for the entry in
/etc/bootptab and reboot the BOOTP client. Use bootpquery to send a bootrequest to /usr/lbin/bootpd for the client whose entry you have corrected.
Check the system log /var/adm/syslog/syslog.log to see if the server replies. At debug level 2
(see “Helpful Configuration
Changes”), bootpd logs the following sequence of messages when it
responds to a bootrequest:
request from hardware address link_address |
found ip_address hostname |
vendor magic field is magic_cookie |
sending RFC1048-style reply |
Symptom:
The client does not receive configuration information for
the tags that pertain to RFC 1048 vendor information:
ds = domain_nameserver_addresses |
lg = log_server_addresses |
Tnnn = generic_information |
Cause:
Too many RFC-1048 options have been specified for the client's configuration
entry in /etc/bootptab. The BOOTP protocol allows only 64 bytes of "vendor
extension" information. When such extended information
is included in the bootreply, bootpd must also add a 4-byte vendor magic cookie to
the bootreply, a 1-byte tag indicating the end of the vendor information,
and a 1-byte or 2-byte tag for each field (depending on the format
of the field) along with the value of the tag itself. The total
size of the extended information you list for a client must not
exceed 64 bytes.
Action:
Ensure the configuration contains only the necessary information
to boot the client. Check the documentation for the BOOTP client
to find out which tags are necessary for configuration and which
tags are supported.
For example, if the client supports only one nameserver address,
there is no need to list three nameserver addresses with the ds tag. If the client does not support configuring
its host name with the hn tag, there is no reason to include it.
Common tftpd Problems |
|
If you experience a problem with tftpd, read through this section for possible remedies.
The problems listed in this section are ordered by symptom.
Symptom:
File transfer "timed out." inetd connection logging (enabled with the inetd -l command) does not show any connection to the TFTP
server.
Cause:
The TFTP server, tftpd, did not start.
Action:
Ensure /etc/inetd.conf is configured correctly as documented earlier
in this chapter.
Ensure you have reconfigured inetd with the command inetd -c.
As documented in “Configuring the BOOTP
Server”, verify
that the server is working by using tftp to transfer a small file. It might be helpful
to try the transfer from another node on your network rather than
from the server node itself.
If the server still fails to start when the client attempts
the file transfer, then you probably have a connectivity problem.
Refer to Installing and Administering LAN/9000 Software or
the BOOTP client manual (for example, HP 700/X documentation).
Symptom:
File transfer "timed out." The system log
contains one of the following messages:
Cause:
The TFTP server, tftpd, exited prematurely.
Action:
If you suspect that there is a problem on the network, you
can increase the per-packet retransmission and the total retransmission
timeouts used by tftpd. These timeouts are specified (in seconds) with
the -R or -T options. See the tftpd man page for more information.
The User tftp unknown message can also mean that the password database
entry for the user tftp is either missing or incorrect. Verify that the
entry exists and is correct, then try the transfer again.
If tftpd experiences a system call failure that causes
it to exit, it will log the name of the system call and the reason
for the system call failure. For more information about the reason
why it failed, refer to the system call in the HP-UX
Reference.
Symptom:
File transfer fails with File Not Found, No Such File or Directory, or TFTP Error Code 1 message.
Cause:
The file the client is attempting to read from or write to
the server does not exist within the home directory of the user tftp or in the path specified with the tftpd command.
Action:
Ensure the full path name that the client is requesting from
the server exists within the tftp directory or in a path specified with the tftpd command. For example, if the tftp directory is /home/tftpdir and the TFTP client is requesting the file /usr/lib/X11/700X/C2300A, the file must exist as /home/tftpdir/usr/lib/X11/700X/C2300A.
If no entry exists for the user tftp in the /etc/passwd file, you must specify at least one file or directory
with the tftpd command. Make sure that you specify the full path
name when attempting to get a file from a directory specified with
the tftpd command.
Symptom:
File transfer fails with Access Violation, Permission Denied, or TFTP Error Code 2 message.
Cause:
tftpd does not have permission to read the file.
Action:
If the transfer is a get operation where the client is attempting to read the
file from the server, then the server does not have read permissions on
the file that it is trying to send. Ensure that the file the client
is reading has read permissions for the user tftp. For example, if the client was attempting to
read the file named xterm, xterm should be mode 0400 and owned by the user tftp:
$ ll /home/tftpdir/xterm
-r-------- 1 tftp guest 438 May 10 1989 xterm |
If the transfer is a put operation (which is not something a BOOTP client will
be doing as part of the BOOTP protocol), then this message means that
the file did not have sufficient write permissions for the server
to write to the file. If the server is to receive a file, it must
already exist and be writeable by the user tftp. For example, if a tftp client is sending the file named fontlist, the file must be mode 0600 and owned by tftp:
$ ll /home/tftpdir/fonts
-rw------- 1 tftp guest 0 May 10 1989 fonts |
Error Logging |
|
This section explains the error messages that bootpd logs through syslogd. The three levels of error logging documented
in this section are as follows:
The bootpd debug level must be set for these messages to
be logged. Set the debug level using the -d option to bootpd.
The following messages are logged at the syslogd information log level.
exiting after time minutes of inactivity
If bootpd hasn't received a bootrequest within time minutes (the timeout set with the -t option), it issues this message and exits.
reading configuration_file
reading new configuration_file
bootpd is reading or rereading configuration information
from the indicated configuration_file.
read number entries from configuration_file
Shows that bootpd successfully read number configuration entries, including table continuation
entries, from the indicated configuration_file.
request from hardware address hardware_address
bootpd received a bootrequest from a client with the
indicated hardware_address. This message is logged at debug level 1.
request from IP addr ip_address
bootpd received a bootrequest from a client with the
indicated ip_address. This message is logged at debug level 1.
found ip_address hostname
bootpd located information for the specified client in
its configuration database. This message is logged at debug level
1.
broadcasting reply on ip_address
Shows the broadcast address that bootpd uses to reply to a client whose configuration
entry has the ba flag. This message is logged at debug level 2.
vendor magic field is magic_cookie
sending CMU-style reply
sending RFC1048-style reply
Shows which vendor magic cookie was sent in the client's
bootrequest and the corresponding vendor magic cookie used in the
bootreply. These messages are logged at debug level 2.
bootptab mtime is time
bootpd uses the indicated modification time to determine
if the configuration file has been modified and should be reread.
This message is logged at debug level 3.
There may be cases where bootpd receives a bootrequest but does not send a bootreply.
The reason is given in one of the following messages and logged
at the notice log level:
hardware address not found: hardware_address
bootpd could not find a configuration entry for the client
with the indicated hardware_address. If bootpd should know about the client that is booting,
ensure that you have correctly specified the client's hardware
address in the configuration file.
IP address not found: ip_address
bootpd could not find a configuration entry for the client
with the indicated ip_address. If bootpd should know about the client that is booting,
ensure that you have correctly specified the client's IP address
in the appropriate configuration file entry.
requested file not found: filename
The client requested the boot file filename, but bootpd could not locate it. Ensure that the boot file
the client is requesting is located in the tftp directory on the server system.
cannot route reply to ip_address
The IP address to which bootpd must send the bootreply is for a client or gateway
that is not on a directly connected network. Ensure that you have
specified a valid IP address for the client or gateway.
The following errors indicate problems with the configuration
file. They are logged at the error log level. If you see any of
these messages, you should correct the indicated configuration entry
in /etc/bootptab and try to reboot the BOOTP client:
bad bootp server address for host hostname
A value specified for the bp tag is invalid. Values can be individual IP addresses
separated by a space, and/or one or more network broadcast addresses.
bad hardware mask value for host hostname
The value for the hardware address mask tag hm was incorrectly formatted in the configuration
file entry for hostname. Correct the configuration entry and try to reboot
the BOOTP client. The subnet mask must be specified in hex.
bad hardware type for host hostname
The value specified for the ht tag is an unsupported hardware type. See the bootpd man page for a list of supported hardware types.
bad hostname: hostname
The name given in the hostname field was not a valid host name. Correct the host
name and try to reboot the BOOTP client. A valid host name consists
a letter followed by any number of letters, digits, periods, or
hyphens.
bad IP address for host hostname
One of the IP addresses listed for the ip tag or any tag requiring a list of IP addresses
is incorrectly formatted in the configuration file entry for hostname.
Correct the configuration entry and try to reboot the BOOTP
client. IP addresses must be specified in standard Internet "dot" notation. They
can use decimal, octal, or hexadecimal numbers. (Octal numbers begin
with 0, and hexadecimal numbers begin with 0x or 0X.) If more than
one IP address is listed, separate the addresses with white space.
bad reply broadcast address for host hostname
The address given for the ba tag was invalid or incorrectly formatted. Correct
the configuration entry and try to reboot the BOOTP client. Type man 1M bootpd for more information.
bad subnet mask for host hostname
The value for the subnet mask tag sm was incorrectly formatted in the configuration
file entry for hostname. Correct the configuration entry and try to reboot
the BOOTP client. The subnet mask must be specified as a single
IP address.
bad time offset for host hostname
The value for the to tag was not a valid number. Correct the configuration
entry and try to reboot the BOOTP client. The to value may be either a signed decimal integer or
the keyword auto, which uses the server's time zone offset.
bad vendor magic cookie for host hostname
The vendor magic cookie, specified with the vm tag, was incorrectly formatted. Correct the configuration
entry and try to reboot the BOOTP client. The vm tag can be one of the following values: auto, rfc1048, or cmu.
can't find tc=label
bootpd could not find a table continuation configuration
entry with the host field label. Correct the configuration entry and try to reboot the
BOOTP client. Type man 1M bootpd for more information.'
duplicate hardware address: hardware_address
More than one configuration entry was specified for the client
with the indicated hardware_address. Ensure that only one configuration entry exists
for the hardware address in /etc/bootptab. Then, try to reboot the BOOTP client.
missing ha values for host hostname
The hardware address must be specified in hex and must be
preceded by the ht tag. If the hm tag is specified, the ha and ht tags must also be specified.
syntax error in entry for host hostname
The configuration entry for the indicated host hostname is incorrectly formatted. Correct the configuration
entry and try to reboot the BOOTP client. Type man 1M bootpd for the correct syntax of the BOOTP configuration
file.
unknown symbol in entry for host hostname
The configuration entry contains an unknown tag or invalid character.
Correct the configuration entry and try to reboot the BOOTP client.
Type man 1M bootpd for the correct syntax of the BOOTP configuration
file.
