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