Option 66 not working on Kea (2.8.1-RELEASE)

McMurphy

I have an issue whereby option 66 is not working with Kea. If I swap back to ISC then it works fine.

I am trying to sent the IP phone config.

The DHCP response is:

My option 66 config is:

Any ideas on how to fix this?

Gertjan

@McMurphy

KEA DHCP Option 66 3CX ?

Kea doesn't have all the 9841 known options yet.
But : look around in the DHCP forum, and you'll find how to add them.

Example : my Unifi stuff needed an special 'Unifi' option :
I added it to Services > DHCP Server > Settings

and on the network DHCP page I added :

and boom : the option worked.
Btw : this one is very well documented on Redmine and here on this forum.

Be ware : JSON text structures are very syntax sensitive.

johnpoz

@Gertjan said in Option 66 not working on Kea (2.8.1-RELEASE):

my Unifi stuff needed an special 'Unifi' option

Why exactly? I run unifi and don't have this option set. Is that for remote adoption? 192.168.1.9 your pointing to.

Would be easier to just use the dns method.

Gertjan

@johnpoz

I wanted the extreme 'plug and play' experience with my new APs
As I had to install a couple of them all at ones, and wanted them to become avaible "me doing nothing", just waiting in fronyt of my local "Cloudkey (hardware) UCK G2 Plus" GUI (which lives at 192.168.1.9) for 'adopt ?' to show up, assign it to a wifi network, and done. All APs administrated in one place, what a progress.
No phone app set up, no ssh access. No nothing. I never had to admin the ancient APs neither ^^
Did I really need it ? Of course not

Before, I used DD2WRT Cisco (linksys low bud) devices and these worked well for a more then a decade.
Since I have fiber and hundreds of Mbits/sec to share, I've upgrade the public captive portal to the next level, way faster, Legacy Wifi, 5Hhz and 6Ghz 'mimo' and all that stuff.

There was a discussion about it in IRC, redmine, and here on the forum how to add DHCP 'options' in kea, so I used it. To make me understand better how kea (settings) (JSON stuff !) works.

johnpoz

@Gertjan are your AP not on the same vlan as your controller? That is only needed for L3 adoption across networks.

I add new unifi devices now and then - but since I put their management on the same L2 - there nothing to do. dns or dhcp is only required when the devices are on a different network then the controller.

mcury

@johnpoz said in Option 66 not working on Kea (2.8.1-RELEASE):

@Gertjan are your AP not on the same vlan as your controller? That is only needed for L3 adoption across networks.

I add new unifi devices now and then - but since I put their management on the same L2 - there nothing to do. dns or dhcp is only required when the devices are on a different network then the controller.

I need to use the L3 adoption method to be able to adopt devices across networks.
See, I like my controller not to be connected to a UniFi switch or any UniFi device.
This gives me the ability to disable LACP, remove connections, and not lose management access—it's like an OOBM (out-of-band management) for the UniFi controller and devices.
Some devices don't like the DNS method, such as the Unifi Flex Mini.

I have a UNIFI_ADOPTION interface (LAN, igc1), which is connected to the UniFi devices.
But my main LAN is on the IGC0 port, to which my desktop and laptop are connected.
The MGMT VLAN on IGC1 is VLAN 99, and VLAN 1 is only used to adopt new devices.

johnpoz

@mcury not sure what your trying to say. None of my unifi devices are on my lan - they are on their own management network of L2. You could have hundred of switches in your network - as long as you put all the unifi devices on the same L2 as your controller.

On the same local network this should never be a problem - only time it is an issue is when your controller is at a different site than the devices you want it to manage.

Guess we have gotten a bit off topic - and yes there are needs of the ability to do options in your dhcp for sure. I just don't see this as the case with unifi unless your controller was off site, in the cloud or something.

Even on a huge campus - unless your network is pretty borked, why would you not be able to put a specific l2 on any interface anywhere in your campus that a unifi device is going to plug into? And that sure doesn't require unifi switches.

mcury

@johnpoz said in Option 66 not working on Kea (2.8.1-RELEASE):

as long as you put all the unifi devices on the same L2 as your controller.

I've battled this before—trying to set up LACP link aggregation, VLAN overrides on individual devices, doing it while being behind a Unifi switch controlled by the same controller.
That is my take on it, you don't want to isolate the controller and have to go on site, while you could just ask someone to reset a device with a pin.

But yes, we got out of the topic.
But always nice to have a good tech chat in this forum

These rules, along with DNS and DHCP options for Unifi, the reset PIN never fails..

johnpoz

@mcury said in Option 66 not working on Kea (2.8.1-RELEASE):

doing it while being behind a Unifi switch controlled by the same controller.
That is my take on it

Yeah that could be problematic I guess.. If something got botched with the config of the switch so the controller could no longer talk to it - that could be problematic for sure.

Gertjan

@johnpoz said in Option 66 not working on Kea (2.8.1-RELEASE):

are your AP not on the same vlan as your controller?

@mcury already said it :

@mcury said in Option 66 not working on Kea (2.8.1-RELEASE):

I need to use the L3 adoption method to be able to adopt devices across networks.
See, I like my controller not to be connected to a UniFi switch or any UniFi device.

That is : I've several APs are situated in a non trusted (captive portal) 'LAN', and several other APs in my trusted (company) LAN. The controller lives in my company LAN, not 'exposed' in the portal network.

The Unifi APs, if they didn't get an DHCPv4 option '44' with a controller IP, fall back to a 'unifi' host name. But why would I use this easy to implement "host override" DNS method as the DHCP option worked just fine ? When I was using, tis worked just fine. When kea was introduced, I had to 'patch' something together. Later on, Netgate made these JSON customisation "officially" avaible in more recent updates.

Btw : I stay away from VLANs. I'm not running away if things gets a bit more complex, but I stay away from VLANs.

edit : and yeah, if needed, a syslog collector is avaible in the same LAN, as is a (free) radius server.

McMurphy

Thanks you.

Until Kea has these options added is there any problem with continuing to use ISC?

johnpoz

@McMurphy No - I am still using it, not a fan of current logging in kea.. And isc still works, there are not any security issues that would warrant switching. They have just stopped development of it is all.

I have no need for the dhcp registration, etc. So just no point to me to switch at this time and more than likely cause my self grief when isc currently works exactly how I like it, etc.