DHCP option 85 (Preferred Server) is not correctly handled
(Last modified: 06May2003)
This document (10065177) is provided subject to the disclaimer at the end of this document.
goal
DHCP option 85 (Preferred Server) is not correctly handled
symptom
DHCP option 85 is configured with a list of IP addresses of preferred servers that the client can use. This way when the first server in the preferred server list is unavailable, the client will try the next one in the list.
- This does not work with Windows 2000 SP1 and Windows 2000 SP2
- This works fine with Windows 95/98 with Novell client v3.3
- This works fine with Windows NT 4.0 with Novell client 4.8 SP3
After analyzing traces, we could see that Option 85 with multiple IP addresses is sent to the client, but in Windows 2000, the Novell client only takes notice of the first address in the list, completely ignoring any of the addresses following. So, if the first server in the list is unavailable, then it does not attempt to look for the next server(s) in the list. The result of this is that the client will fail to login in, if the first server in the preferred server list is unavailable.
cause
The root cause for this Problem is that the registry key for tree / context / server is created with the wrong type.
This has been caused by nwsetup.dll, which was configuring the Microsoft DHCP service to store the corresponding data from the DHCP options 85-87 into our location profile registry key as binary keys. We then told the DHCP service to create those keys as binary, but this is wrong as they are supposed to be string values. For the current client, version 4.80 w/ SP3 for Windows NT 4.0, we can tell the Microsoft DHCP Client Service to get option 85 (as well as Option 86 and 87) for us and have it put the data into one of our location profiles registry key.
On Microsoft Windows 2000, this mechanism does not work the same way as on any previous version of Windows NT. This means currently this work with Windows NT 4 only. So, the data received for option 85 will only be used by the client login. At the moment, the login reads the first IP address only, even though there might be more available.
When the DHCP service retrieves the data for option 85, it needs to create the registry key as a "Binary" type and put down every IP address in this list as four bytes. This means for one IP address you get 4 bytes, for two IP addresses bytes and so on. If the entry was created manually through the UI, the value type is "String". If the value type is "Binary", login knows that the data came from the DHCP service and will parse the key data accordingly.
Here are the requirements so that the mentioned service at the end of this document will work with multiple IP addresses:
- The DHCP server needs to be configures to send option 85 as an array of IP addresses and
- The DHCP client needs to be configured to request option 85 and to store it as "Binary".
You enable the DHCP options through the client properties page, but you need to verify that
HKLM\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\Options\85 (DWORD)"KeyType" is set to 0x00000003.
The key "RegLocation" (String) will point you to the registry key that you need to look at.
The new service will read the registry key "Server" from the location profile (see above how to find the location in the registry) and if the type is "Binary", then it knows to parse it in binary mode. If the type is "String", it will simply use this string as it is. If the type is "Binary" and there is only one entry, login will convert it to a string and use it.
If the type is "Binary" and there is more then one IP address, login will ping the IP addresses in the order in which they are stored in the registry. The first IP address that successfully replies to the ping will be used. If no ping to any IP address is successful, login uses the first one in the list. The ping timeout is currently set to 1000ms (TTL is set to 32). This means if there are three IP addresses in the registry key and the first two fail to respond, login will take two seconds before it will show up, or if you switch location profiles and switch to one with DHCP supplied IP addresses, it will take two seconds before login switches to the desired location profile.
From here there are three possible scenarios.
1) If you successfully login and the location profile is set to "Save profile after successful login", the Server registry key will be changed to "String" and the data is the server IP address. All subsequent logins will not use the ping logic, because the Server registry key was changed to "String". Only if the machine is rebooted the DHCP service recreates the Server key as "Binary" with the list if IP addresses, and the ping logic will be used.
2) If you successfully login and the location profile is not set to "Save profile after successful login", the Server registry key will not be changed to "String" and therefore all subsequent logins will use the ping mechanism.
3) If login fails to login to the server with this IP address, it will follow the normal code path and try to find another server in that tree. If there is no tree specified, the login will fail right away. If there is no other server found for the specified tree, the login will fail.
.
symptom
Note: If you install this service on Windows NT 4.0, you'll receive the following Error Message:
Entry Point Not Found: The procedure entry point DhcpRequestParams could not be located in the dynamic link library: DHCPSVC.DLL.
This error message is because The libraries are statically linked and therefore the error message. To prevent the error message we would have to incorporate this, this is planned for one of the next client versions.
fix
Resolved with a new service for Windows 2000 included in the 4.83 version of the Novell Client for Windows NT/2000/XP.
document
Document Title: | DHCP option 85 (Preferred Server) is not correctly handled |
Document ID: | 10065177 |
Solution ID: | NOVL60000 |
Creation Date: | 05Oct2001 |
Modified Date: | 06May2003 |
Novell Product Class: | NetWare |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.