Print

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

[FurryNutz]

Those were some suggestions and information that could help and is why I posted.

Thank you for sharing and yes, this is beyond forum help and needs to be resolved with D-Link

Let us know how it goes.

Good Luck.

[lissyx]

Hello,

Some news. French support contacted me by email last week stating that they are currently working on a fix for my issue and that the firmware should be released by today. Let's hope they achieve it in time so that I can test

[FurryNutz]

Good to hear. Hope it works out.

Please keep us posted on the results and outcome.

[lissyx]

Hello,

Some news. At first, after trying the new firmware, it was still reproducing the issue. However, since last weekend, it seems to be working as expected, and I'm not loosing IPv6 anymore. I only did two things that may have an impact:

• Unplug the AP from power for at least 10 mins
• Set |AdvLinkMTU 1280;| in my radvd config

I can't tell whether it's one of those, but I don't reproduce the issue since this weekend, while it was breaking quite fast previously.

[FurryNutz]

Awesome, I'm wondering of setting this MTU value would have worked on the old FW version as well.

Hope it keeps working well for you.

Enjoy.

[lissyx]

I won't downgrade to check .

This is with firmware v1.30 beta07 rc062(0128101256).

[FurryNutz]

Thank you for confirming the version. Is this the one thats on the Main site?

[lissyx]

No, I got the link from the support, I don't think I'm authorized to disclose it.

[FurryNutz]

well, lets hope that maybe using the new setting for this particular device will help others with this particular device and the DAP-2553. Hopefully, D-Link FR will post it to the mains for public download soon.

I'd let them know your results and request that they post the new FW soon.

Thank you.

No, I got the link from the support, I don't think I'm authorized to disclose it.

[lissyx]

Some news now. It has been more than one week since I don't have anymore issues with my IPv6 connectivity. At the same time, I don't see anymore "Deauth reason 7" errors.

However, I cannot conclude on the fix:

• AP firmware is still v1.30
• laptop upgraded from Ubuntu 13.04 to 13.10
• router upgraded from Debian Squeeze to Debian Wheezy (and kernel from backports, upgrading from 3.2 to 3.14)

So I can't state for sure, but I'm starting to wonder if the bug would not be triggered by bad interaction with another device, be it my laptop or my router.

[FurryNutz]

Glad it's working better. Anything is possible with interactions with other devices, envrionment and WiFi.

Enjoy.

[lissyx]

Okay, I have some other news to add. Three weeks after my previous messages, the AP started to get back to the buggy behavior. I rebooted it once, bug again within the next day, then I rebooted it, and it's now been three weeks that everything is fine.

Nothing has changed to my knowledge within my environment. Moreover, the breakage started during my trip to Berlin

[FurryNutz]

You may have a faulty unit, I recommend that you phone contact your regional D-Link support office and ask for help and information regarding this. We find that phone contact has better immediate results over using email.
Let us know how it goes please.

[lissyx]

Thanks for your feedback, my case at D-Link support is now nearly one year old, I doubt they will replace the unit. That being said, the issue came back two days ago, and I had a closer look at the logs.

So what I can now state for sure is that everytime I loose IPv6 connectivity:
 - it happens exactly after the IPv6 valid lifetime expired
 - there are those "reason 7" errors in the log

I had a closer look at those messages, and I could notice:
 - I see a bunch of "Deauth: STA C8:D3:A3:xx:xx:xx(reason 7)" in the logs
 - this is strange, since it means the AP is deauthenticating itself (the MAC is the one from the AP)
 - I could notice that it happens always after a "4-way handshake fail" happened
 - as far as I could dig in my logs, this "4-way handshake" failure is only ever triggered by my Nexus S device

So the interactions can be summed as:
 - Nexus S connects to EAP-TLS
 - 4-way handshake fails
 - AP tries to deauth the Nexus S, but for some reason (valid, maybe?) the logs shows its own MAC instead of the Nexus S' one
 - Nexus S tries to reauthenticate after 10 seconds
 - 4-way handshake is now succesfull
 - Nexus S does its IPv4 DHCP request and gets an IP address

Then from this point, I'm not able to see any new ICMPv6 RA packets going through the AP.

[FurryNutz]

"it happens exactly after the IPv6 valid lifetime expired"

I'm curious about this idea. Is there anyway you can shut off all IPv6 services and test the DAP with out any IPv6 services running and see if it happens again?