Is ISC DHCP going away?

[Monviech (Cedrik)]

What do you mean with filtering some features?

DHCP is quite simple, it provides your clients with an IP address to use, as well as with DHCP options which specify certain resources (e.g., default gateway (router), dns server).

Did you set any specific DHCP option to enable Wifi calling?

[PhoenixRider]

What do you mean with filtering some features?

DHCP is quite simple, it provides your clients with an IP address to use, as well as with DHCP options which specify certain resources (e.g., default gateway (router), dns server).

Did you set any specific DHCP option to enable Wifi calling?

No, I haven't configured anything special under KEA that could affect WiFi Call, that's the strange thing.

If it works fine with ISC and I've configured KEA correctly (which I have), then KEA must be filtering something or whatever. I just can't understand why KEA acts like this.

But generally, I agree with your statement that DHCP shouldn't filter anything, but rather handle the distribution of IP addresses.

[Monviech (Cedrik)]

You should compare the DHCP Offer packets sent via ISC and KEA to find out of the options inside them match and if the clients receive all of the options they request. If they do, it should not have anything to do with DHCP itself.

You could use Wireshark on a client, or the Packet Capture feature in the OPNsense GUI.

[meyergru]

Alas, DHCP and its older brother BOOTP are probably the most awkward protocols ever invented. There were (and are) size limitations on what can be transmitted, so if you use too many (or too long) options, you may cause problems. Some clients bark on options they do not know.

Behind the DHCP daemons, there is some trickery going on, that may cause addition or modification of DHCP options that you do not see plainly in the configuration.

Thus, @Monviech's advice is correct: compare tcpdumps of the actual DHCP responses and see if you can find differences.

[julsssark]

I could be reading your post incorrectly, but when you say "parent" interface do you mean a non-VLAN subnet? If you mix tagged and untagged traffic on the *same* trunk port, that could be the problem. See here and note the orange box: https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html

[wrobelda]

BTW, I switched to DnsMasq for DHCP by stopping the ISC and adding ranges to DnsMasq config, but I cannot actually have ISC disabled (to avoid it starting on boot again), because ticking the "Enable DHCP server on the LAN interface" checkbox does nothing, as in the "Apply" button does not show up.

EDIT: nevermind, the ISC configuration page actually somehow has "Save" button on the bottom for any changes, a blast from the past.

[PhoenixRider]

You should compare the DHCP Offer packets sent via ISC and KEA to find out of the options inside them match and if the clients receive all of the options they request. If they do, it should not have anything to do with DHCP itself.

You could use Wireshark on a client, or the Packet Capture feature in the OPNsense GUI.

With KEA, all clients receive both an IPv4 and an IPv6 address. However, the latter comes from ISC DHCPv6 and not from KEA. This shouldn't be a problem, because the main Wi-Fi subnet works with WiFi Call, but not the subnets that work with VLANs. From my understanding, everything should be fine as long as the clients have received their IP addresses successfully. So, you can be wrong.

So I suspect that KEA isn't embedded deep enough in the system yet, or that something is missing in the coding. But I have no idea about that, so I'll leave it to Franco and co.

Thanks for your helpful answers.