AX201 Stateless Autoconfiguration IPv6 not working reliably after Sleep/Hybernate

[KiPe]

This is a follow-up tread from

https://community.intel.com/t5/Wireless/IPv6-SLAAC-broken-on-AX200-w-recent-22-x-drivers-on-Windows-10/td-p/1246367

I have switched laptop from one with AX200 to one with AX201.

Also, it has been a while since I last tested and new driver version is: 22.100.0.3

Situation is:

SLAAC works reliably after fresh boot / reboot.

SLAAC does NOT work reliably after sleep / hybernate.

I.e., after coming out of sleep you see that the NIC does not receive the right prefix of the network and does not assign itself a public ipv6 address. It comes up with a link-local fe80:: only.

"ipconfig /renew6" sometimes fixes the issue

alternatively

letting sit the laptop idle for a few minutes (until unsolicited announcements arrive) sometimes fix the issue

Next stop: driver update.

[Alberto_R_Intel]

Hello KiPe, I Just received an update on this matter.

After investigating the issue we determine that the source of the problem is actually happening at Operating System level. So, the next thing to do will be to get in contact directly with HP support to report this scenario so they can further assist you on this subject:

https://support.hp.com/us-en

Regards,

Albert R.

Intel Customer Support Technician

[Gnk_k]

Ciao @Alberto_R_Intel ,

issue is seen also from my side. Tried different kind of intel wireless card, several laptop with windows 10.

Bought just some days ago this:
Driver : Intel(R) Wi-Fi 6E AX210 160MHz
Vendor : Intel Corporation
Provider : Intel
Date : 24/05/2022
Version : 22.150.0.3
INF file : oem6.inf
Type : Native Wi-Fi Driver
Radio types supported : 802.11b 802.11g 802.11n 802.11a 802.11ac 802.11ax

Same behaviour, I can't get ipv6 when I connect or as @KiPe explained.

Thanks.

[KiPe]

Its been a while since I last updated this thread.

I)

Last changes: I moved to the latest driver (22.220.0.4) on Windows 10 -> same problem.

II)

Then I changed my home network setup to do DHCPv6 instead of SLAAC (in an attempt to work around the issue).
NOTE: I am using a FritzBox with 7.50 OS as the DHCP(v6) server and router in my network.

Enabling DHCPv6 however yields a different behaviour which I am mentioning because some people might see it.

In fact, with DHCPv6 enabled, you will receive an IP address (this is then different from my initial description here).

BUT: you will NOT be able to access any external IPv6 address nevertheless.

This is because the DHCPv6 ack is not coming with a default router option (not part of DHCPv6!).

The default route / gateway setup still relies on SLAAC (in fact, relies on the router advertisements).

So the condition in this setup is: You have an IPv6 address, BUT, you cannot use it.

If you look at services like "what is my IP", you will see that you only have an IPv4.

How to detect DHCPv6 connection issues:

If you try to ping an ipv6 site ("ping -6 google.com") it will fail with a "PING: transmit failed. General failure."

If you print the routing table "route -6 print"), you see the default route IPv6 missing (::/0 entry is not existing).

This is because there is no default IPv6 route is set, which again is the consequence of this obscure Intel NIC/Windows10 bug.

III)

Next Stop: Update to Windows 11

[KiPe]

Replying to myself to add one thing:

In fact, IPv6 / DHCPv6  _CAN_  be a workaround for the bug discussed in this thread, but you have to do two things:

1) enable DHCPv6 in your network

2) set a static IPv6 default route on all of your computers affected ("route add ::/0 fe80::1 -p")

Note that the default route is using the link local default router address, this way it will be _always_ valid, in each network that is IPv6 enabled... and hence it is safe to set it "-p" persistent.

[Thomas_I_samohT]

Hello KiPe,

I received a notification that there are new message in this thread. So I thought it is a good idea to share my recent experiences with this issue, as it also kept my occupied for some time last year.

When installing Windows 11 on one of the laptops mid of last year, the issue also appeared after resuming from standby. At this my conclusion was, that this is not a matter or question of Windows 10 vs 11.

Now, I had to anyhow reinstall OS on my Lenovo Yoga Slim with AX210 NIC begin of this year, because of some issues with the builtin hard disc.Thus, I decided to give Windows 11 another chance. This time, I used the English OS image version, which I prefer anyhow (because of some strange translations from ENG to GER) .

And what I can say - I've never seen this issue since the time I re-installed the OS in January.

So my guess, although not a proof, is, that the language OS version matters for this issue. 

I also have Fritz!OS 7.50 on my current home router (in the meantime a FB6690) but for IPv6 I still use SLAAC.

The only "weird" thing remaining, is that there are still many entries in the event log of the DHCPv6 client, stating that the M and O flags have changed according to RAs received on the network adapter, although in fact the values remain unchanged all the time (and the values are as expected: M=false, O=true).

Before the new installation, I did some tests, but even if you can switch the GUI language of an existing OS from DE to EN, it somehow still thinks it is a German OS, because the advanced properties tab for the NIC in device manager still are shown with German translation. Only after fresh installation, the parameter names are shown correctly in English.

Maybe, you want to start with a fresh Windows 11 OS installation (no upgrade of existing OS) and also install the image for EN language.

Btw: another problem was that in my mixed Mesh environment (Fritz!box 6660 Router with Wifi 6, Fritz!Repeater 2400 with Wifi5 only) starting with a certain Intel driver version the Lenovo laptop always connected to the Repeater (sticky), even if the signal of the Router was much stronger. Some months ago I replaced the Repeater with Wifi 6 version (Fritz!Repeater 1200AX) and since then the laptop no longer "sticks" to the Repeater, but also connects directly to the Router, depending on signal strength.

[Gnk_k]

Hi @Thomas_I_samohT ,

I don't think that reinstallation of Windows OS would be a nice solution. Kipe and I opened two bugs more than 1 years ago but the only thing I can't understand is why we are able to reproduce the issue, that is very stressful when you test ipv6, and no one from intel support is able to reproduce or say: ok we have an issue on this.

I didn't expect from Intel support honestly but I do not want to make controversy.

@KiPe I will try your suggestion thank you very much.

[Thomas_I_samohT]

Hi Gnk_k,

Surely, I don't want to recommend to you to reinstall OS, because I know that is usually a big effort.

Anyhow, for me this solved the problem (at least it is the only thing that I changed compared to the old setup and since which I don't get this error any longer).

And (another guess) Intel Support maybe also works with native English OS version. So this could be a reason why they are not able to reproduce the error, because it just doesn't occur in such environment.

Maybe I am entirely wrong and some other factor/change (that I don't see right now) has resolved the problem for me on the same piece of hardware. What you could also do in this case, is to install another OS (Windows 11 EN) parallel to existing OS, e.g., on a virtual hard disc (VHDX). If the problem then still occurs - you would have the old OS installation, and can easily get rid of the new one.

What OS language version do you use by the way ?

Regards

Thomas

Update: I think I also tested different IPv6 settings in my router last year, including the option of assigning IPv6 address via DHCPv6 Server. And I think this eventually lead to the same issues, because the information of how IPv6 addresses are assigned in the network comes by RA message, and these messages are, sometimes, not received by the laptop. Consequently, it won't send request to the DHCP server and request IPv6 address and it will lead to same situation that IPv6 connectivity is lost.

[KiPe]

An update after upgrading to Windows 11.

Going to Windows 11, I did via an in-place update, not a completely new installation.

I am now on Windows 11, 22H2, Build 22621.1555, all the latest updates and drivers installed.
Intel driver however remained unchanged since Windows 10, as I had updated before and tested the latest version already.

I am unaware of my OS image language. But had always set OS interface language to English, since Windows 10 already.
Somehow it feeld I have a mixed german/english version.
But checking the registry [1] now, it seems to show my OS install language is indeed German.

I have been running some extended tests yesterday and today and I am unable to reproduce the issue now.

Will continue to test, but right now it seems as if:

- bug is at least harder to reproduce on windows 11 (possibly fixed?)

- os install language as well as in-place installation have no adverse effect

Judging from what Thomas outlined earlier (his Windows 11 test with negative result / no fix) somewhat earlier last year, this could mean that the bug is indeed only fixed after a specific release of windows 11?

Intel, can you confirm this?

Cheers

Kai

[1]

on the command line execute:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Nls\Language" /v Installlanguage

yieling a

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language
Installlanguage REG_SZ 0407

[thaddeus842j]

I have been following this thread for a while, as I have been having this issue on an ASUS Zephyrus G14 GA402XV with an Intel AX210 wifi card I put in it to replace the stock wifi. I am running Intel driver 22.250.1.2.

I recently made some progress on working around this issue. I found that any frame forwarding delay introduced by the AP after the OS/driver considers the link "up" will lead to this issue.

KiPe - do you get different behavior in the following to situations?

• Connecting to a SSID when there is NO other client currently connected
• Connecting to that SSID after some other client is already active

In my case, using Mikrotik APs, the bridge port for the wlan interface is down when there are no clients connected. When the first client connects, that port is enabled. The bridge did not start forwarding frames immediately because the bridge had RSTP enabled and would introduce a forwarding delay when the wlan bridge port first came "up". Disabling RTSP on the AP bridges resolved my issues.

When SLAAC fails because of the forwarding delay immediately after connecting, I never get an IPv6 IP, even later when unsolicited RAs go out.

My specific situation is unique to my equipment, but I am curious if other APs may have longer or shorter forwarding delays based on if there are already clients connected or not.

There seems to be an issue in either the Windows IP stack or Intel's wifi driver where things get into a bad state if transmitted frames are dropped for the first few seconds after the OS / driver considers the link "up".

[KiPe]

Hi There,

unfortunately, I have no setup at hand anymore where I can reproduce the issue - as it seems to have vanished with Windows11.

That said - as the OS Version solved it for me and also - as in my setup numerous  other systems did not reproduce the error - I would assume your infrastructure related description did not apply to me.

Also, I was able to reproduce it in the most simplistic setup possible, Home router (FritzBox) which is WiFi AP and gateway all in one, with various devices already connected while testing.

Cheers