Configuring DHCP server options selectively based on vendor class?

Moving from another router OS platform (Endian), and still haven't figured out how to port over this portion of the config (for ISC dhcpd) that causes dhcpd to send extra config to our phones so they can get firmware / config updates automatically on reboot.

class "gxp2124" {
		match if substring (option vendor-class-identifier,0,19) = "Grandstream GXP2124";	
		option option-66 "http://10.10.100.31/phones/cfg-auto";
 	}

...

class "gxp2020" {
		match if substring (option vendor-class-identifier,0,19) = "Grandstream GXP2020";	
		option option-66 "http://10.10.100.31/phones/cfg-auto";
 	}

I can see (I think) how I can just blindly send option 66 for all things, but I don't know how I can match it to just certain vendor-class-identifier strings. We'd like to be able to provide a regular old PXE boot menu for everything else.

Personally, I'd forego dnsmasq and install kea or, if you want to retain your existing config and have enough space, isc-dhcp-server-ipv[46]

I don't see kea as an OpenWrt package, but it runs easily on an old Raspberry Pi-class device (though I don't know your scale/load). It shouldn't be too hard to package up for OpenWrt either (assuming you're OK with command-line configuration).

https://openwrt.org/docs/guide-user/base-system/dhcp#classifying_clients_and_assigning_individual_options

1 Like

We're running this on an x86 machine so RAM/disk/CPU are not an issue.

I am hoping to keep things generally manageable via LuCi though, so those less technically inclined can make changes when needed. Configuring the phones' boot stuff manually is fine, but if someone wants to add a DHCP assignment I'd like that they can still do it from LuCi.

Looks like from the link @vgaetera provided we may be able to accomplish this.

Looks like I can add to UCI config in /etc/config/dhcp ?

config vendorclass 'gxp2124'
        option vendorclass 'Grandstream GXP2124'
        list   dhcp_option '66,http://10.10.100.31/phones/cfg-auto'

etc

I'll test it later today.

Doesn't seem to work. The config never gets passed into the generated /var/etc/dnsmasq.conf.*

I tried putting the equivalent non-UCI config into /etc/dnsmasq.conf but that didn't seem to work either. Option 66 doesn't appear to be sent.

However if I add option 66 to Network > Interfaces > LAN > DHCP Server > Advanced Settings > DHCP-Options, then it works, but it's for all devices, not just specific vendor class matches.

So maybe I'm doing it wrong (wrong file? error in formatting?) ...

Option networkid is mandatory, I suppose you should use gxp2124 or tag:gxp2124 as its value.

1 Like

The networkid should correspond to the name of the config dhcp section, usually lan.

Edit: that would apply the option 66 to all LAN clients which isn't what we want. The networkid should indeed be another tag value to tie the vendor class to the option.

I just tried this:

config vendorclass
        option networkid 'gxp2124'
        option vendorclass 'Grandstream GXP2124'                   
        list   dhcp_option '66,http://10.10.100.31/phones/cfg-auto'

Which was translated to these options in /var/etc/dnsmasq.conf.*:

dhcp-vendorclass=gxp2124,Grandstream GXP2124
dhcp-option=gxp2124,66,http://10.10.100.31/phones/cfg-auto

Meaning "when vendor class contains the substring Grandstream GXP2124, apply the tag gxp2124 to it. For tag gxp2124 add option 66 with value http://10.10.100.31/phones/cfg-auto."

I then tested it from my workstation by adding send vendor-class-identifier = "Grandstream GXP2124"; to /etc/dhcp/dhclient.conf. After killall -9 dhclient; dhclient wlan0 I could verify that the value of option 66 was put into the sname field of the DHCP reply:

request

reply

3 Likes

I can confirm this works - not just sending Option 66, but that the phone actually then makes the expected requests to the URL passed in Option 66 (it tries to download firmware and config updates and such).

Interestingly, the ISC DHCP on our Endian router sends the string without null termination, and DNSmasq on OpenWRT send it with null termination, but luckily it doesn't seem to matter, the phone seems to accept both (hopefully this is true across the whole range of models, I've just got one ancient one I'm using to test with).

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.