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. Issue with INIT-REBOOT use case - Kea returns a NACK
(Chaigneau, Nicolas)
2. Re: Issue with INIT-REBOOT use case - Kea returns a NACK
(Chaigneau, Nicolas)
3. Re: Issue with INIT-REBOOT use case - Kea returns a NACK
(Marcin Siodelski)
4. Malformed packets returned by Kea (Chaigneau, Nicolas)
5. Re: Malformed packets returned by Kea (Chaigneau, Nicolas)
6. Re: Malformed packets returned by Kea (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Dec 2014 15:18:57 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Issue with INIT-REBOOT use case - Kea returns a
NACK
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194b8...@de-cm-mbx06.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I believe there may be an issue with the following use case (Kea version 0.9) :
A client in "INIT-REBOOT" state sends a DHCP Request to Kea.
The message contains option 50 (Requested IP address), and no option 54 (DHCP
Server Identifier).
The requested IP address belongs to the subnet identified by the giaddr, so
this is a valid INIT-REBOOT case.
Kea has no knowledge of this client.
- Observed behavior:
Kea returns a NACK.
In the log we have the following DEBUG message:
2014-11-06 16:25:05.828 DEBUG [kea-dhcp4.dhcp4/26599]
DHCP4_INVALID_ADDRESS_INIT_REBOOT invalid address 10.157.49.213 requested by
INIT-REBOOT client (id: 01:00:21:6a:71:60:c4, hwaddr: hwtype=1
00:21:6a:71:60:c4)
- Expected behavior (according to RFC):
"If the DHCP server has no record of this client, then it MUST remain silent"
(see RFC 2131, chapter 4.3.2 DHCPREQUEST message, section "DHCPREQUEST
generated during INIT-REBOOT state")
If you agree this is abnormal, I'll open a ticket.
Regards,
Nicolas.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20141222/df5ecc8e/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 22 Dec 2014 15:27:18 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Issue with INIT-REBOOT use case - Kea returns a
NACK
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194b8...@de-cm-mbx06.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
In addition, the returned NACK is malformed (according to Wireshark).
It contains option 50 (Requested IP address) with a length of 1, containing
"1F". (0x 32 01 1F)
> I believe there may be an issue with the following use case (Kea version 0.9)
> :
>
> A client in "INIT-REBOOT" state sends a DHCP Request to Kea.
> The message contains option 50 (Requested IP address), and no option 54 (DHCP
> Server Identifier).
> The requested IP address belongs to the subnet identified by the giaddr, so
> this is a valid INIT-REBOOT case.
>
> Kea has no knowledge of this client.
>
>
> - Observed behavior:
>
> Kea returns a NACK.
> In the log we have the following DEBUG message:
> 2014-11-06 16:25:05.828 DEBUG [kea-dhcp4.dhcp4/26599]
> DHCP4_INVALID_ADDRESS_INIT_REBOOT invalid address 10.157.49.213 requested by
> INIT-REBOOT client (id: 01:00:21:6a:71:60:c4, hwaddr: hwtype=1
> 00:21:6a:71:60:c4)
>
>
> - Expected behavior (according to RFC):
>
> "If the DHCP server has no record of this client, then it MUST remain silent"
>
> (see RFC 2131, chapter 4.3.2 DHCPREQUEST message, section "DHCPREQUEST
> generated during INIT-REBOOT state")
>
>
>
> If you agree this is abnormal, I'll open a ticket.
>
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: 3
Date: Mon, 22 Dec 2014 17:43:45 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Issue with INIT-REBOOT use case - Kea returns a
NACK
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Please open a ticket and we will investigate. I think that there are
cases where the DHCPv4 server may not determine the client's state
correctly. I've been working on the host reservation implementation for
DHCPv4 (#3564) which reworks the allocation strategy extensively. But I
believe it may still have the issue you're pointing out.
Please mention the DHCPNAK issue in the ticket.
Marcin
On 12/22/14 16:27, Chaigneau, Nicolas wrote:
>
> In addition, the returned NACK is malformed (according to Wireshark).
>
> It contains option 50 (Requested IP address) with a length of 1, containing
> "1F". (0x 32 01 1F)
>
>
>
>> I believe there may be an issue with the following use case (Kea version
>> 0.9) :
>>
>> A client in "INIT-REBOOT" state sends a DHCP Request to Kea.
>> The message contains option 50 (Requested IP address), and no option 54
>> (DHCP Server Identifier).
>> The requested IP address belongs to the subnet identified by the giaddr, so
>> this is a valid INIT-REBOOT case.
>>
>> Kea has no knowledge of this client.
>>
>>
>> - Observed behavior:
>>
>> Kea returns a NACK.
>> In the log we have the following DEBUG message:
>> 2014-11-06 16:25:05.828 DEBUG [kea-dhcp4.dhcp4/26599]
>> DHCP4_INVALID_ADDRESS_INIT_REBOOT invalid address 10.157.49.213 requested by
>> INIT-REBOOT client (id: 01:00:21:6a:71:60:c4, hwaddr: hwtype=1
>> 00:21:6a:71:60:c4)
>>
>>
>> - Expected behavior (according to RFC):
>>
>> "If the DHCP server has no record of this client, then it MUST remain silent"
>>
>> (see RFC 2131, chapter 4.3.2 DHCPREQUEST message, section "DHCPREQUEST
>> generated during INIT-REBOOT state")
>>
>>
>>
>> If you agree this is abnormal, I'll open a ticket.
>>
> 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
>
------------------------------
Message: 4
Date: Tue, 23 Dec 2014 08:44:58 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: [kea-dev] Malformed packets returned by Kea
Message-ID:
<ab94b0b675bdf14189cd5a861db36c84194b9...@de-cm-mbx06.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I've opened the ticket for yesterday's issue:
http://kea.isc.org/ticket/3656
I've found other cases in which I have a "malformed packet" (as displayed by
Wireshark).
This can happen in ACK or NACK replies.
It occurred on the following attributes:
Option 50 (Requested IP address): 0x 32 01 1f
Option 51 (IP Address lease time): 0x 33 01 20 (the packet actually contains
two options 51, the first one is correct).
Option 49 (X Window System Display Manager): 0x 31 01 1e
Option 48, 45... etc.
(there may be more, I didn't check all packets yet, but possibly they are all
related).
What is strange is these last three options (49, 48, 45) I don't know where
they come from: they are not defined in my configuration.
If that can help investigation, I can provide pcap captures for these cases
(and for the case described in ticket 3656).
(I've also saved Kea's full DEBUG log of these just in case, but it's big. If
need be, I can probably extract the parts related to malformed requests).
Regards,
Nicolas.
> Please open a ticket and we will investigate. I think that there are cases
> where the DHCPv4 server may not determine the client's state correctly. I've
> been working on the host reservation implementation for
> DHCPv4 (#3564) which reworks the allocation strategy extensively. But I
> believe it may still have the issue you're pointing out.
>
> Please mention the DHCPNAK issue in the ticket.
>
> Marcin
>
> On 12/22/14 16:27, Chaigneau, Nicolas wrote:
> >
> > In addition, the returned NACK is malformed (according to Wireshark).
> >
> > It contains option 50 (Requested IP address) with a length of 1,
> > containing "1F". (0x 32 01 1F)
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: 5
Date: Tue, 23 Dec 2014 09:47:28 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>, 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"
An update on this issue:
Each time, the badly encoded "option" appears after option 81 (Client Fully
Qualified Domain Name).
There is also an option 81 in packet, but with a different value.
In the response it seems a string is appended (always the same:
".example.com.R"), I don't know where that comes from.
For example:
- Received packet contains:
Option 81
Length: 15
Flags: 0x00
A-RR result: 0
PTR-RR result: 0
Client name: PC-de-AADENA
- And (malformed) response packet contains:
Option 81
Length: 29
Flags: 0x08
A-RR result: 0
PTR-RR result: 0
Client name: PC-de-AADENA.example.com.R
And immediately following, we have "0x 32 01 1f" which is interpreted as option
50 (Requested IP Address), with length = 1, value = 1f.
Hope this helps.
Regards,
Nicolas.
> Hello,
>
>
> I've opened the ticket for yesterday's issue:
> http://kea.isc.org/ticket/3656
>
>
>
> I've found other cases in which I have a "malformed packet" (as displayed by
> Wireshark).
> This can happen in ACK or NACK replies.
>
> It occurred on the following attributes:
> Option 50 (Requested IP address): 0x 32 01 1f Option 51 (IP Address lease
> time): 0x 33 01 20 (the packet actually contains two options 51, the first
> one is correct).
> Option 49 (X Window System Display Manager): 0x 31 01 1e Option 48, 45... etc.
> (there may be more, I didn't check all packets yet, but possibly they are all
> related).
>
> What is strange is these last three options (49, 48, 45) I don't know where
> they come from: they are not defined in my configuration.
>
>
> If that can help investigation, I can provide pcap captures for these cases
> (and for the case described in ticket 3656).
> (I've also saved Kea's full DEBUG log of these just in case, but it's big. If
> need be, I can probably extract the parts related to malformed requests).
>
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: 6
Date: Tue, 23 Dec 2014 12:07:26 +0100
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [kea-dev] Malformed packets returned by Kea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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
On 12/23/14 10:47, Chaigneau, Nicolas wrote:
>
>
> An update on this issue:
>
> Each time, the badly encoded "option" appears after option 81 (Client Fully
> Qualified Domain Name).
>
> There is also an option 81 in packet, but with a different value.
> In the response it seems a string is appended (always the same:
> ".example.com.R"), I don't know where that comes from.
>
> For example:
>
> - Received packet contains:
>
> Option 81
> Length: 15
> Flags: 0x00
> A-RR result: 0
> PTR-RR result: 0
> Client name: PC-de-AADENA
>
> - And (malformed) response packet contains:
>
> Option 81
> Length: 29
> Flags: 0x08
> A-RR result: 0
> PTR-RR result: 0
> Client name: PC-de-AADENA.example.com.R
>
> And immediately following, we have "0x 32 01 1f" which is interpreted as
> option 50 (Requested IP Address), with length = 1, value = 1f.
>
>
>
> Hope this helps.
>
>
> Regards,
> Nicolas.
>
>
>
>> Hello,
>>
>>
>> I've opened the ticket for yesterday's issue:
>> http://kea.isc.org/ticket/3656
>>
>>
>>
>> I've found other cases in which I have a "malformed packet" (as displayed by
>> Wireshark).
>> This can happen in ACK or NACK replies.
>>
>> It occurred on the following attributes:
>> Option 50 (Requested IP address): 0x 32 01 1f Option 51 (IP Address lease
>> time): 0x 33 01 20 (the packet actually contains two options 51, the first
>> one is correct).
>> Option 49 (X Window System Display Manager): 0x 31 01 1e Option 48, 45...
>> etc.
>> (there may be more, I didn't check all packets yet, but possibly they are
>> all related).
>>
>> What is strange is these last three options (49, 48, 45) I don't know where
>> they come from: they are not defined in my configuration.
>>
>>
>> If that can help investigation, I can provide pcap captures for these cases
>> (and for the case described in ticket 3656).
>> (I've also saved Kea's full DEBUG log of these just in case, but it's big.
>> If need be, I can probably extract the parts related to malformed requests).
>>
> 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 9
*************************************
