*** UNIX MANUAL PAGE BROWSER ***

client.pcy(4) Kernel Interfaces Manual client.pcy(4) NAME client.pcy - BOOTP and DHCP client policy DESCRIPTION client.pcy is a text database, read by joinc on startup, which governs the behavior of BOOTP and DHCP clients. If the variable JOINCONFIG is present in joinc's environment, it is taken to be the directory where client.pcy is housed; otherwise /etc/join is searched. Defaults exist for all parameters and switches, so it is not an error if the file does not exist. FORMAT Blank lines are ignored. The character '#' introduces a comment which continue to the next newline. Each new policy option must begin and end on a separate line. Policy options are introduced by a keyword, and may be boolean, or may take a value separated from the keyword by whitespace (but not a newline). If an option is present more than once, only the value attached to the last occurrence will be take effect - earlier value(s) will be forgotten. KEYWORDS AND VALUES accept_bootp If no DHCP re- sponses are heard, and this flag is set, the client will use any BOOTP re- sponse in con- fig- u- ra- tion. In this sce- nario, the client will not re- new, re- bind ex- pire or re- lease its IP ad- dress lease. In other words the client is given what is ef- fec- tively an in- fi- nite lease. Al- though the client will ac- cept BOOTP re- sponses, it will only send DHCP pack- ets. There is no guar- an- tee that BOOTP servers which hear these pack- ets will re- spond, since they may be- come con- fused by the pres- ence of DHCP data within the packet. This op- tion is not yet im- ple- mented. arp_timeout seconds When the client re- ceives an IP ad- dress from the server it will per- form an ARP on the lo- cal net- work to ver- ify than no other client is in fact us- ing the ad- dress. If it re- ceives no re- ply af- ter sec- onds ex- pires it as- sumes that it may use the ad- dress. De- fault: 2 sec- onds. class_id The client's class ID. Con- sult RFC1541 for de- tails. client_id Use a client iden- ti- fier other than the MAC ad- dress. Cur- rently set- ting client_id tells the DHCP client dae- mon to use a con- cate- na- tion of the MAC addr and the in- ter- face name as the client ID. The MAC addr is in in- ter- nal form, not the hu- man read- able colon sep- a- rated string. Note that you must use this op- tion when con- fig- ur- ing a client with mul- ti- ple in- ter- faces and where the client's MAC ad- dress is the same on each in- ter- face (SUN hard- ware for ex- am- ple). lease_desired seconds The DHCP server grants the client per- mis- sion to use a an IP ad- dress for a fixed pe- riod of time (which may be in- fi- nite). In the lan- guage of DHCP the client is granted a "lease" on the IP ad- dress. With this pa- ra- me- ter, the client may re- quest a lease of a par- tic- u- lar du- ra- tion, al- though servers are not bound to honor the re- quest. If the client doesn't care sec- onds should be set to zero; if an in- fi- nite lease is re- quired to mi- nus one, -1. Oth- er- wise spec- ify in sec- onds the lease du- ra- tion re- quired. De- fault: 0 retry_broadcast integer This pa- ra- me- ter is sub- tly dif- fer- ent from the num- ber of re- tries a client will make as part of an ex- po- nen- tial broad- cast retry back- off. Rather it is the num- ber of sep- a- rate at- tempts the client will make to con- tact a server, as- sum- ing that replies are re- ceived, but that the client, for one rea- son or an- other, re- jected those replies. De- fault: 2 timeouts value,value,value.... Clients are re- quired by the DHCP pro- to- col to im- ple- ment an ex- po- nen- tial re- trans- mis- sion and back- off when broad- cast- ing dis- cover or re- quest pack- ets. The ar- ray of val- ues spec- i- fies how long the client should wait for replies be- fore tim- ing out and retry- ing the broad- cast. Each time the client sends a DHCP pro- to- col packet it waits for a re- sponse un- til a time- out oc- curs af- ter an given by a mem- ber of this ar- ray (in sec- onds). If a time- out has oc- curred the packet is re- trans- mit- ted with the same XID (see RFC 1541) and the time- out is set to the next pos- i- tive num- ber in the comma sep- a- rated list. The last el- e- ment in the list is neg- a- tive or zero. At this the next ac- tion de- pends on op- tions to the dhcp- conf pro- gram. One op- tion is to fail. An- other is to retry for- ever. If the last value is neg- a- tive DHCP sus- pends con- fig- u- ra- tion of the in- ter- face for an amount of time given by the neg- a- tive num- ber ter- mi- nat- ing the ar- ray. Dur- ing this time the in- ter- face is con- sid- ered "idle" -- the client is not ex- pect- ing rep- sonses des- tined for the in- ter- face and will ig- nore any that ar- rive. When the idle time is over the client be- gins re- trans- mit- ting with a time- out given by the first el- e- ment in the ar- ray and a new XID. If the last value is zero the client con- tin- ues to use the same XID and time- out of the last pos- i- tive value in the ar- ray. De- fault: 4,8,16,32,0 use_saved_config If there is no re- ply to DHCP, and "use_saved_con- fig" is set, then use the con- fig- u- ra- tion stored in <in- ter- face>.cf from a pre- vi- ous in- oca- tion of the pro- to- col pro- vid- ing the lease is still valid. wait_before_broadcast seconds The DHCP pro- to- col re- quires clients to de- lay a ran- dom time in- ter- val on boot- ing, and af- ter each time- out, be- fore broad- cast- ing to the net. This is to pre- vent net- work "flood- ing" in the event of many clients all try- ing to con- fig- ure si- mul- ta- ne- ously (say af- ter a sitewide power- up). This pa- ra- me- ter is the max- i- mum de- lay that the client will tol- er- ate. The ac- tual de- lay is ran- domised from zero up to sec- onds. Note that on each time- out the client will also de- lay, and that the sec- ond and sub- se- quent de- lays are also ran- dom, and need not be the same as the first. De- fault: 10 sec- onds. request parameter_name There may be many in- stances of the re- quest key- word, each with a dif- fer- ent pa- ra- me- ter_name. Each pa- ra- me- ter that is con- fig- urable through DHCP and the server ex- ten- sions is iden- ti- fied by a unique pa- ra- me- ter Lim- ited size of DHCP pack- ets dic- tates that a client should not re- quest data which it can- not use. How- ever, dif- fer- ent DHCP servers, or dif- fer- ent server poli- cies may dic- tate that a server re- turn more con- fig- u- ra- tion that a client re- quested. For a de- scr- tip- tion of the mean- ing of the var- i- ous pa- ra- me- ters, con- sult RFC1542 and oth- ers to which it refers. Valid op- tions fol- low. The first group are DHCP generic: all_sub- nets_are_lo- cal arp_cache_time- out boot_file boot_file_server boot_size broad- cast_ad- dress cookie_server de- fault_ip_time- to- live dns_do- main_name dns_servers eth- er- net_en- cap- su- la- tion ex- ten- sions_path home_di- rec- tory host_name im- press_server in- ter- face_mtu ip_for- ward- ing keepalive_garbage lease_time log_server lpr_server mask_sup- plier max- i- mum_data- gram_re- assem- bly_size merit_dump_file name_server net- bios_data- gram_dis- tri- b- u- tion_server net- bios_name_server net- bios_node_type net- bios_scope nis_do- main_name nis_server non- lo- cal_source_rout- ing ntp_server path_mtu_ag- ing_time- out path_mtu_plateau_ta- ble per- form_mask_dis- cov- ery per- form_router_dis- cov- ery pol- icy_fil- ter re- bind- ing_time_value re- newal_time_value re- source_lo- ca- tion_server root_path router router_so- lic- i- ta- tion_ad- dress sta- tic_routes sub- net_mask swap_server tcp_de- fault_time_to_live tcp_keepalive_in- ter- val time_off- set time_server_(rfc_868) trailer_en- cap- su- la- tion x_win- dow_dis- play_man- ager x_win- dows_font_server The next are spe- cific to the DHCP server: nfs_mounted_file_sys- tems svr4_printer_setup print- ers RELATED INFORMATION joinc(8), DARPA Internet Request For Comments RFC1541, RFC1542. delim off client.pcy(4)