Dhcp-options vendor-class-id, numerical value rejected

I use since august VyOS 1.4-rolling-202308050917 for my Internet access and it works fine. I tried the current 1.5 rolling release and I did build myself the current Sagitta version.
On latest 1.4 and rolling 1.5 my current config to enable WAN access over my ISP is rejected.
I get
[ interfaces ethernet eth1 vif 10 dhcp-options vendor-class-id 100008.0001 ]
invalid value

Any idea what has changed and how to adapt my setup ?
This is my current working config on previous release

set interfaces ethernet eth1 vif 10 address ‘dhcp’
set interfaces ethernet eth1 vif 10 address ‘dhcpv6’
set interfaces ethernet eth1 vif 10 description ‘Internet’
set interfaces ethernet eth1 vif 10 dhcp-options host-name ‘ubnt-sw’
set interfaces ethernet eth1 vif 10 dhcp-options vendor-class-id ‘100008,0001’
set interfaces ethernet eth1 vif 10 dhcpv6-options pd 0 interface eth0 address ‘1’
set interfaces ethernet eth1 vif 10 dhcpv6-options pd 0 interface eth0 sla-id ‘0’
set interfaces ethernet eth1 vif 10 dhcpv6-options pd 0 length ‘56’
set interfaces ethernet eth1 vif 10 ip adjust-mss ‘clamp-mss-to-pmtu’
set interfaces ethernet eth1 vif 10 ip enable-proxy-arp
set interfaces ethernet eth1 vif 10 ipv6 address autoconf
set interfaces ethernet eth1 vif 10 ipv6 dup-addr-detect-transmits ‘1’

1 Like

The 1.5 migrated to KEA-DHCP server dhcp: T3316: Migrate dhcp/dhcpv6 server to Kea by sarthurdev · Pull Request #1960 · vyos/vyos-1x · GitHub

Ah sorry, your case is related DHCP-client
it is another case

No idea why this isn’t anymore supported ?
set interfaces ethernet eth1 vif 10 dhcp-options vendor-class-id ‘100008,0001’

in latest release I can enter any arbitrary text string and it is accepted but ‘100008,0001’ is rejected.

There is the Regex for validation

Thank you. I understand now why it has to be non-numerical. Do I have to patch my build or couldn’t it be of general interest to accept the kind of vendor-class-id I need with my ISP ?

Add please a bug report

I do not know if this is by design or a bug. I converted the string ‘100008,0001’ to hex after reading the comment of the regex change you mentioned and it works this way.
Maybe it’s more a documentation issue.

1 Like