Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[drshock]

I successfully applied the 1.20 patch for KRACK mentioned here http://forums.dlink.com/index.php?topic=72763.msg292201 at the top of the forums today.
 
I just upgraded without a factory reset since this is a same version patch.  No problems applying the patch. 

I applied this on a DAP2695 in a production environment, though its after hours currently and only 11 clients connected.   Will see how it manages the rest of this week and post back if there are any issues uncovered.

[FurryNutz]

Thanks for letting us know. Hope it works for other users as well.

Enjoy. 

[drshock]

I haven't seen any new problems with this beta patch for KRACK on the DAP-2695.   I've been using the unit in production running both IPv4 and IPv6 traffic as usual.   It's been stable and no obvious regressions.
 
I did however find one new firmware bug that I missed previously with 1.20RC75.   This was noticed this time because we have additional IPv6 firewall rules logging at our Vyatta edgerouter since the new year.   
 
The DAP is repeatedly sending out DHCPv6 router solicit messages, even after the router has acknowledged them.  This is within a SLAAC + stateless DHCPv6 configuration only.   The problem with this bug is that it not only will rapidly fill a syslog with noise, but it puts a CPU load on the DAP as well as the responding DHCPv6 server.   I ended up disabling IPv6 on the DAP-2695 to shut this down, and immediately got a 1% CPU gain back on the DHCPv6 server in such an endless loop.
 
My warranty is expired for this DAP-2695, so I cannot contact D-Link support to report it officially.  Hopefully someone from D-Link engineering will notice this, as it's likely an obvious fix (stop sending out the broadcast solicit messages once the router responds with the DHCPv6 additional information reply message).   In this type of enterprise IPv6 configuration, the only response is going to be internal corporate DNS name server locations as the DAPs IP is assigned via SLAAC (which the DAP-2695 correctly handles and shows in the UI along with the router gateway v6 address).  DHCPv6 is not used to assign addresses, only to assign other configuration settings (i.e., internal DNS servers). The DNS info is irrelvant to the DAP so it shouldn't be asking for this additional information in the first place when stateless DHVPv6 is employed in addition to SLAAC.

[FurryNutz]

Something you could email or contact D-Link support on Chat about and let them know what your experiencing...

I haven't seen any new problems with this beta patch for KRACK on the DAP-2695.   I've been using the unit in production running both IPv4 and IPv6 traffic as usual.   It's been stable and no obvious regressions.
 
I did however find one new firmware bug that I missed previously with 1.20RC75.   This was noticed this time because we have additional IPv6 firewall rules logging at our Vyatta edgerouter since the new year.   
 
The DAP is repeatedly sending out DHCPv6 router solicit messages, even after the router has acknowledged them.  This is within a SLAAC + stateless DHCPv6 configuration only.   The problem with this bug is that it not only will rapidly fill a syslog with noise, but it puts a CPU load on the DAP as well as the responding DHCPv6 server.   I ended up disabling IPv6 on the DAP-2695 to shut this down, and immediately got a 1% CPU gain back on the DHCPv6 server in such an endless loop.
 
My warranty is expired for this DAP-2695, so I cannot contact D-Link support to report it officially.  Hopefully someone from D-Link engineering will notice this, as it's likely an obvious fix (stop sending out the broadcast solicit messages once the router responds with the DHCPv6 additional information reply message).   In this type of enterprise IPv6 configuration, the only response is going to be internal corporate DNS name server locations as the DAPs IP is assigned via SLAAC (which the DAP-2695 correctly handles and shows in the UI along with the router gateway v6 address).  The DNS is irrelvant to the DAP so it shouldn't be asking for this additional information in the first place when stateless DHVPv6 is employed in addition to SLAAC.

[Gattsu]

drshock, so issue is replicated on firmware ver. 1.20RC93? And you've verified the AP has received an IPv6 address? If you have packet captures, please provide a copy.

Thanks!

[drshock]

@Gattsu, thanks for commenting.
 
So if we SSH into the DAP-2695 after enabling IPv6 in the GUI, we can find the redacted information looks properly configured except DNS (which we shouldn't really care about here):

Code: [Select]

WAP-> get ipv6
ipv6 dnsaddr                        -- Show DNS server IPv6 address
ipv6 enable                         -- Enable IPv6 protocol stack
ipv6 gateway                        -- Show Gateway IPv6 address
ipv6 ipaddr                         -- Show IPv6 address
ipv6 mode                           -- Show IPv6 mode
ipv6 prefix                         -- Show IPv6 prefix
WAP-> get ipv6 ipaddr
2606:a000:xxxx:xxxx:xxxx:xxxx:xxxx:7710
WAP-> get ipv6 gateway
fe80::xxxx:xxxx:xxxx:99d3
WAP-> get ipv6 dnsaddr

WAP-> get ipv6 mode
auto
WAP-> get ipv6 prefix
64

But when we initiate a port 547 packet capture on the Vyatta router we see the endless loop of solcit messages and replies in a redacted exerpt here:
 

Code: [Select]

admin@vyatta3:~$ show interfaces ethernet eth1 capture port 547
Capturing traffic on eth1 port 547 ...
19:08:02.859717 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 solicit
19:08:02.862125 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 advertise
19:08:03.951641 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 solicit
19:08:03.953863 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 advertise
19:08:04.955673 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 request
19:08:04.956768 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 reply
19:08:05.751564 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 solicit
19:08:05.752841 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 advertise
19:08:06.756632 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 request
19:08:06.758074 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 reply
19:08:07.251573 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 solicit
19:08:07.253538 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 advertise
19:08:08.255687 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 request
19:08:08.256787 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 reply
19:08:08.623570 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 solicit
19:08:08.624882 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 advertise
19:08:09.627691 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 request
19:08:09.628794 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 reply
19:08:09.691581 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 solicit
19:08:09.692931 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 advertise
19:08:10.695717 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 request
19:08:10.697692 IP6 fe80::xxxx:xxxx:xxxx:99d3.547 > fe80::xxxx:xxxx:xxxx:7710.546: dhcp6 reply
19:08:11.242477 IP6 fe80::xxxx:xxxx:xxxx:7710.546 > ff02::1:2.547: dhcp6 solicit
Is this configuration the router is also the DHCPv6 server.  What I typically see in this type of SLAAC + stateless DHCPv6 configuration (and what the other devices in our IPv6 network are doing) is a specific one time four step dance following SLAAC autoconf, which using the https://en.wikipedia.org/wiki/DHCPv6 example as an overview is as follows:
 
1) Device initiates a solicit on IPv6 broadcast ff02::1:2.547 per RFC3315 - The DAP-2695 correctly does this
2) The router detects the broadcast and responds with an advertise to the client on 546 - We see the router do this
3) The client should then request the additional DNS information on ff02::1:2.547 - We see the DAP-2695 do this (sometimes)
4) The server then finishes with a reply to the client with the information on 546 - We see the router do this also

The DAP-2695 then starts this dance all over again, in error, endlessly.   It should have stopped once receiving the step 4 reply.  Though, unless I'm missing something an AP requesting IPv6 DNS server information is probably unneeded, as it got everything needed via SLAAC already.

If you wanted to PM me an email address I could send a tcpdump output that shows more lower level detail of this same endless loop.

[Gattsu]

I have attempted to replicate this issue but my 2695 is only sending "solicit" messages every 5-20 seconds but no "reply" or "advertise" from the gateway link local address.

"Source- fe80::7a54:2eff:feaa:ea10     Destination- ff02::1:2      Protocol: DHCPv6   136    Solicit XID: 0xb46be0 CID: 00010001c792bc9278542eaaea10 "

Hardware Settings:

--DAP-2695 on default settings with IPv6 enabled

Link-Local IPv6 addres:  fe80::7a54:2eff:feaa:ea10   

WAP-> get ipv6 ipaddr
3001:1212::7a54:2eff:feaa:ea10
WAP-> get ipv6 gateway
fe80::eacc:18ff:fe15:9fe0
WAP-> get ipv6 pref
64

--DXS-3600- IPv6 DHCP Stateless
Switch(config)#int vlan 1
Switch(config-if)#no sh
Switch(config-if)#ipv6 address 3001:1212::/64 eui-64
Switch(config-if)#ipv6 nd prefix 3001:1212::/64
Switch(config-if)#no ipv6 nd suppress-ra
Switch(config-if)#ipv6 nd other-config-flag


Here is the packet captures: https://www.dropbox.com/s/xv4k6ckd8i30dhc/2695-Ipv6%20DHCP.zip?dl=0

[drshock]

@Gattsu,
Thanks for checking, I really appreciate your trying to repro this to get a ticket opened. 

So your DAP-2695 would be same config as mine (presuming it's running 1.20 firmware).  But if your router is not advertising/replying, then there's not a SLAAC + stateless DHCPv6 handshake going on in your config.   It's a vanilla RFC3315 four message handshake we need to recreate the bug.  I am not familiar with the DXS-3000, but it looks like a layer 3 switch with routing capabilities (very nice).  In order to replicate the config exhibiting the bug, we need to get into the RFC3315 dance using SLAAC.

Suggesting perhaps this CLI instead for your test.  Again I am not familiar with the DXS series but rather Brocade/Vyatta but I did a quick read of the manual:

Code: [Select]

Switch(config)#int vlan 1
Switch(config-if)#no sh
Switch(config-if)#ipv6 enable
Switch(config-if)#ipv6 address autoconfig [default]
Switch(config-if)#no ipv6 nd suppress-ra
Switch(config-if)#no ipv6 nd managed-config-flag
Switch(config-if)#no ipv6 nd other-config-flag
Switch(config-if)#ipv6 dhcp pool testpool
Switch(config-if)#ipv6 dns-server 2001:4860:4860::8888

What I'm hoping you can get from the above CLI, even if incorrect for the DXS, is that we want to get your VLAN1 interface into SLAAC autoconf mode for IP issuance plus the bare minimum default RA, and then tell the DXS only give out DNS on DHCPv6/no IPs.  we also want to explicitly omit the [Rapid Commit] option on the dhcp pool command to get the four message handshake instead of the two message handshake for that DNS response.   Again, to try and replicate the config I'm reporting on.  The router advertisements CLI above should replicate the default with SLAAC.  My radvd.conf is below (vanilla out of the box config) for reference as to why I chose the particular DXS RA cli commands.
 

Code: [Select]

interface eth1 {
#   This section was automatically generated by the Vyatta
#   configuration sub-system.  Do not edit it.
#
#   service type [slaac]
#
    IgnoreIfMissing on;
    AdvSendAdvert on;
    AdvManagedFlag off;
    AdvOtherConfigFlag off;
    prefix ::/64 {
          AdvOnLink on;
          AdvAutonomous on;
    };
};

Stick with me just a little longer on this, you'll see it loop if we can get the right config setup.  ;-)

BTW, in my case the router is also the DHCPv6 server hence the link local address you're seeing in my previous post.

[Gattsu]

Looks like you have both M and O bits off, does this mean your ISP is providing the public IPv6 addresses?

Please see my private message, I have requested a copy of the tcpdumps and other things. I will have this escalated to have it further analyzed.

Thank you!