Setting DHCP Vendor Classes on Windows 2003 Server

[acb_]

We have been trying and failing all day to sort this.

We have a batch of Dell Axim X51 handhelds all shiny and new; they will be used for lesson registration. We have all the apps and so on installed. What we're trying to do now is give them a gateway other than our default loopback.

Ideally we would do it how we do it for the workstations: setting options using class IDs. We haven't found a way of sorting this on this kit.

We thought we might be able to do it with Vendor Class instead.

During the lease process, the units are sending 'Option 60: Vendor Class identifier "Microsoft Windows CE" '

This is not a predefined Vendor Class on our Win 2003 Server. We have created this class and tried to assign the 003 router option through it. The 003 Router option wasn't available, we created one, it failed to provide the required setting to the unit.

In the ACK packet, we are receiving 'Option 43: Vendor-Specific Information' which contains the information we defined in the option under the Vendor Class, but the unit doesn't know what to do with it.

Our aim is for the DHCP server to see that it's a handheld, and dole out the correct 003 Router option accordingly. We both thought the Vendor Class stuff was like the user class stuff, but it doesn't seem to work the same way.

Can anyone shed some light on this or come up with an alternative which we haven't spotted? And before you post, Linux isn't an option here

[Face-Man]

have you investigated using reserved IP address. I realise it may be time consuming to do a lot of devices that way

[acb_]

have you investigated using reserved IP address. I realise it may be time consuming to do a lot of devices that way

Thanks - it is an option, but it's very low down on our list. There will be 120 units when they are all here

The boss is now messing around in the unit's registry to try to spoof a class id - I've just heard the words 'Well I've messed something up somewhere...'

[indie]

And before you post, Linux isn't an option here

The linux solution i'm thinking of is very easy and you'd only need a crap old machine for it to work and it would solve your problems.

But if you don't want to go the easy way then try what Face-Man suggested, that should work, there's just a lot more admin overhead.

[acb_]

OK, he's cracked it!

He modified the registry to include a value to send a class ID, so we get to use the solution we wanted all along

PS Indie, no disrespect to Linux (we use plenty of open source solutions in school) - we needed a solution on our Windows set up...

[indie]

No problem, would you like to post the complete solution in case any one else runs into a problem like this?

[Face-Man]

Well done. I'd certainly be interested in your solution as I can see it coming my way at some point next term..

[Shiny_Guru]

Well, having had my arm twisted to finally document something here we go...

Using whatever your favorite method to edit the registry navigate to

HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms\DhcpSendOptions

in our case their was already a entry called 60 which is the option code for Vendor Class ID - the binary string that is the value matched the Vendor Code we sniffed off the wire - I guessed that this might be a generic store for options to send in the DHCP request

The option for User Class ID is 77 (sniffed from one of our workstations - I can never remember the numbers) so I created a binary value called 77 and entered the binary data I sniffed from our workstation DHCP update. I saved the change and renewed the IP and Voila! it worked. Well, the second time it worked when I had typed the binary in properly - which was the stage where I decided to choose a short Class ID for the hand helds.

The format of the binary value is
4d <length> xx xx xx xx
where the xx pairs are the hex values that match your class ID, <length> is the number of hex values and 4d is hex for 77 decimal.

A concrete example, I created the class id palm to use on our handhelds which gives us the binary

4d 04 70 61 6c 6d

We are working on Dell Axim X51's which are fairly new - I do not know how far back this mod would work, but I guess you should be safe on all WinCe Version 5 stuff.

As with all these things, once you know how it takes about 30seconds to do - finding out how has taken me several days and a few false starts. Hope that helps some of you.

[acb_]

8O

*faints at novel sight of documentation*

[contink]

8O

*faints at novel sight of documentation*

ROFLMAO...

Oh how true... but if you want to really suffer a shock, let's see if it gets to the Wiki

Just pulling legs here btw.. useful info although thankfully I don't have to worry about this particular issue in my primary school(s) it's nice to know I can always return in a year or so..

[Shiny_Guru]

I have read back my description and I think it might be a little confusing. To try and remove any ambiguity I have exported the registry key in regedit format and copied it before. As in my previous example I have used the Class ID palm - if that suits your environment you can import the key 'as-is'.

REGEDIT4

[HKEY_LOCAL_MACHINE\Comm\Tcpip\Parms\DhcpSendOptions]
"77"=hex:4d,04,70,61,6c,6d

[CyberNerd]

It is a bit confusing - your saying that you need to hack a Windows CE device, to tell it that its a palm device so that a Windows server can recognise it ? hmm Microsoft sure don't make integration easy.

[Shiny_Guru]

It has nothing to do with Palm OS, I'm just slightly old fashioned and use the term 'palmtop' to refer to hand held devices. To avoid typing when setting up binary registry settings I shortened this to just palm.

The effort I expended was to make our DHCP server recognise the hand helds as different to our desktop machines and offer them different network settings.

To achieve this I set a custom class id in the DHCP request - the word palm was used for the reasons I have just noted.

I'm sorry if I made things sound more confusing than they already were

[CyberNerd]

lol, thanks for clearing that up