[Kea-users] dhcp4 server listening on more than one interface does not work

[Chuck Zmudzinski]

Hi Darren,

After reading some information from the isc knowledge base about
the raw socket and the fallback udp socket in dhcp4 servers, it
seems necessary to have the fallback UDP socket, so I investigated
some more and found a difference in how the fallback socket displays
in netstat when using the old isc dhcp4 server vs. the kea-dhcp4
server that might be relevant to this problem. In both cases, the
dhcp4 server is listening on two vifn.0 interfaces. But only in the
case of the old ISC dhcp server do the two vifn.0 interfaces have
the same IPv4 address. On the system with kea-dhcp4, it was necessary
to set the interface of the second to have a different IPv4 address,
in this case it was set to 192.168.1.16, as the output of the
following commands show. 

On a system using the old ISC dhcp4 server:

user at fedora:~$ sudo netstat -lun --program | grep dhcpd
udp        0      0 0.0.0.0:67              0.0.0.0:*                           5589/dhcpd
user at fedora:~$

On a system using the kea-dhcp4 server:

user at almalinux:~$ sudo netstat -lun --program | grep kea
udp        0      0 192.168.1.16:67         0.0.0.0:*                           2369/kea-dhcp4
udp        0      0 192.168.1.105:67        0.0.0.0:*                           2369/kea-dhcp4
user at almalinux:~$

The system with the old ISC server is Fedora 41, and the system with
kea-dhcp4 is AlmaLinux Kitten, which currently tries to be binary
compatible with the RHEL 10 pre-release.

So it would seem the Alma Kitten system with kea-dhcp4 tries to bind
the UDP fallback socket to the IPv4 address of the listening interface
and it only succeeds if the addresses are unique, but the Fedora system
with the old ISC dhcp4 server binds the UDP fallback socket to 0.0.0.0
which apparently enables the UDP fallback socket to succeed even if
the IPv4 addresses are the same.

I don't know if this behavior is caused by differences in the dhcp4 servers
or in differences in how the bind system call behaves on the two systems.

Any suggestions on how to proceed?

Thanks,

Chuck 

On 4/19/2025 7:23 PM, Chuck Zmudzinski via Kea-users wrote:
> On 4/19/2025 5:39 PM, Chuck Zmudzinski via Kea-users wrote:
>> Hi Darren,
>> 
>> I found the reason for the problem, but still have a question. Your
>> advice to look at the logs identified the problem.
>> 
>> According to the logs, the problem is that the Xen system is
>> configuring each vifn.0 interface on which kea-dhcp4 is listening
>> to have the same IPv4 address, and this is something that kea rejects.
>> 
>> Here is the warning I get from the logger:
>> 
>> Apr 19 16:25:05 almalinux kea-dhcp4[5650]: WARN  [kea-dhcp4.dhcpsrv.139918558259328] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface vif6.0, reason: failed to bind fallback socket to address 192.168.1.105, port 67, reason: Address already in use - is another DHCP server running?
> 
> I see this warning is coming from PktFilter::openFallbackSocket, and
> the fallback socket fails to bind because the address is already in use.
> 
> Is this the same thing that is described in the note at section 8.2.4
> of the documentation for the dhcp4 server quoted below?
> 
>> Specifying the value raw as the socket type does not guarantee that raw sockets will be used! The use of raw sockets to handle traffic from the directly connected clients is currently supported on Linux and BSD systems only. If raw sockets are not supported on the particular OS in use, the server issues a warning and fall back to using IP/UDP sockets.
> 
> It looks like the failure in my case is due to a failure to bind the
> fallback IP/UDP socket.
> 
> But in my case, I don't think I need the UDP fallback socket because
> all the clients are directly connected. Would it be possible to add a
> dhcp-socket-type option such as "raw-no-fallback" to the dhcp4 server
> to allow the server to listen on an interface using the raw socket in
> cases like mine when the the call to bind the fallback UDP socket
> fails?
> 
> That might help in my situation since, as I mentioned in a previous
> message in this thread, I have to waste N-1 IPv4 addresses on the Xen
> virtualization server to serve N guests with IPv4 configurations using
> the kea dhcp4 server, which is IMHO a nasty regression compared to the
> old ISC dhcp4 server, with which I could get away with using only a
> single IPv4 address on the Xen virtualization sever for all N vifn.0
> interfaces, the same address the Xen virtualization server obtains
> from the SOHO router.
> 
> Would the kea project consider such a new dhcp-socket-type option as
> proposed above?
> 
> I am willing to do some experiments to test such an option in my system
> to see if it solves this regression compared to the old ISC dhcp4 server.
> 
> Thanks,
> 
> Chuck Zmudzinski