[kea-dev] Lost Discover

Chaigneau, Nicolas nicolas.chaigneau at capgemini.com
Tue Dec 23 17:35:58 UTC 2014

Alright I have more information on the "lost Discover" case.
I managed to find one. Each time I send this specific message, it seems Kea silently drops.

I took a capture of this Discover, along with another one (which is correctly processed) for comparison purposes.
See attached pcap file, which contains 3 packets:
- first Discover (correct one)
- Offer sent back in response to first Discover
- second Discover (the lost one)

Comparing the two Discover, I notice:
- First one has "Bootp flags" = 0x8000 (Broadcast), the other 0x0000 (Unicast)
(but I don't think this is the issue, I have other packets with either and they are handled correctly)
- Second one has some options that are not in the first:
116 (DHCP Auto-Configuration)
43 (Vendor-Specific Information)
- Also, option 55 (Parameter Request List) is different.

There must be something that explains the difference in behavior...

I'm away until next Monday, until then - have a nice Christmas :)


-----Message d'origine-----
De : kea-dev-bounces at lists.isc.org [mailto:kea-dev-bounces at lists.isc.org] De la part de Chaigneau, Nicolas
Envoyé : mardi 23 décembre 2014 17:08
À : Marcin Siodelski; kea-dev at lists.isc.org
Objet : Re: [kea-dev] Malformed packets returned by Kea


Thanks for looking into this.

For the moment I'm not able to build from the master head (I'm still stuck with the autoconf tools).
That's something I must look into.

When it's resolved, I'll test this again. I'll keep you updated of the results.

I would have an unrelated question:

Is it possible for Kea to silently drop DHCP packets received ?
(by silently I mean that even in DEBUG, nothing is traced)

I'm checking log entries such as the following:
2014-11-06 18:11:24.864 DEBUG [kea-dhcp4.dhcp4/26707] DHCP4_PACKET_RECEIVED DISCOVER (type 1) packet received on interface bond0.102

I've counted 145 received DHCP Discover less than what I expected (out of 11616, according to the network capture).
All these Discover messages are unicast from the same source address, to the same destination address.
I've got quite a lot so I don't know which exactly are lost and why...

I know this is quite vague but if you have any idea it would be most welcome :)


> Nicolas,
> I had a look into the issue and I believe that it had been fixed on the master branch already. See: http://kea.isc.org/ticket/3624
> I also updated the ticket #3659 with this information.
> Can you please have a look if the latest version of Kea from master works for you?
> Marcin
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

kea-dev mailing list
kea-dev at lists.isc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace-disc_2cmp.pcap
Type: application/octet-stream
Size: 1225 bytes
Desc: trace-disc_2cmp.pcap
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20141223/0fc23595/attachment.obj>

More information about the kea-dev mailing list