AIX Version 4.3 Differences Guide

7.4 Dynamic Host Configuration Protocol Enhancements (4.3.1)
A new command dadmin has been added to assist the DHCP administrator.
The dadmin command lets the DHCP administrator query and modify the state of
his DHCP servers’ databases. It gives the administrator the ability to locally or
remotely query the DHCP server for the status of an IP address, query for a pool
of IP addresses, query for a client, delete an IP address mapping, refresh the
server, and change the server’s tracing level. The dadmin command is backwards
compatible with previous AIX release DHCP servers to list their IP address status
and refresh.
When querying for IP address information, the dadmin command returns the IP
address’s status, and depending on this, may return the lease duration, start
lease time, last leased time, whether the server supports DNS A record updates
for this IP address, and the client identifier that is mapped to this IP address.
When querying for client information, the dadmin command returns the client’s IP
address and IP address status, whether the server supports DNS A record
updates for this IP address, the last time the client was given any IP address, and
the hostname and domain name used by the client.
When modifying the server tracing level, the dadmin command sets and returns
the server tracing level in the form of a tracing mask. This mask represents a bit
string, where each bit represents whether a specific log item is being traced by
the server (see DHCP Server Configuration in the online documentation). From
least significant to most significant order, these log items are LOG_NONE,
LOG_SYSERR, LOG_OBJERR, LOG_PROTOCOL and LOG_PROTERR (same
value), LOG_WARN and LOG_CONFIG (same value), LOG_EVENT and
LOG_PARSEERR (same value), LOG_ACTION, LOG_INFM, LOG_ACNTING,
LOG_STAT, LOG_TRACE, LOG_START, and LOG_RTRACE.
7.5 TFTP Block Size Option (4.3.1)
The implementation of TFTP in AIX Version 4.3.1 has been enhanced to include
the Block Size Option proposed in RFC 1783. Older implementations of TFTP
relied upon a fixed block size of 512 octets that although easy to code and
implement in the limited ROM space available in some clients, proves to be very
inefficient on LANs whose MTU size may be 1500 octets or more.
This implementation of TFTP has modified the TFTP Read Request and TFTP
Write Request packets to include a block size option. When a client sends a read
or write request, it can now include an option to request that the server uses a
block size other than 512 octets. If the server is willing to accept the blocksize
option, it responds with an Option Acknowledgment (OACK) containing the
blocksize that must be equal to, or smaller than, that requested by the client. If
the client is unable to accept the blocksize returned by the server, it must reply
with an error packet and terminate the transfer.
Tests on the performance of TFTP with different blocksizes have revealed that file
transfer time can be reduced by as much as 80 percent by using larger block
sizes.
Networking Enhancements 167