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.

I sent you an email. Please verify your inbox.

Regards,

Albert R.

Intel Customer Support Technician

[KiPe]

Dear Albert,

Is there an update on this issue?

Has Intel been able to set up a test environment suitable to re-create the issue, potentially even re-created the issue?

Thanks and regards

[Thomas_I_samohT]

Hello,

I am new in this forum, but already spent a lot of time for investigation of an issue very similar (likely the same) as described by KiPe.

I am having 2 Lenovo Laptops here:

Yoga S740 with Intel AX201 (laptop shipped with this NIC)

Yoga Slim 7 Carbon with Intel AX210 (I replaced a RTL8852AE chip with this NIC)

Both laptops / NIC have the same issue. When NIC is initializing (after standby, hibernate,  or even after temporarily disabling WiFi connection with system tray icon in Windows 10) IPv6 connectivity is not reliably restored and "ipconfig" shows only link local address but no public IPv6.

I conntacted the manufacturer of the router (AVM Cable Fritzbox 6660) but they don't seem to know a problem.

What I did so far and found out:

The local WireShark protocols shows that both Intel NICs during the "initialization phase" send out 3 Router Solicitation (RS, ICMPv6 Type 133) message with 1 second delay between each. Local WireShark protocol on both devices, however, show also that no Router Advertisement (RA, ICMPv6 Type 134 ) message is received and/or processed for any of the 3.

WireShark protocols from other computers on the network (tested both, LAN and WLAN)  show, that the router is sending total 3 RA messages as response to the RS.

Both laptops show the same issue with another router, too. (tested with travel router GL iNet AC750S).

Other laptop with RTL8852AE NIC doesn't seem to have this problem for IPv6 connectivity with my router.

I have tested various driver versions. In both cases the latest drivers provided by Lenovo, but also most recent Intel WiFi drivers (22.120.x) - the problem is the same with all tested drivers.

A workaround that improves the situation, but which not fully resolves is, is the following:

* I have created a scheduled task that is triggered by successfull restoration of WLAN connectivity with a delay of 10 seconds and which will execute a simple "ipconfig -renew6 WLAN" which forces the laptops to send another RS message which is (in many cases) leading to RA message which is also received by the problematic NICs.

I have attached an Excel workbook with 2 sheets, each containing an excerpt of a WireShark logfile for the same time period (time stamp are almost the same, only part of a second difference). One was recorded with the Lenovo Yoga Slim 7 Carbon with Intel AX210 NIC and it shows the ICMPv6 network traffic while disconnecting and reconnecting the laptop to the WiFi network few times. The second one was recorded simultaneously on another computer connected by LAN to the same router. When comparing the 2 logfiles you can clearly recognize the difference, i.e., that the RA messages are only received/processed/visible by the LAN device.

I truely hope that this information helps you in identifying the problem to eventually find a working solution or fix.

Thanks & greetings from Germany

Thomas

[KiPe]

Hi Thomas,

sounds like the exact same issue that I also reproduced. Great to have you part of this thread.

I also do not see the RA in response to RS, but as I see them for all my other devices, I am pretty sure it is some sort of (unintenional) ingres filtering mechanism on the Intel WLAN NIC.

The RA (in response to RS) definitly exist in my network, so same situation here.

As SLAAC relies on (IPv6)Multicast, my wild guess was that some multicast membership/filtering table is not correctly set up after wake.

I.e. the mac address equivalent of ff02::1 (ipv6 mcast for "all nodes") , which is 33:33:00:00:00:01 is (temporarily) not received on WiFi.

Your Excel dump to me also seems to be pointing there... lets see what Intel will make out of this.

Cheers,
Kai

[Thomas_I_samohT]

Hello Kai, hello Support Team

Kai's explanation seems plausible and let's see if Intel can reproduce the error and find a solution (which I hope).

What is also visible in the Windows event viewer (eventvwr.msc), and the detailed log of the DHCPv6 Client:

There are multiple entries, partially within 1 or 2 seconds, indicating sequential changes in the router advertisement settings (source: "Microsoft-Windows-DHCPv6 Client Events/Admin", eventID 1006), although there are no such RA messages in the WireShark logfile with a corresponding time stamp.

Over time I see all kind of combinations of ICMPv6 M-flag (managed address configuration) and O-flag (other stateful configuration) in this log file. Sometimes M-flag is set to "true", which means the NIC thinks it is now using stateful address configuration and tries to obtain IPv6 address from the router. But as the router is in SLAAC mode it will not provide such address --> this is usually leading to situation when "ipconfig -renew6" will not work as short-term solution. You described this as the "non-recoverable" scenario earlier in this thread.

At least on the Lenovo Yoga S740 (modeltype 14IIL) I recently installed a clean Windows 10 21H2 with image from Microsoft and the problem still persists. The other laptop was shipped last December with Windows 11 Professional - which showed the problem. 2 months ago I downgraded to Windows 10 21H2, fully patched, and also have the problem. So I assume it is not an issue of the operating system, too.

I also tried to reset the router to factory defaults, and rebuilt the former configuration manually (without restoring existing configuration file) -> problem still exist. Plus, the fact that the problem also occurs on my travel router, I think it is also not an issue of the router.

Regards,

Thomas

[KiPe]

Dear Thomas,

I would like to emphasize what you wrote: The router is probably not the issue here.
Rationale: I have personally reproduced this issue in two different networks with three different routers (Cisco, FritzBox and Vodafone HW). With your setup being environment number 4.

Regards,

Kai

[Thomas_I_samohT]

[content deleted and posted as new message in this thread]

[Thomas_I_samohT]

I found out some further information, which could be helpful for further investigation.

This morning I installed on the laptop with Intel AX210 NIC a fresh Windows 11 Professional (to VHDX / virtual disk) and booted from it.  This time I downloaded and used the English ISO from Microsoft as source of the installation (so far, I had always used German OS version).

After installation of all initial updates, and newest drivers (Intel WiFi driver 22.120.x) I also installed WireShark and started another tests.

In these tests I found out that there was no longer an issue with missing or lost RA messages and SLAAC seemed to be finally working in reliable manner.

In most cases, following activation of network connectivity already for the 1st RS message an RA was received according to WireShark logfile.

In very small number of cases, the laptop had to send a 2nd RS message until RA was received from router. I had the feeling that this mainly occurred whenever the time period between deactivation and activation of network connectivity was very short (<2 seconds or so).

Only in one of many tries, for first 3 RS messages, there was no RA message visible in WireShark log. But few seconds later laptop sent another another RS and then it also received an RA.

That leads to following guesses or conclusion:

1) The OS language version could play a role here and English OS version may possibly not be affected. This could also be a reason why Intel engineers cannot reproduce this error. (speculative; so far based on only on a single test).

2) Whenever the NIC was just switched-off and then immediately re-initializes this could also lead to loss of some RAs.

If I find some time, I will maybe more tests, maybe again with installation of German Windows 11 ISO to VHDX and see, if the error occurs or not.

KiPe: what OS language are you using on your affected devices? Maybe this is supporting my hypothesis (or not ...)

[KiPe]

All my devices are installed using German locale.

[Thomas_I_samohT]

Well, this (use of German locale version) could then really be an explanation.

I tried to change system locale of my regular Windows 10 Pro installation from German to English. However, even after a clean Intel WiFi driver re-installation, the advanced properties in the device manager are still shown in German (so the driver somehow remembers the old language settings, and I couldn't find where exactly).

Also, the issues with missing RAs still persists after change of system language.

In contrast I could change the system language of my Windows11@VHDX installation from EN to DE and still don't have any issues with the RA (which could mean the driver will remember the OS language setting from first installation...).

The other laptop (with AX201 NIC) is currently not in use. I will try to do clean Windows 10 installation (EN version) and see if the RA issue are resolved or not.

[Thomas_I_samohT]

Seems I was too optimistic. In the meantime (after some sleep cycle), I also had missing RAs in the Windows 11 OS (EN), although my subjective impression is, that it is still more stable compared to Windows 10 (GER)

[KiPe]

Hi Thomas,

I also have very high variance in „reproducibility“. Sometimes it happens almost every sleep-cycle. Sometimes I need to sleep and wake the system a dozen times to make it happen.

That said, I can really only reliably reproduce on battery mode.

Can you confirm this for your case, too?

Cheers
Kai

[Thomas_I_samohT]

Good Morning,

Having a laptop with capacity to run on battery for ~10 hours, I seldomly have the power cable plugged in, and like 95%+ of the time I am using the device in battery mode. In fact, so far I didn't do a lot of useful tests on AC power. But I'll keep this in mind for later.

My most recent results:

A fresh install of Windows 10 Pro English on the other laptop (with Intel AX201) had issues with RA from the beginning. That's another indicator that my theory of the language OS version playing a role may not be true.

In some cases WireShark logfile shows even 2 RAs being received for a single RS, even though I have doubt that the router sent two.

In my primary laptop I replaced the Intel AX210 with the RTL8852AR WiFi NIC it was shipped with by Lenovo --> no more issues with missing RAs, but in most other terms (roaming behavior between router vs repeater and between 2.4 and 5 GHz band, speed ) the Intel AX210 is, by far, the better choice ... (it seems I have to choose which of the issues matters less to me .

Regards

Thomas

[Alberto_R_Intel]

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

I sent you an email requesting private information, please verify your inbox.

Thomas_I_samohT, Thank you for posting in the Intel® Communities Support.

Please submit your inquiry on a new thread, the reason for this is that every scenario is different even if the same product is being used, so for us to better assist you and in order to try to fix the problem, please submit a new thread:

https://communities.intel.com/community/tech

Still, you can always keep monitoring this forum for a possible solution that might work for your platforms as well. 

Let me apologize for any inconvenience.

Regards,

Albert R.

Intel Customer Support Technician

[Alberto_R_Intel]

Hello KiPe, I just wanted to check if you received our last email where we are requesting for you to follow some steps and after that provide the results privately?

Regards,

Albert R.

Intel Customer Support Technician

[KiPe]

Dear Alberto,

no private message received. Kindly re-send the information/request.

Regards,
Kai

[Alberto_R_Intel]

Hi KiPe, Thank you for letting us know those updates.

Sure, I just sent you an email. Please verify your inbox.

Regards,

Albert R.

Intel Customer Support Technician

[DeividA_Intel]

Hello KiPe,  

I reviewed your post, please let me know if the issue was resolved, if not, do not hesitate, just reply back.

Regards,  

Deivid A.  

Intel Customer Support Technician  

[KiPe]

No, the issue does not resolve magically on its own.

I'll do another debugging round according to the information sent by Intel ASAP.

That said, I am wondering what the status on Intel side is in terms of reproducing the issue?

Is someone working on that?

Thanks,
Kai

[Alberto_R_Intel]

Hello KiPe, Thank you very much for sharing those updates.

"I'll do another debugging round according to the information sent by Intel ASAP", Perfect, no problem at all, take your time and once you get the chance, let us know the results.

"Is someone working on that?", Yes, we are currently working on your case, waiting for the results you mentioned and also analyzing the results you sent in your email as well. As soon as I get any updates I will post all the details on this thread or, if necessary, I will send you an email.

Regards,

Albert R.

Intel Customer Support Technician

[KiPe]

Dear Alberto,

Just wanted to follow up and see if there is any update on the issue?

Or at least, has Intel been able to reproduce the issue with the information I provided. Guess this is what I am most interested in.

So, has Intel been able to reproduce it?

I know engineering is probably working in shifts to make it happen, so I hope you excuse my being a bit nosy already, .. after only 1.5years since this issue [1] was first opened.

Cheers,
Kai

[1]

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