[Kea-users] Kea server can't send ACK packets
Darren Ankney
darren.ankney at gmail.com
Thu Dec 18 13:47:07 UTC 2025
Hi Daniel,
I am not able to understand your last response. I am confused about what
is running where. I'll just provide some general guidance. You probably
won't be able to (and shouldn't) test Kea in your production network as
there will be problems with ports in use and the like. The testing should
be performed in a separate test lab setup of some kind. This can be as
simple as Virtualbox with a couple of VMs running on your local laptop, but
it is probably better if you have an actual test lab setup with dedicated
hardware so that you can test things going forward (even after switching to
Kea) in case problems.
There must already be other DHCP processes running on the servers you have
been trying to use, I really can't think of any other reason that perfdhcp
would not be able to bind to the port (note that running perfdhcp as root
is pretty much required).
Note that you can run perfdhcp on the same server where you run Kea but you
won't be able to use the same port (eno1).
Another important note about perfdhcp is that the packets from perfdhcp
need to somehow reach the interface where Kea is running (eno1 as shown in
your configuration) either via relay or specification of the IP address on
the perfdhcp command line. In the example I sent previously: `perfdhcp -4
-r 1 -R 1 -p 2 AddressServer`, "AddressServer" would be replaced with the
IP address of eno1 of your Kea server.
Looking at your configuration, I see that you might be omitting an address
pool. Note that you will need to add an address pool or perfdhcp will not
be able to obtain an IP address (though you can observe the mac addresses
that are used by perfdhcp with the number of clients specified in `-R` and
add reservations for such clients either by looking at the Kea logs or a
packet capture).
Hope this advice above helps!
Thank you,
Darren Ankney
On Wed, Dec 17, 2025 at 11:39 AM Daniel Garrapucho Levy <
daniel.garrapucho at ub.edu> wrote:
> Hello Darren,
>
> Yes, we did the *perfdhcp* tests from the client server targeting the kea
> server. But that same message appeared when we first ran *perfdhcp* from
> the same server.
> We also get the same drop rate when running *perfdhcp* from the same kea
> server
> *. *Unless we want to attempt a real interaction between the client and
> the kea server, we needed to keep the legacy dhcp server active (in a
> separate server) .
>
> For the genuine DHCP test, we first set up the IP configuration manually
> on both client and kea server machines so they can still communicate with
> each other when the main DHCP server is disabled for 3 minutes. Once the
> dhcp server is disabled, we set the IP configuration of the client to
> Automatically hoping that the kea server properly receives the requests and
> offers the expected IP address. However, in such scenario no package is
> ever sent to or received by the server.
>
> I attach the configuration file that we're using. We had to remove the
> used pools and reservations for security.
>
> *Daniel Garrapucho Lévy*
>
> Tècnic informàtic
>
>
> *Departament de Física de la Matèria Condensada *Facultat de Física
> Martí i Franquès, 1
> 08028 Barcelona
> Despatx 344
> Email:
>
> *daniel.garrapucho at ub.edu <daniel.garrapucho at ub.edu> *
> ------------------------------
> *De:* Kea-users <kea-users-bounces at lists.isc.org> de part de Darren
> Ankney <darren.ankney at gmail.com>
> *Enviat el:* dijous, 11 de desembre de 2025 17:06
> *Per a:* Kea user's list <kea-users at lists.isc.org>
> *Tema:* Re: [Kea-users] Kea server can't send ACK packets
>
> Hello Daniel,
>
> > perfdhcp returns the error "Failed to bind socket 3 to
> ClientAddress/port=67 " , even if we run it as root.
>
> This is unexpected. Do you have any idea why this is the case? Your
> tcpdump output suggests that "client" (perfdhcp) and server (kea) are
> not the same IP address. Is there already a DHCP server or relay
> agent running on the "client" system?
>
> FYI, in my experience `perfdhcp` must be run as root (though I suppose
> you could assign some capabilities to it if you really wanted to) as
> it uses a privileged port.
>
> Thank you,
> Darren Ankney
>
>
> On Thu, Dec 11, 2025 at 10:28 AM Daniel Garrapucho Levy
> <daniel.garrapucho at ub.edu> wrote:
> >
> > Hi Darren,
> > Many thanks for the quick answer. We've run some tests from the client
> computer using perfdhcp as you suggested.
> > This is what we get:
> >
> > perfdhcp returns the error "Failed to bind socket 3 to
> ClientAddress/port=67 " , even if we run it as root. The workaround was
> using a non-privileged port with the -L option, but as the guide warns:
> >
> > no responses will be received from the DHCP server because the server
> responds to default relay port 67
> >
> > Following what's mentioned above, Wireshark now captures an incoming
> DHCP Offer package from the server instead of only an outcoming DHCP
> Discover package from the client.
> > The ouput that returns perfdhcp from the client is the following:
> > Running: perfdhcp -L 2346 -4 -r 1 -R 1 -p 2 ServerAddress
> > Scenario: basic.
> > Multi-thread mode enabled.
> > ***Rate statistics***
> > Rate: 0 4-way exchanges/second, expected rate: 1
> >
> > ***Malformed Packets***
> > Malformed packets: 0
> > ***Statistics for: DISCOVER-OFFER***
> > sent packets: 1
> > received packets: 0
> > drops: 1
> > drops ratio: 100 %
> > orphans: 0
> > rejected leases: 0
> > non unique addresses: 0
> >
> > min delay: inf ms
> > avg delay: min delay: n/a
> > avg delay: n/a
> > max delay: n/a
> > std deviation: n/a
> > collected packets: 0
> >
> > ***Statistics for: REQUEST-ACK***
> > sent packets: 0
> > received packets: 0
> > drops: 0
> > drops ratio: -nan %
> > orphans: 0
> > rejected leases: 0
> > non unique addresses: 0
> >
> > min delay: inf ms
> > avg delay: min delay: n/a
> > avg delay: n/a
> > max delay: n/a
> > std deviation: n/a
> > collected packets: 0
> >
> > From the server side, tcpdump captures two packages:
> > ClientFQDN.2346 > ServerFQDN.bootps: BOOTP/DHCP, Request from
> UnknownMACAddress (oui Unknown), length 262, hops 1, Flags [none]
> > Gateway-IP ClientFQDN
> > Client-Ethernet-Address UnknownMACAddress (oui Unknown)
> > Vendor-rfc1048 Extensions
> > Magic Cookie 0x63825363
> > DHCP-Message (53), length 1: Discover
> > Parameter-Request (55), length 7:
> > Subnet-Mask (1), BR (28), Time-Zone (2), Default-Gateway (3)
> > Domain-Name (15), Domain-Name-Server (6), Hostname (12)
> > Client-ID (61), length 7: ether UnknownMACAddress
> >
> >
> > ServerFQDN.bootps> ClientFQDN.bootps: BOOTP/DHCP, Reply, length 324,
> hops 1, Flags [none]
> > Your-IP RandomFQDNFromRegisteredHostNames
> > Gateway-IP ClientFQDN
> > Client-Ethernet-Address UnknownMACAddress (oui Unknown)
> > Vendor-rfc1048 Extensions
> > Magic Cookie 0x63825363
> > DHCP-Message (53), length 1: Offer
> > Subnet-Mask (1), length 4: 255.255.255.0
> > Default-Gateway (3), length 4: NetworkGateway
> > Domain-Name-Server (6), length 16: [NetworkDNSServersList]
> > Domain-Name (15), length 9: "ffn.ub.es"
> > BR (28), length 4: NetworkAddress.255
> > Lease-Time (51), length 4: 4000
> > Server-ID (54), length 4: ServerFQDN
> > RN (58), length 4: 1000
> > RB (59), length 4: 2000
> > Client-ID (61), length 7: ether UnknownMACAddress
> >
> > Unfortunately, when we do the test of shutting down the current dhcp
> server for 3 minutes and toggling the client's network interface, it still
> fails to get its IP address offered .
> >
> > We'll later send you the log files with anonymized IP and MAC Addresses
> for safety.
> >
> > Daniel Garrapucho Lévy
> >
> > Tècnic informàtic
> >
> > Departament de Física de la Matèria Condensada
> > Facultat de Física
> > Martí i Franquès, 1
> > 08028 Barcelona
> > Despatx 344
> > Email: daniel.garrapucho at ub.edu
> >
> > ________________________________
> > De: Kea-users <kea-users-bounces at lists.isc.org> de part de Darren
> Ankney <darren.ankney at gmail.com>
> > Enviat el: dimecres, 10 de desembre de 2025 16:25
> > Per a: Kea user's list <kea-users at lists.isc.org>
> > Tema: Re: [Kea-users] Kea server can't send ACK packets
> >
> > Hi Daniel,
> >
> > This looks similar to:
> >
> https://urldefense.com/v3/__https://gitlab.isc.org/isc-projects/kea/-/issues/3662__;!!D9dNQwwGXtA!S4kA00EHgt5ChCa7Cgv1e0NjWf_WkVGatJnpciFieVpvhCysjpALaSqNxCVvF36I1SY3excZd0x-yKFJFhrbbckL8adh$
> but perhaps not
> > the same since you stated it happens regardless of socket type used. I
> > suspect this might be happening due to some strangeness in the packet
> > sent by nmap. Please try testing with perfdhcp
> > (
> https://urldefense.com/v3/__https://kea.readthedocs.io/en/stable/man/perfdhcp.8.html__;!!D9dNQwwGXtA!S4kA00EHgt5ChCa7Cgv1e0NjWf_WkVGatJnpciFieVpvhCysjpALaSqNxCVvF36I1SY3excZd0x-yKFJFhrbba7GUT3T$
> ) instead.
> > This may do a better job of simulating a proper DHCP client.
> >
> > A simple command line to use with perfdhcp that would match `nmap -sU
> > -p67 --script dhcp-discover AddressServer` would be:
> >
> > `perfdhcp -4 -r 1 -R 1 -p 2 AddressServer`
> >
> > The above will perform a 4-way exchange (DORA). If you only want the
> > DISCOVER / OFFER part, then add `-i` to the command.
> >
> > If that still results in the DHCP4_PACKET_SEND_FAIL error, then your
> > full configuration, debug log messages, and a packet capture will
> > probably be needed to understand what is happening.
> >
> > Thank you,
> > Darren Ankney
> >
> >
> > On Tue, Dec 9, 2025 at 10:03 AM Daniel Garrapucho Levy
> > <daniel.garrapucho at ub.edu> wrote:
> > >
> > > Greetings !
> > >
> > > We just installed isc-kea in our server and configured it according to
> what is instructed in the Documentation.
> > > The server receives DHCP DISCOVERY packages, but it doesn't seem to be
> able to send back any ACK response.
> > > The only clue we have so far is the log file we configured for dhcp
> packets :
> > > Given the following variables, this is what we get whenever we
> simulate a DHCP Discovery broadcast with nmap
> > >
> > > AddressCliet: IP address of the client from which we run the tests
> > > AddressServer: IP address of the server where Kea DHCP is installed
> > > MACClient: MAC address of the client from which we run the tests.
> > >
> > >
> > > Command used from the client: nmap -sU -p67 --script dhcp-discover
> AddressServer
> > >
> > > DHCP4_BUFFER_RECEIVED received buffer from AddressClient:RandomPort to
> AddressServer:67 over interface NetworkInterface
> > > DHCP4_PACKET_RECEIVED [hwtype=1 MACClient], cid=[no info],
> tid=0x624894ca: DHCPDISCOVER (type 1) received from AddressClient to
> AddressServer on interface NetworkInterface
> > > DHCP4_PACKET_SEND [hwtype=1 MACClient], cid=[no info], tid=0x624894ca:
> trying to send packet DHCPOFFER (type 2) from AddressServer:67 to
> 255.255.255.255:68 on interface NetworkInterface
> > > DHCP4_PACKET_SEND_FAIL [hwtype=1 MACClient], cid=[no info],
> tid=0x624894ca: failed to send DHCPv4 packet: pkt4 send failed: sendmsg()
> returned with an error: Permission denied
> > >
> > >
> > > We have already made sure that the subnet we have configured is using
> the rigth network interface and we have opened both UDP ports 67/68 on the
> server using ufw, but to no avail. Using udp or raw packets gives the same
> outcome.
> > >
> > > We also checked that the kea sockets directory is owned by user
> _kea:_kea with mode 0755
> > >
> > > This is the information of the server where Kea is installed
> > >
> > >
> > > OS
> > > Ubuntu 22.04.5 LTS
> > > Kea version
> > > 3.0.2
> > > Installation method
> > > Package from Cloudsmith repository
> > >
> > >
> > > And this is the configuration of the dhcp server service:
> > > [Unit]
> > > Description=ISC KEA IPv4 DHCP daemon
> > > Documentation=man:kea-dhcp4(8)
> > > Wants=network-online.target mariadb.service
> > > Requires=kea-ctrl-agent.service
> > > After=network-online.target mariadb.service mysql.service
> > >
> > > [Service]
> > > ExecStart=/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
> > > RuntimeDirectory=kea
> > >
> > > [Install]
> > > WantedBy=multi-user.target
> > >
> > > Any idea what can be wrong ? Many thanks for the hard work !
> > >
> > >
> > > Daniel Garrapucho Lévy
> > >
> > > Tècnic informàtic
> > >
> > > Departament de Física de la Matèria Condensada
> > > Facultat de Física
> > > Martí i Franquès, 1
> > > 08028 Barcelona
> > > Despatx 344
> > > Email: daniel.garrapucho at ub.edu
> > >
> > >
> > >
> > > Aquest missatge, i els fitxers adjunts que hi pugui haver, pot
> contenir informació confidencial o protegida legalment i s’adreça
> exclusivament a la persona o entitat destinatària. Si no consteu com a
> destinatari final o no teniu l’encàrrec de rebre’l, no esteu autoritzat a
> llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a
> revelar-ne el contingut. Si l’heu rebut per error, informeu-ne el remitent
> i elimineu del sistema tant el missatge com els fitxers adjunts que hi
> pugui haver.
> > >
> > > Este mensaje, y los ficheros adjuntos que pueda incluir, puede
> contener información confidencial o legalmente protegida y está
> exclusivamente dirigido a la persona o entidad destinataria. Si usted no
> consta como destinatario final ni es la persona encargada de recibirlo, no
> está autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo,
> ni a revelar su contenido. Si lo ha recibido por error, informe de ello al
> remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos
> que pueda contener.
> > >
> > > This email message and any attachments it carries may contain
> confidential or legally protected material and are intended solely for the
> individual or organization to whom they are addressed. If you are not the
> intended recipient of this message or the person responsible for processing
> it, then you are not authorized to read, save, modify, send, copy or
> disclose any part of it. If you have received the message by mistake,
> please inform the sender of this and eliminate the message and any
> attachments it carries from your account.
> > >
> > > --
> > > ISC funds the development of this software with paid support
> subscriptions. Contact us at
> https://urldefense.com/v3/__https://www.isc.org/contact/__;!!D9dNQwwGXtA!S4kA00EHgt5ChCa7Cgv1e0NjWf_WkVGatJnpciFieVpvhCysjpALaSqNxCVvF36I1SY3excZd0x-yKFJFhrbbVjfZ0WJ$
> for more information.
> > >
> > > To unsubscribe visit
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/kea-users__;!!D9dNQwwGXtA!S4kA00EHgt5ChCa7Cgv1e0NjWf_WkVGatJnpciFieVpvhCysjpALaSqNxCVvF36I1SY3excZd0x-yKFJFhrbbVdNy3xz$
> .
> > > Kea-users at lists.isc.org
> > --
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at
> https://urldefense.com/v3/__https://www.isc.org/contact/__;!!D9dNQwwGXtA!S4kA00EHgt5ChCa7Cgv1e0NjWf_WkVGatJnpciFieVpvhCysjpALaSqNxCVvF36I1SY3excZd0x-yKFJFhrbbVjfZ0WJ$
> for more information.
> >
> > To unsubscribe visit
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/kea-users__;!!D9dNQwwGXtA!S4kA00EHgt5ChCa7Cgv1e0NjWf_WkVGatJnpciFieVpvhCysjpALaSqNxCVvF36I1SY3excZd0x-yKFJFhrbbVdNy3xz$
> .
> > Kea-users at lists.isc.org
> >
> >
> > Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir
> informació confidencial o protegida legalment i s’adreça exclusivament a la
> persona o entitat destinatària. Si no consteu com a destinatari final o no
> teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo,
> modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si
> l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant
> el missatge com els fitxers adjunts que hi pugui haver.
> >
> > Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener
> información confidencial o legalmente protegida y está exclusivamente
> dirigido a la persona o entidad destinataria. Si usted no consta como
> destinatario final ni es la persona encargada de recibirlo, no está
> autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a
> revelar su contenido. Si lo ha recibido por error, informe de ello al
> remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos
> que pueda contener.
> >
> > This email message and any attachments it carries may contain
> confidential or legally protected material and are intended solely for the
> individual or organization to whom they are addressed. If you are not the
> intended recipient of this message or the person responsible for processing
> it, then you are not authorized to read, save, modify, send, copy or
> disclose any part of it. If you have received the message by mistake,
> please inform the sender of this and eliminate the message and any
> attachments it carries from your account.
> >
> > --
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at
> https://urldefense.com/v3/__https://www.isc.org/contact/__;!!D9dNQwwGXtA!SdrcQeiANLiXu1y9rfZkUzA6nglHgqZSmQY6Z_LkLVfrdPyad2na7NpATT-ZoZTW_Fy1xjhA1cYXMMx9y1PDp9kXgyLz$
> for more information.
> >
> > To unsubscribe visit
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/kea-users__;!!D9dNQwwGXtA!SdrcQeiANLiXu1y9rfZkUzA6nglHgqZSmQY6Z_LkLVfrdPyad2na7NpATT-ZoZTW_Fy1xjhA1cYXMMx9y1PDp9pIKgHW$
> .
> > Kea-users at lists.isc.org
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at
> https://urldefense.com/v3/__https://www.isc.org/contact/__;!!D9dNQwwGXtA!SdrcQeiANLiXu1y9rfZkUzA6nglHgqZSmQY6Z_LkLVfrdPyad2na7NpATT-ZoZTW_Fy1xjhA1cYXMMx9y1PDp9kXgyLz$
> for more information.
>
> To unsubscribe visit
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/kea-users__;!!D9dNQwwGXtA!SdrcQeiANLiXu1y9rfZkUzA6nglHgqZSmQY6Z_LkLVfrdPyad2na7NpATT-ZoZTW_Fy1xjhA1cYXMMx9y1PDp9pIKgHW$
> .
> Kea-users at lists.isc.org
>
>
> Aquest missatge, i els fitxers adjunts que hi pugui haver, pot contenir
> informació confidencial o protegida legalment i s’adreça exclusivament a la
> persona o entitat destinatària. Si no consteu com a destinatari final o no
> teniu l’encàrrec de rebre’l, no esteu autoritzat a llegir-lo, retenir-lo,
> modificar-lo, distribuir-lo, copiar-lo ni a revelar-ne el contingut. Si
> l’heu rebut per error, informeu-ne el remitent i elimineu del sistema tant
> el missatge com els fitxers adjunts que hi pugui haver.
>
> Este mensaje, y los ficheros adjuntos que pueda incluir, puede contener
> información confidencial o legalmente protegida y está exclusivamente
> dirigido a la persona o entidad destinataria. Si usted no consta como
> destinatario final ni es la persona encargada de recibirlo, no está
> autorizado a leerlo, retenerlo, modificarlo, distribuirlo o copiarlo, ni a
> revelar su contenido. Si lo ha recibido por error, informe de ello al
> remitente y elimine del sistema tanto el mensaje como los ficheros adjuntos
> que pueda contener.
>
> This email message and any attachments it carries may contain confidential
> or legally protected material and are intended solely for the individual or
> organization to whom they are addressed. If you are not the intended
> recipient of this message or the person responsible for processing it, then
> you are not authorized to read, save, modify, send, copy or disclose any
> part of it. If you have received the message by mistake, please inform the
> sender of this and eliminate the message and any attachments it carries
> from your account.
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> Kea-users at lists.isc.org
> <https://lists.isc.org/mailman/listinfo/kea-users.Kea-users@lists.isc.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20251218/3d48b8cd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-sjd0f41e.png
Type: image/png
Size: 98177 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20251218/3d48b8cd/attachment-0001.png>
More information about the Kea-users
mailing list