[Kea-users] kea DHCPv6 and clients not working
Wlodek Wencel
wlodek at isc.org
Tue Nov 8 19:14:21 UTC 2016
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>> 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>
> > 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>
> https://lists.isc.org/mailman/listinfo/kea-users
> <https://lists.isc.org/mailman/listinfo/kea-users>
>
>
More information about the Kea-users
mailing list