Wireless
Participate in insightful discussions regarding issues related to Intel® Wireless Adapters and technologies
7365 Discussions

IPv6 (SLAAC) broken on AX200 w/ recent 22.x drivers on Windows 10

KiPe
New Contributor I
3,295 Views

Hi There,

I have just reproduced an issue on my HP Notebook (1040 G6).

IPv6 Stateless Autoconfiguration (SLAAC) seems to be borked in the more recent versions of the 22.x Intel wireless drivers for AX200.

What happens is, that the interface gets assigned only the link-local fe80:* IPv6 address, not the public prefix announced on the network.

It seems that Windows also has a history of breaking IPv6, which is why I have been sceptical in the beginning. Also, it seems hard to believe that a fundamental, yet higher protocol layer mechanism (relying on ICMPv6 and IPv6 Mulicast) could be impacted by a low level driver.
Even harder to understand that Intel does not check for this functionality as part of their verification process. Yet, I have reproduced the issue here by switching drivers, leaving the rest of the system untouched.

Any more recent 22.x driver I installed exposes the problem.

Problem can easliy be identified as I do not receive the public prefix IPv6 address of a network, only link-local (fe80:..).

Downgrading the driver to 22.0.0.6 solved the problem. 22.0.0.6 seems to be the last one working for me.

Using the newer (potentially buggy) drivers, e.g. 22.20.0., under rare circumstances I was able to receive an IPv6 once. This I did by issuing issuing a number of "ipconfig /renew6" in combination with "netsh int ip reset" on an elevated rights shell. Yet, as soon as I switched the network, things broke again.

This is reproducible on two completely distinct IPv6 enabled setups (i.e. Wireless Networks / APs / SSIDs).

I can also confirm that IPv6 is fully functional on these two networks with various Apple / iOS Devices, also worknig flawlessly with another Windows 10 Laptop, using a non-AX200 card.

I can furthermore confirm that the Laptop (used to reproduce the issue) is (besides the now downgraded WiFi driver) completely up to date in terms of Firmware, Driver and Windows, as well as all applications.

Anyone else seeing this? If so, any chance to get this quite basic thing fixed?

Regards,
Kai

 

0 Kudos
12 Replies
Alberto_Sykes
Employee
3,281 Views

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


In reference to this scenario, just to let you know, we always recommend to install the Wireless drivers provided by the manufacturer of the computer, since that driver was heavily customized by them to work with your specific platform.

Keep in mind as well that the Intel® Wireless drivers are generic, meaning they might or might not with your system.


"22.0.0.6 seems to be the last one working for me", I looked for the drivers provided by HP and actually the latest Wireless driver that they have available for installation that was tested and validated by them is precisely version 22.0.0.6 Rev.P as you can confirm in the link below, so we recommend to keep using that driver for the proper functionality of the Wireless connection:

https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-elitebook-x360-1040-g6-notebook-pc/26938567/swItemId/ob-260050-1


For Intel® is very important all the feedback provided by our customers, so we thank you very much for letting us know those details about the Intel® Wireless driver version 22.20.0 and we will send your comments to the proper department for them to be aware of suggestions and recommendations in future driver releases.


Any questions, please let me know.


Regards,

Albert R.


Intel Customer Support Technician


0 Kudos
KiPe
New Contributor I
3,279 Views

Dear Albert,

thanks for your reply.

Unfortunately, it now started to happen on 22.0.x also.

I installed the drivers provided by HP.

Not sure why it worked in the beginning, but writing this message, I am back on IPv4 only

Kind Regards,
Kai

0 Kudos
Alberto_Sykes
Employee
3,263 Views

KiPe, You are very welcome, thank you very much for providing that information.


We are sorry to hear the problem is also happening with the drivers provided by HP. 


In order for us to provide the most accurate assistance on this matter, we just wanted to confirm a few details:

You mentioned, "I can also confirm that IPv6 is fully functional on these two networks with various Apple / iOS Devices, also working flawlessly with another Windows 10 Laptop, using a non-AX200 card."

What is the model of the Windows* 10 laptop and the Apple / iOS Devices? 

What is the model of the Wireless cards in those devices?

What is the model of the Router?

Is this a new computer?

Did you make any recent hardware/software changes besides installing the latest Intel® Wireless driver?

The wireless card, for the computer in question, did you purchased it separately, or did it came installed on the computer?

Which Windows* version are you using?

Does the problem happen at home or work environment?

Please provide the SSU report so we can verify further details about the components in your platform, please check all the options in the report including the one that says "3rd party software logs":

https://downloadcenter.intel.com/download/25293/Intel-System-Support-Utility-for-Windows-?product=91600


Regards,

Albert R.


Intel Customer Support Technician


0 Kudos
Alberto_Sykes
Employee
3,243 Views

KiPe, I just wanted to check if you saw the information posted previously and if you need further assistance on this matter?


Regards,

Albert R.


Intel Customer Support Technician


0 Kudos
Alberto_Sykes
Employee
3,235 Views

Hello KiPe, Since I have not heard back from you, we are closing the case, but if you have any additional questions, please post them on a new thread so we can further assist you with this matter.


Regards,

Albert R.


Intel Customer Support Technician


0 Kudos
Znevna
Beginner
3,099 Views

Hi!

I've noticed similar behaviour with my AX200 card, I've tried every driver version I could find, from 21.40 to 22.60 with no luck.

I've also tested with fresh installs of Windows 10 versions from 1809 to 21h1 trying to replicate the problem with no luck.

In the end I've found out that it's caused by disabling the IPv6 Privacy Extensions on Windows, using the following:

netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent

It works fine after a reboot, or just disable/enable the adapter from device manager (or Network Connections) after a reconnect to the AP, since for the first connection it works fine.

It doesn't process the RA after a reconnect, donno why. Also captured with Wireshark and I didn't see the RA sent by the router, only for the first connection to the AP, as mentioned, after a reboot or disable/enable of the adapter.

Turning back "privacy state=enabled" fixes the issue, but not desired behaviour.

Sent this to support, we'll see

0 Kudos
KiPe
New Contributor I
3,051 Views

Hi Znevna,


thanks for the hint.

I can confirm that disabling the privacy extensions with the two commandlines you provided [1] indeed temporarily fixes the issue.
It is fixed ONLY after a reboot.
I seems to be fixed as long as I do not switch SSIDs.

After rebooting, I had received the SLAAC prefix, presumably received the related RA which I admittedly did not confirm with Wireshark.
Then switching SSID the Prefix is gone again, even if I switch back to the initial SSID.
So after chaning SSID I am back in a situation where I have only link-local (fe80:..) IPv6.

 

Then I tried enabling the privacy extensions using [2], as I understand this permanently resolved issues for you.
However, for me this is the same situation as above. It temporarily resolves the problem, but only intill I switch SSIDs.

 

This leads me to the conclusion that any CHANGE in the privacy extensions (enable and disable) actually temporarily fixes the issue.

This howewer cannot serve as a workaround, as I cannot change the settings and reboot whenever I change SSID.

 

Kindly asking you to elaborate if for you enabling the privacy extensions really permanently fixes things and if [2] was way to go to enable.


[1]
netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent

[2]
netsh interface ipv6 set privacy state=enabled store=active
netsh interface ipv6 set privacy state=enabled store=persistent

0 Kudos
Znevna
Beginner
2,994 Views

@KiPe Some more info regarding this issue:

I had an open case about this for a week and something with "Intel Support" that led nowhere, I've described the problem and steps to reproduce it but it wasn't enough for them because this laptop didn't came with the card preinstalled as it was installed afterwards, replacing some realtek card that was only 1x1. And so for them to take a look into this I had to replicate the issue on a laptop that is preinstalled with this card, so they can "be sure it's not an integration issue by the OEM" and after they do that, they might take a look into it.

I did replicate the issue on another laptop, told them about it, specified the model and maker,  they kept asking for more logs now from that laptop, but after a week of talks I got tired of this and the logs don't reveal anything else that wasn't already said, as in the logs don't show if the driver/windows handles properly that specific wireless frame containing the Router Advertisement or not and I didn't have access to that specific laptop all the time just to grab some useless logs.

I even told them it works fine under Linux, so it's not a hardware defect. They kept insisting on "OEM Integration" "no support otherwise" (short version). Ok.. I called it quits. I'm guessing those guys get paid to not forward tickets to the technical department. (they could've just tried to replicate the issue on some "properly integrated OEM laptop whatever" but no..).

Anyway, back to IPv6 privacy extensions and windows, by default they are enabled:

 

netsh int ipv6 show privacy

 

 

Spoiler
Querying active state...

Temporary Address Parameters
---------------------------------------------
Use Temporary Addresses             : enabled
Duplicate Address Detection Attempts: 3
Maximum Valid Lifetime              : 7d
Maximum Preferred Lifetime          : 1d
Regenerate Time                     : 5s
Maximum Random Time                 : 10m
Random Time                         : 8m3s​

 

 

netsh set privacy

 

 

Spoiler
Usage: set privacy [[state=]enabled|disabled] [[maxdadattempts=]<integer>]
             [[maxvalidlifetime=]<integer>]
             [[maxpreferredlifetime=]<integer>]
             [[regeneratetime=]<integer>]
             [[maxrandomtime=]<integer>]
             [[store=]active|persistent]

Parameters:

       Tag                    Value
       state                - Whether temporary addresses are enabled.
       maxdadattempts       - Duplicate address detection attempts.
                              The default value is 5.
       maxvalidlifetime     - Maximum lifetime over which an temporary
                              address is valid.  The default value is 7d
                              (seven days).
       maxpreferredlifetime - Maximum lifetime over which an temporary
                              is preferred.  The default value is 1d
                              (one day).
       regeneratetime       - Time prior to deprecating an temporary
                              address when a new address is generated.
                              The default value is 5s (five seconds).
       maxrandomtime        - Upper bound to use when computing a random
                              delay at startup time.  The default value is
                              10m (ten minutes).
       store                - One of the following values:
                              active: Change only lasts until next boot.
                              persistent: Change is persistent (default).

Remarks: Modifies parameters related to temporary address generation.
         If randomtime is specified, the maxrandomtime value is not
         used.  Time values can be expressed in days, hours, minutes,
         and seconds; e.g. 1d2h3m4s.

Tells us that we can disable privacy extensions by doing this:

 

 

netsh int ipv6 set privacy disabled

 

(reboot required for changes to take effect)

Now I've only encountered this issue with privacy disabled, with privacy enabled (Windows default) I didn't encounter this issue.

You could try resetting the IPv6 settings to defaults with:

 

netsh int ipv6 reset

 


Intel Driver & Support Assistant still offers Wi-Fi driver version 22.50.1.1 as of this date, for this WLAN card.

This driver is still buggy.

On Windows 10 21H1 19043.1110 driver version 22.60.0.6 gets offered via Windows Update / Optional updates / Driver updates,

It can be downloaded from Microsoft Catalog too: https://www.catalog.update.microsoft.com/Search.aspx?q=Intel+-+net+-+22.60.0.6

This driver still presents the issue, but it seemed a little more stable, as in switching to another SSID but on the same band (2.4GHz -> 2.4GHz or 5GHz -> 5GHz) did not cause this issue, most of the time. Switching from a 2.4GHz SSID to a 5GHz SSID produced this issue. Reconnecting to the same SSID also produced this issue. Pretty inconsistent results.

The fix.. reboot or disable/enable of the Wireless Adapter, or restart it via pnputil, you get the "Device instance path" from the cards properties / details and issue this (in my case):

 

pnputil /restart-device "PCI\VEN_8086&DEV_2723&SUBSYS_00848086&REV_1A\4&2C356BC3&0&000F"

 

Now, I've tried last night Windows 11, the Insider Dev channel, current build 21H2 22000.65

The same 22.60.0.6 driver got offered via Windows Update / Optional / Driver Updates, but I could not replicate the issue, all seemed ok with privacy extensions disabled.

Today, on the same Windows 11 install I got offered via Windows Update / Optional / Driver Updates, driver version 22.70.0.5 dated June 21, 2021. This driver also seemed stable under Win 11 21H2. So... I grabbed this driver and installed it in Win 10 21H1, all seems ok!

So it seems this somehow got fixed, probably along with another issue that also affected this for so many time.

Notable random issues:

In event viewer this warning still shows up: Event ID: 6062

 

6062 - Lso was triggered

 

I cannot pin a cause to it or if it causes anything. It seems to appear as soon as you switch bands (2.4 -> 5 or the other way around) or it shows up after some time staying even on the same band.

Sometimes (even though I get replies from pings v4 and v6) wlan auto config thinks that it has no connectivity and restarts the wlan card. Event ID 4003:

 

WLAN AutoConfig detected limited connectivity, attempting automatic recovery.

 

  I think this about sums up my experience with Intel AX200 and Windows 10/11.

0 Kudos
KiPe
New Contributor I
2,868 Views

What a pity... seems intel has given up on this issue. Intel, did you?

 

 

 

0 Kudos
KiPe
New Contributor I
2,841 Views

Short Update:

 

Testing with 22.70.0.6 drivers, the situation improved.


Now every time I reboot, the first "join" to a network (arbitrary SSID), SLAAC reliably works.

Still, after the first SSID change, SLAAC breaks again. But with 22.70, reboot can cure it!

 

Digging a bit deeper, it seems that now both router solicitation and advertisements are going through reliably.

In when I leave the WiFi connection sit idle (after chaning SSID)  for a few minutes, I again get my IPv6 prefix.

I.e.: When joining a new SSID, I have no IPv6 connectivity, then I wait a few minutes and will eventuellay receive the timed (unsolicited) RA sent out peridically by my IPv6 router... and in turn the IPv6 gets configured.

 

So the culprit that is remaining seems to be: there is no solicitation request generated (or sent out) after the SSID is changed.

Intel, can you please fix this last remaining issue so that after SSID change, both IPv4 and IPv6 work instantaneously?

 

Version 22.70 of the driver seems to be an improvement, not a complete solution though.

 

Cheers,

Kai

0 Kudos
KiPe
New Contributor I
2,196 Views
0 Kudos
KiPe
New Contributor I
2,194 Views
0 Kudos
Reply