MAN page from Mandriva 2010 dhcp-client-4.1.1-6mdv2010.1.i586.rpm
Section: Maintenance Commands (8)Index
dhclient-script - DHCP client network configuration script
The DHCP client network configuration script is invoked from time totime by dhclient(8)
. This script is used by the dhcp client toset each interface's initial configuration prior to requesting anaddress, to test the address once it has been offered, and to set theinterface's final configuration once a lease has been acquired. If nolease is acquired, the script is used to test predefined leases, ifany, and also called once if no valid lease can be identified.
This script is not meant to be customized by the end user. If localcustomizations are needed, they should be possible using the enter andexit hooks provided (see HOOKS for details). These hooks will allow theuser to override the default behaviour of the client in creating a/etc/resolv.conffile.
No standard client script exists for some operating systems, even thoughthe actual client may work, so a pioneering user may well need to createa new script or modify an existing one. In general, customizations specificto a particular computer should be done in theETCDIR/dhclient.conffile. If you find that you can't make such a customization withoutcustomizingETCDIR/dhclient.confor using the enter and exit hooks, please submit a bug report.
When it starts, the client script first defines a shell function,make_resolv_conf ,
which is later used to create the/etc/resolv.conf
file. To override the default behaviour, redefine this function inthe enter hook script.
On after defining the make_resolv_conf function, the client script checksfor the presence of an executableETCDIR/dhclient-enter-hooksscript, and if present, it invokes the script inline, using the Bourneshell '.' command. The entire environment documented under OPERATIONis available to this script, which may modify the environment if neededto change the behaviour of the script. If an error occurs during theexecution of the script, it can set the exit_status variable to a nonzerovalue, andCLIENTBINDIR/dhclient-scriptwill exit with that error code immediately after the client script exits.
After all processing has completed,CLIENTBINDIR/dhclient-scriptchecks for the presence of an executableETCDIR/dhclient-exit-hooksscript, which if present is invoked using the '.' command. The exitstatus of dhclient-script will be passed to dhclient-exit-hooks in theexit_status shell variable, and will always be zero if the scriptsucceeded at the task for which it was invoked. The rest of theenvironment as described previously for dhclient-enter-hooks is alsopresent. TheETCDIR/dhclient-exit-hooksscript can modify the valid of exit_status to change the exit statusof dhclient-script.
When dhclient needs to invoke the client configuration script, itdefines a set of variables in the environment, and then invokesCLIENTBINDIR/dhclient-script.
In all cases, $reason is set to the name of the reason why the scripthas been invoked. The following reasons are currently defined:MEDIUM, PREINIT, BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL, STOP, RELEASE,NBI and TIMEOUT.
The DHCP client is requesting that an interface's media typebe set. The interface name is passed in $interface, and the mediatype is passed in $medium.
The DHCP client is requesting that an interface be configured asrequired in order to send packets prior to receiving an actualaddress. For clients which use the BSD socket library, this meansconfiguring the interface with an IP address of 0.0.0.0 and abroadcast address of 255.255.255.255. For other clients, it may bepossible to simply configure the interface up without actually givingit an IP address at all. The interface name is passed in $interface,and the media type in $medium.
If an IP alias has been declared in dhclient.conf, its address will bepassed in $alias_ip_address, and that ip alias should be deleted fromthe interface, along with any routes to it.
The DHCP client has done an initial binding to a new address. Thenew ip address is passed in $new_ip_address, and the interface name ispassed in $interface. The media type is passed in $medium. Anyoptions acquired from the server are passed using the option namedescribed in dhcp-options
, except that dashes ('-') are replacedby underscores ('_') in order to make valid shell variables, and thevariable names start with new_. So for example, the new subnet maskwould be passed in $new_subnet_mask.
Before actually configuring the address, dhclient-script shouldsomehow ARP for it and exit with a nonzero status if it receives areply. In this case, the client will send a DHCPDECLINE message tothe server and acquire a different address. This may also be done inthe RENEW, REBIND, or REBOOT states, but is not required, and indeedmay not be desirable.
When a binding has been completed, a lot of network parameters arelikely to need to be set up. A new /etc/resolv.conf needs to becreated, using the values of $new_domain_name and$new_domain_name_servers (which may list more than one server,separated by spaces). A default route should be set using$new_routers, and static routes may need to be set up using$new_static_routes.
If an IP alias has been declared, it must be set up here. The aliasIP address will be written as $alias_ip_address, and other DHCPoptions that are set for the alias (e.g., subnet mask) will be passedin variables named as described previously except starting with$alias_ instead of $new_. Care should be taken that the alias IPaddress not be used if it is identical to the bound IP address($new_ip_address), since the other alias parameters may be incorrectin this case.
When a binding has been renewed, the script is called as in BOUND,except that in addition to all the variables starting with $new_,there is another set of variables starting with $old_. Persistentsettings that may have changed need to be deleted - for example, if alocal route to the bound address is being configured, the old localroute should be deleted. If the default route has changed, the old defaultroute should be deleted. If the static routes have changed, the oldones should be deleted. Otherwise, processing can be done as withBOUND.
The DHCP client has rebound to a new DHCP server. This can be handledas with RENEW, except that if the IP address has changed, the ARPtable should be cleared.
The DHCP client has successfully reacquired its old address after areboot. This can be processed as with BOUND.
The DHCP client has failed to renew its lease or acquire a new one,and the lease has expired. The IP address must be relinquished, andall related parameters should be deleted, as in RENEW and REBIND.
The DHCP client has been unable to contact any DHCP servers, and anyleases that have been tested have not proved to be valid. Theparameters from the last lease tested should be deconfigured. Thiscan be handled in the same way as EXPIRE.
The dhclient has been informed to shut down gracefully, thedhclient-script should unconfigure or shutdown the interface asappropriate.
The dhclient has been executed using the -r flag, indicating that theadministrator wishes it to release its lease(s). dhclient-script shouldunconfigure or shutdown the interface.
No-Broadcast-Interfaces...dhclient was unable to find any interfacesupon which it believed it should commence DHCP. What dhclient-scriptshould do in this situation is entirely up to the implementor.
The DHCP client has been unable to contact any DHCP servers.However, an old lease has been identified, and its parameters havebeen passed in as with BOUND. The client configuration script shouldtest these parameters and, if it has reason to believe they are valid,should exit with a value of zero. If not, it should exit with anonzero value.
The usual way to test a lease is to set up the network as with REBIND(since this may be called to test more than one lease) and then pingthe first router defined in $routers. If a response is received, thelease must be valid for the network to which the interface iscurrently connected. It would be more complete to try to ping all ofthe routers listed in $new_routers, as well as those listed in$new_static_routes, but current scripts do not do this.
Each operating system should generally have its own script file,although the script files for similar operating systems may be similaror even identical. The script files included in InternetSystems Consortium DHCP distribution appear in the distribution treeunder client/scripts, and bear the names of the operating systems onwhich they are intended to work.
If more than one interface is being used, there's no obvious way toavoid clashes between server-supplied configuration parameters - forexample, the stock dhclient-script rewrites /etc/resolv.conf. Ifmore than one interface is being configured, /etc/resolv.conf will berepeatedly initialized to the values provided by one server, and thenthe other. Assuming the information provided by both servers isvalid, this shouldn't cause any real problems, but it could beconfusing.
has been written for Internet Systems Consortiumby Ted Lemon in cooperation with VixieEnterprises. To learn more about Internet Systems Consortium,seehttps://www.isc.org.
To learn more about VixieEnterprises, seehttp://www.vix.com.
- SEE ALSO
This document was created byman2html,using the manual pages.