Messages

It's a known package manager incompatibility between the two third party repos you have set up on your end.


Cheers,
Franco

Appreciate the response.

So is this just cosmetic or am I setting myself up for a more serious problem down the road? Just saying, I'm fine doing the updates through CLI as long as these repos (which I need) play nice at the core.

Anyone?

Do the fact that these components shows as "N/A" under Current version have something to do with it?

Some updates that show up in the Web UI will go through the whole nine yards of downloading, extracting, and installing. It would appear that the updates were installed successfully. But when I click on "Check for updates" immediately after, the same set of components pops up that requires an update.... rinse and repeat.

I've found out that doing a "pkg update -f" then "pkg upgrade" in CLI would actually stop the cycle.... until the next time.

Right now, these are the usual suspects...



Is this just the nature of the beast or am I doing something wrong?

It appears to support multiple pools, but only with the same settings... Did you set up multiple subnets that lease out the same interface? I never even thought of attempting that.

My bad. I mistook the term "Pool" to mean "Scope". The latter is what I need to configure.

I have a DHCP relay set up on the L-3 switch that forwards DHCP-Discover packets to a Windows DHCP server. The DHCP server hosts multiple Scopes (or subnets) and responds to the L-3 switch's request to give the client device the correct IP address in the VLAN that they are in.

It seems that ISC in its current form does not support this scenario, unfortunately. Kea does support it, but no Option 150. It's just cruel.. I tell ya! :D

So just for the heck of it, I tried setting up ISC.

Apparently, it does not support multiple subnet pools on the same interface?

As mentioned a few posts back, I have an L-3 switch that does the inter-VLAN routing and then a single routed connection to OPNsense for Internet. The L-3 switch does DHCP relay and for the most part, works well in Kea (sans Option 150) but seems not possible in ISC.

So in summary:

Kea - Supports multiple subnet pools on the same interface (ie. LAN) but lacks vendor-specific Option settings
ISC - Supports ONE subnet pool per interface (or VLAN) on OPNsense. Apparently supports vendor-specific Option settings but I haven't gone that far to test it out due to the aforementioned limitation

A little more research indicates that option 150 is Cisco proprietary for the same functionality 😒
The network capture output recognizes both: TFTP-Server-Address (150), TFTP (66).
Kea only handles 66.

While the OP could hack the Kea config, updates don't survive changes in the GUI so that's not practical.
ISC has support for custom options.
For Kea, it's in the works per Kea dhcp - vendor specific options

Thank you for this info. I honestly thought that adding vendor-specific/custom options on most any DHCP servers was something trivial.

I was going to use ISC but since it's being deprecated and with Kea taking its place, I decided to deploy the latter for future-proofing. Cisco IP phones are ubiquitous and it's been around for the last 20+ years. I would've thought that custom Options support is "standard" across DHCP servers. For the same purpose, Avaya IP phones require Option 176, and I think it's going to run into the same problem on Kea.... at least for now.

I guess I'll stay with Windows Server DHCP for the time being until Kea adds support for custom Options.

Thanks guys!

It seems pretty trivial to look at the traffic (Interfaces > Diagnostics > Packet Capture), filter on interface, IPv4, UDP & port 68.
Unplug & replug a phone. The full capture seems pretty readable.
I'm no expert but the client seems to be requesting various options and the server obliges when it can.

Not sure what I'm doing wrong but the capture is empty.

If I go check the Kea DHCP leases, the IP phone is there, so that indicates that it is getting an IP address at least.

I should add that the IP phones are behind a Layer-3 switch, which is on a VLAN/subnet different from the LAN subnet on OPNsense. The L-3 switch is doing DHCP-relay (ip helper-address in Cisco-speak).

To illustrate:

It's a reach, but are you using Socket Type "udp"? I have a switch that only works with "raw".

Being new to Kea, I've left everything default. It's currently set to "raw" and I might play around and try UDP later. Will revert back whatever the results may be.

Thanks for the suggestion.

Currently using a dedicated Windows Server as DHCP and everything is working ok. I want to streamline my home network and collapse more, if not all functions on OPNsense.

So I'm trying out Kea DHCP.

Unfortunately, it doesn't appear to have support for Option 150. This is required for Cisco IP phones to figure out the IP address of the TFTP server.

In Kea > Subnets, there's a field for a TFTP server. I've put in the IP address of the TFTP server but the phones aren't seem to be getting it.

Routing is working fine and all other devices on this particular subnet can ping or access the TFTP server, so this is not a reachability issue as far as I can tell.

Any help is appreciated. Thanks!