Option 43 is not being send after moving to a specific scope

[W.J.M. Nelis]

Hello,

> There is two things that need looking at, firstly when concatenating 
> option numbers to the dhcp-parameter-request-list you need to specify 
> them in hex, not decimal. So that is happily adding option number 0x43 
> (67) and 0x60 (96) to the list. If this were to be mentioned in the 
> documentation it would be the dhcp-eval man page...
>   
It can be found in the FAQ. I was wondering why it worked for so long. 
It turns out that the clients ask for those options themselves.

> The way this is frequently done is to define PXE options is using a 
> specific PXE class. Searching the archives should show a few examples of 
> this I think.
It has taken some time for tests, but I finally found why option 43 was 
*not* send in the more specific class scope. In the configuration there 
was also a line to define the layout of option 43 for an Aastra IP 
telephone. That line in question was:
option AastraIpPhoneOpt43 code 43 = string ;
This option definition is not yet used. Once the option definition was 
removed, option 43 was send to the PXE client. I do not know why it has 
this negative impact. Can someone shed some light on this issue?

>> we are using ISC dhcpd version 3.1.3. For PXE-clients there is a bit of
>> configuration to send them additional information in option 43. If the
>> PXE configuration is moved from the global scope to a specific scope,
>> option 43 is no longer send.
>>
>> The original configuration in the global scope is:
>>
>> option space PXE;
>> option PXE.discovery-control code 6 = unsigned integer 8 ;
>> option PXE.boot-server code 8 = { unsigned integer 16, unsigned integer
>> 8, ip-address } ;
>> option PXE.boot-menu code 9 = { unsigned integer 16, unsigned integer 8,
>> text } ;
>> option PXE.menu-prompt code 10 = { unsigned integer 8, text } ;
>>
>> server-name "deploy-os.nlr.nl" ;
>> option dhcp-parameter-request-list = concat ( option
>> dhcp-parameter-request-list, 60, 43 ) ;
>> option vendor-class-identifier "PXEClient" ;
>> vendor-option-space PXE ;
>> option PXE.discovery-control 7 ;
>> option PXE.boot-server 15 1 137.17.144.50 ;
>> option PXE.boot-menu 15 3 "NLR" ;
>> option PXE.menu-prompt 0 "R" ;
>>
>>
>> The modified configuration is:
>>
>> option space PXE ;
>> option PXE.discovery-control code 6 = unsigned integer 8 ;
>> option PXE.boot-server code 8 = { unsigned integer 16, unsigned integer
>> 8, ip-address } ;
>> option PXE.boot-menu code 9 = { unsigned integer 16, unsigned integer 8,
>> text } ;
>> option PXE.menu-prompt code 10 = { unsigned integer 8, text } ;
>>
>> class "vendor-classes" {
>> match option vendor-class-identifier ;
>> }
>> subclass "vendor-classes" "PXEClient:Arch:00000:UNDI:002001" {
>> option dhcp-parameter-request-list = concat ( option
>> dhcp-parameter-request-list, 60, 43 ) ;
>> #
>> vendor-option-space PXE ;
>> option PXE.discovery-control 7 ;
>> option PXE.boot-server 15 1 137.17.144.50 ;
>> option PXE.boot-menu 15 3 "NLR" ;
>> option PXE.menu-prompt 0 "R" ;
>> #
>> server-name "deploy-os.nlr.nl" ;
>> option vendor-class-identifier "PXEClient" ;
>> }
>>
>> Using a network sniffer, it is found that the servername
>> (deploy-os.nlr.nl) is added to the DHCP OFFER, and that the shorter
>> vendor-class-identifier (PXEClient) is send. However, there is no option
>> 43 in the DHCP OFFER. None of the other specific scopes, host and
>> subnet, do something with option 43.
>>
>> What is wrong in this configuration? Why is option 43 not included in
>> the replies?
>>     
Regards,
Wim Nelis.



*******************************************************************************************************
The NLR disclaimer (http://www.nlr.nl/emaildisclaimer) is valid for NLR e-mail messages.
*******************************************************************************************************