[Kea-users] kea DHCPv6 and clients not working
Włodzimierz Wencel
wlodek at isc.org
Thu Nov 10 10:27:37 UTC 2016
Thanks, we don't yet know why windows does not like messages from Kea.
Yes, we could use equivalent capture from ISC-DHCP to make detailed
comparison.
Also you kea config file could be useful (your recent capture doesn't
show option 23 in advertise message, did you change your config?).
Thanks,
Wlodek Wencel
ISC, QA Engineer
On 11/09/2016 03:07 PM, SoupNazi izaNpuoS wrote:
> Wlodek,
>
> Attached are matching capture files from server and client sides.
> Would you like a capture from server/client side when using ISC DHCP
> for DHCPv6 which functions correctly? Anything else I can provide?
>
> On Tue, Nov 8, 2016 at 2:14 PM, Wlodek Wencel <wlodek at isc.org
> <mailto:wlodek at isc.org>> wrote:
>
> Ok, so this is not the option case. But that capture doesn't bring us
> closer. Server still doesn't receive Request message.
>
> Can you produce capture on client site? We need to know if client is
> sending Request and if so - where it's being lost.
>
> Wlodek Wencel
> ISC, QA engineer
>
> On 11/08/2016 06:18 PM, SoupNazi izaNpuoS wrote:
> > I set the option 24 (I had previously tried that). I wouldn't
> know what
> > to set for option 17. It should be noted that the successful DHCPv6
> > conversation with ISC DHCP and the windows 10 test machine does not
> > contain options 17,24, and 39. Attached is the updated packet
> capture.
> >
> > On Tue, Nov 8, 2016 at 11:28 AM, Wlodek Wencel <wlodek at isc.org
> <mailto:wlodek at isc.org>
> > <mailto:wlodek at isc.org <mailto:wlodek at isc.org>>> wrote:
> >
> > Hello,
> >
> > thanks for reporting this issue, we will try to sort it out
> together.
> >
> > Differences between messages you pointed out should not make be
> > problematic and what you described in point 3 - Kea works
> according
> > to spec.
> >
> > Your capture contains forwarded messages solicit and
> advertise, normally
> > DHCPv6 is performing 4 message exchange. Client should send
> Request
> > after receiving Advertise (unless rapid-commit option is
> allowed, you
> > have that one configured in kea BUT there is no rapid commit
> option in
> > Solicit so clients should perform full 4 way message exchange).
> >
> > It looks like windows client is not happy with what
> Advertise message is
> > containing.
> >
> > In Solicit message client is requesting two option that you
> dont have
> > configured:
> > - option 17 - Vendor-specific Information
> > - option 24 - Domain Search
> >
> > Maybe those options (or just one of them) are mandatory for your
> > clients? Can you configure them and send the results?
> >
> > Thanks,
> > Wlodek Wencel
> > ISC, QA Engineer
> >
> > On 11/08/2016 03:47 PM, SoupNazi izaNpuoS wrote:
> > > Folks,
> > >
> > > I am testing kea for DHCPv6 with three test clients. A
> windows 10
> > > laptop, a Linksys router and a D-Link router. All three
> of these
> > > clients can receive DHCPv6 addresses + PD (where
> applicable) from ISC
> > > DHCP server. Only the D-Link can successfully receive
> DHCPv6 from the
> > > kea server.
> > >
> > > DHCPv4 portion of the kea server is working fine.
> > >
> > > Version: Kea DHCPv6 server version 1.1.0 (installed from
> EPEL repo on
> > > Centos 7)
> > >
> > > It should be noted that there is a Juniper SRX that is the
> relay
> > agent.
> > >
> > > I see the relay-forward and relay-reply messages on the
> server with
> > > tcpdump. I see the solicit/advertise messages on the
> windows 10
> > client
> > > with Wireshark. Windows, using ipconfig /renew6 in
> command prompt,
> > > shows an ultra-informative error:
> > >
> > > "An error occurred renewing interface Ethernet : The
> parameter is
> > incorrect"
> > >
> > > and windows 10 assigns no IPv6 address to the interface.
> The Linksys
> > > similarly assigns no address but I have no error to show
> or anything.
> > >
> > > I compared the packet capture with the ISC DHCPv6 packet
> capture and
> > > noticed three differences in the relay-reply:
> > >
> > > 1) option 3 (identity association for non-temporary
> address) was
> > listed
> > > first in the packet on the ISC DHCPv6 and was 3rd in the
> kea packet.
> > >
> > > 2) option 3 had values of 500 and 400 for T1 and T2
> respectively
> > in the
> > > Kea packet and both were 0 in the ISC DHCPv6 relay-reply
> packet.
> > >
> > > 3) Kea DHCPv6 packet had option 39 FQDN (requested by
> client) and the
> > > ISC DHCPv6 packet contained no such option even though
> requested
> > by the
> > > client.
> > >
> > > I'm assuming I've missed something in the config that is
> necessary for
> > > 67% of clients to work :)
> > >
> > > Here is the DHCPv6 portion of my config:
> > >
> > > "Dhcp6": {
> > >
> > > "interfaces-config": {
> > >
> > > "interfaces": [
> "enp4s0/2620:0:2e50:e4::226" ]
> > >
> > > },
> > >
> > > "dhcp-ddns": {
> > >
> > > "enable-updates": false
> > >
> > > },
> > >
> > > "lease-database": {
> > >
> > > "type": "mysql",
> > >
> > > "name": "keatest",
> > >
> > > "host": "localhost",
> > >
> > > "user": "<hidden>",
> > >
> > > "password": "<hidden>",
> > >
> > > "connect-timeout": 3
> > >
> > > },
> > >
> > > "preferred-lifetime": 600,
> > >
> > > "valid-lifetime": 600,
> > >
> > > "renew-timer": 500,
> > >
> > > "rebind-timer": 400,
> > >
> > > "option-data": [{
> > >
> > > "name": "dns-servers",
> > >
> > > "code": 23,
> > >
> > > "space": "dhcp6",
> > >
> > > "csv-format": true,
> > >
> > > "data": "2620:0:2e50:a::233,
> > 2620:0:2e50:a::234"
> > >
> > > }],
> > >
> > > "subnet6": [{
> > >
> > > "subnet": "2620:0:2e50:e8::/64",
> > >
> > > "rapid-commit": true,
> > >
> > > "pools": [ {
> > >
> > > "pool":
> > > "2620:0:2e50:e8::2-2620:0:2e50:e8::ffff"
> > >
> > > } ],
> > >
> > > "pd-pools": [{
> > >
> > > "prefix":
> "2620:0:2e50:f000::",
> > >
> > > "prefix-len": 52,
> > >
> > > "delegated-len": 64
> > >
> > > }]
> > >
> > > }]
> > >
> > > },
> > >
> > >
> > > Attached is the server side packet capture for Kea DHCPv6
> > server... Any
> > > ideas?
> > >
> > >
> > > _______________________________________________
> > > Kea-users mailing list
> > > Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
> <mailto:Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>>
> > > https://lists.isc.org/mailman/listinfo/kea-users
> <https://lists.isc.org/mailman/listinfo/kea-users>
> > <https://lists.isc.org/mailman/listinfo/kea-users
> <https://lists.isc.org/mailman/listinfo/kea-users>>
> > >
> > _______________________________________________
> > Kea-users mailing list
> > Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
> <mailto:Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>>
> > https://lists.isc.org/mailman/listinfo/kea-users
> <https://lists.isc.org/mailman/listinfo/kea-users>
> > <https://lists.isc.org/mailman/listinfo/kea-users
> <https://lists.isc.org/mailman/listinfo/kea-users>>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/b02a5c43/attachment.htm>
More information about the Kea-users
mailing list