[kea-dev] Malformed packets returned by Kea

Marcin Siodelski marcin at isc.org
Tue Dec 23 11:50:49 UTC 2014


Oh, I forgot to mention that with the latest Kea version you have the ability to select an IPv4 address on the interface with multiple addresses, on which you want Kea to listen. However, it still lacks the ability to filter out the unicast packets sent to a different address as described in #3547.

Anyway, I recall you were after this feature, so you might want to test it.

Marcin


On 12/23/14 12:07, Marcin Siodelski wrote:
> 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
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
>



More information about the kea-dev mailing list