Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Lost Discover (Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Dec 2014 10:09:00 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Lost Discover
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194be...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="utf-8"
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 : [email protected]
> > [mailto:[email protected]] De la part de Chaigneau,
> > Nicolas Envoy? : mardi 23 d?cembre 2014 17:08 ? : Marcin Siodelski;
> > [email protected] 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.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 9, Issue 12
**************************************
