[kea-dev] Lost Discover

Chaigneau, Nicolas nicolas.chaigneau at capgemini.com
Mon Dec 29 10:09:00 UTC 2014


Hello Marcin,


It's alright, that's not an urgent issue. I'm just reporting things as I find them :)

Anyway, I found out the cause of the packet drop.
(which is the same for each of the 145 lost DHCP Discover)


This happens when receiving a message (Discover in this case) containing DHCP Option 43 (Vendor-Specific Information), with a value of "0xdc00".
According to RFC 2132, option 43 should contain a list of TLV attributes.
Here, we have one attribute (code 0xdc) with a length of 0, which is a bit weird, but I think this should not cause the server to drop the packet.

When this happens, we have the following log entry as DEBUG:
2014-11-06 18:17:44.321 DEBUG [kea-dhcp4.dhcp4/26707] DHCP4_PACKET_PARSE_FAIL failed to parse incoming packet: Attempt to parse truncated option 220

Then the packet is dropped. Client gets no response.


I'll create a ticket for this.



Regards,
Nicolas.


> Nicolas,
> 
> Thanks for reporting the issue. Unfortunately, many folks from our team disappear until January 2nd and is unlikely that anyone will be able to have a look this year. Please share any additional findings and if you're convinced that it is an issue in Kea, please file a ticket.
> 
> Merry Christmas,
> 
> Marcin
> 
> On 12/23/14 18:35, Chaigneau, Nicolas wrote:
> >
> > 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 :)
> >
> >
> > Regards,
> > Nicolas.
> >
> >
> >
> > -----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
> >
> >
> > Marcin,
> >
> >
> > 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 :)
> >
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.


More information about the kea-dev mailing list