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: Malformed packets returned by Kea (Chaigneau, Nicolas)
2. Re: Lost Discover (Chaigneau, Nicolas)
3. Re: Lost Discover (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Dec 2014 16:08:21 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Malformed packets returned by Kea
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194b9...@de-cm-mbx06.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
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 :)
Regards,
Nicolas.
> 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.
------------------------------
Message: 2
Date: Tue, 23 Dec 2014 17:35:58 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>, Marcin
Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Lost Discover
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194b9...@de-cm-mbx06.corp.capgemini.com>
Content-Type: text/plain; charset="iso-8859-1"
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 :)
Regards,
Nicolas.
> 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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
-------------- 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-0001.obj>
------------------------------
Message: 3
Date: Tue, 23 Dec 2014 18:41:02 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Lost Discover
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
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
> :)
>
>
>
> Regards,
> Nicolas.
>
>
> > 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
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 9, Issue 11
**************************************
