Intel Connectivity Performance Suite causes intermittent IPv6 TLS resets on Windows 11 Wi-Fi & Eth

[andretheronsa]

Summary

Intel Connectivity Performance Suite caused intermittent IPv6 HTTPS/TLS connection resets on an ASUS Vivobook S 14 running Windows 11 25H2.

The issue affected Chrome, Edge, and Windows curl.exe. Approximately 40–60% of IPv6 HTTPS connections to an AWS CloudFront distribution were reset. IPv4 was completely stable.

The issue reproduced:

• On Intel Wi-Fi

• On a separate ASIX USB Ethernet adapter

• On the office network

• On a home network

• Through a mobile phone hotspot

Another Windows computer on the same office network and using an equivalent ASIX USB Ethernet adapter had zero failures.

The issue was resolved only after fully disabling and removing the Intel Connectivity Performance Suite device, services, driver package, and files, followed by a reboot. IPv6 then completed repeated tests with zero failures.

System information

Laptop:

ASUS Vivobook S 14 S5406SA_S5406SA
Version: 1.0

Operating system:

Microsoft Windows 11 Home
Version: 25H2
OS build: 26200.8894
Edition: Core

Installed Windows update at the time:

KB5121767
Installed: 20/07/2026

Intel wireless adapter:

Intel(R) Wi-Fi 7 BE201 320MHz
Driver date: 2026-01-06
Driver version: 24.20.0.4
NDIS version: 6.89

Secondary Ethernet adapter used to rule out the Wi-Fi hardware:

ASIX USB to Gigabit Ethernet Family Adapter #2
Link speed: 1 Gbps

Affected Intel software component:

Intel(R) Connectivity Performance Suite
Provider: Intel Corporation
Driver date: 25/07/2025
Driver version: 40.25.725.165
Installed INF: oem9.inf
Original INF: icpscomponent.inf
Matching device ID: SWC\VID_8086&PID_ICPS&SID_0001

CloudFront distribution used for reproduction:

Application domain: maps.skygeo.com

User-visible symptoms

Chrome and Edge intermittently displayed:

net::ERR_CONNECTION_RESET

Complex pages often loaded only partially. Individual JavaScript, CSS, or API requests would randomly fail. Keeping Chrome Developer Tools open with cache disabled appeared to reduce the visible impact because failed requests were retried or reloaded.

The issue also reproduced outside Chromium using Windows curl.exe.

Initial reproduction

The following endpoint returns HTTP 403 when unauthenticated, which is expected. An HTTP 403 therefore represents a successful TCP, TLS, and HTTP exchange. HTTP=000 represents a network/TLS failure.

1..50 | ForEach-Object {
    Write-Host "Request $_"
    curl.exe -sS -o NUL -w "HTTP=%{http_code} time=%{time_total}s`n" `
      "https://maps-permian.skygeo.com/api/v2/user/"
    Start-Sleep -Milliseconds 300
}

Representative output:

Request 1
HTTP=403 time=0.647055s
Request 2
HTTP=403 time=0.336120s
Request 3
curl: (35) Send failure: Connection was reset
HTTP=000 time=0.039066s
Request 4
HTTP=403 time=0.184078s
Request 5
curl: (35) Send failure: Connection was reset
HTTP=000 time=0.059573s
Request 6
curl: (35) Recv failure: Connection was reset
HTTP=000 time=0.038768s

Verbose curl output from a failed connection showed an IPv6 CloudFront address and failure during the TLS handshake:

curl.exe -v -o NUL "https://maps-permian.skygeo.com/api/v2/user/"

Output:

* Host maps-permian.skygeo.com:443 was resolved.
* IPv6: 2600:9000:2449:1000:8:4b2:4880:93a1, ...
* IPv4: 18.239.18.119, 18.239.18.2, 18.239.18.118, 18.239.18.46
*   Trying [2600:9000:2449:1000:8:4b2:4880:93a1]:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* Recv failure: Connection was reset
* schannel: failed to receive handshake, SSL/TLS connection failed
* closing connection #0
curl: (35) Recv failure: Connection was reset

IPv4 control test

Forcing IPv4 eliminated the failures.

$failures = 0

1..200 | ForEach-Object {
    curl.exe -4 -sS -o NUL `
      "https://maps.skygeo.com/api/v2/event_categories/" 2>$null

    if ($LASTEXITCODE -ne 0) {
        $failures++
    }

    Start-Sleep -Milliseconds 100
}

Write-Host "Failures: $failures / 200"

Output:

Failures: 0 / 200

IPv6 failure rate

After rebooting with the normal Intel services running, the following test produced 46 failures out of 100:

$failures = 0

1..100 | ForEach-Object {
    curl.exe -6 -sS `
        --connect-timeout 3 `
        --max-time 5 `
        -o NUL `
        "https://maps.skygeo.com/api/v2/event_categories/" 2>$null

    if ($LASTEXITCODE -ne 0) {
        $failures++
    }

    if ($_ % 20 -eq 0) {
        Write-Host "Progress: $_ / 100 — failures: $failures"
    }
}

Write-Host "FINAL: $failures / 100 failures"

Output:

Progress: 20 / 100 — failures: 10
Progress: 40 / 100 — failures: 16
Progress: 60 / 100 — failures: 25
Progress: 80 / 100 — failures: 35
Progress: 100 / 100 — failures: 46
FINAL: 46 / 100 failures

A later Ethernet sanity test produced:

Progress: 20 / 100 — failures: 13
Progress: 40 / 100 — failures: 21
Progress: 60 / 100 — failures: 32
Progress: 80 / 100 — failures: 40
Progress: 100 / 100 — failures: 50
ETHERNET FINAL: 50 / 100 failures

A Wi-Fi test produced:

WiFi status: Up
WiFi IPv6: True
Progress: 20 / 100 — failures: 11
Progress: 40 / 100 — failures: 24
Progress: 60 / 100 — failures: 34
Progress: 80 / 100 — failures: 46
Progress: 100 / 100 — failures: 57
FINAL: 57 / 100 failures

The same issue reproduced on a mobile hotspot:

Global IPv6 addresses:

2a02:a420:2597:9036:a783:2e38:d534:7040
2a02:a420:2597:9036:4a5:4a79:6690:6cfb

Progress: 20 / 100 — failures: 17
Progress: 40 / 100 — failures: 25
Progress: 60 / 100 — failures: 37
Progress: 80 / 100 — failures: 50
Progress: 100 / 100 — failures: 60
HOTSPOT FINAL: 60 / 100 failures

Control destinations

The issue was not a complete loss of IPv6 connectivity. On Wi-Fi, Google and Cloudflare were stable while the CloudFront-hosted application failed.

$sites = @(
    "https://maps.skygeo.com/api/v2/event_categories/",
    "https://www.google.com/",
    "https://www.cloudflare.com/"
)

foreach ($site in $sites) {
    $failures = 0

    1..50 | ForEach-Object {
        curl.exe -6 -sS `
            --connect-timeout 3 `
            --max-time 5 `
            -o NUL `
            $site 2>$null

        if ($LASTEXITCODE -ne 0) {
            $failures++
        }
    }

    Write-Host "$site FINAL: $failures / 50 failures"
}

Output:

https://maps.skygeo.com/api/v2/event_categories/ FINAL: 27 / 50 failures
https://www.google.com/ FINAL: 0 / 50 failures
https://www.cloudflare.com/ FINAL: 0 / 50 failures

Same-network comparison with another Windows PC

Another Windows computer was tested on the same office network.

Comparison computer:

Microsoft Windows 11 Home
Build: 26100
ASIX USB to Gigabit Ethernet Family Adapter

Results:

Maps IPv4 — failures: 0 / 20
Maps IPv6 — failures: 0 / 20
CloudFront domain IPv6 — failures: 0 / 20
Google IPv6 — failures: 0 / 20
Cloudflare IPv6 — failures: 0 / 20

Both of that computer’s IPv6 source addresses also completed all tests:

maps.skygeo.com from 2001:1c00:b16:8400:9d59:3c56:5c62:501a — failures: 0 / 10
maps.skygeo.com from 2001:1c00:b16:8400:6d27:d316:f7fb:3a6 — failures: 0 / 10

www.google.com from 2001:1c00:b16:8400:9d59:3c56:5c62:501a — failures: 0 / 10
www.google.com from 2001:1c00:b16:8400:6d27:d316:f7fb:3a6 — failures: 0 / 10

This ruled out the office IPv6 router, ISP, CloudFront distribution, and ASIX Ethernet adapter model.

Other tests that did not resolve the issue

The following were tested without resolving the problem:

• Chrome QUIC/experimental protocol settings

• Chrome cache

• Microsoft Edge

• IPv6 MTU reduced from 1500 to 1400

• TLS limited to TLS 1.2

• IPv6 TCP checksum offload

• IPv6 Large Send Offload

• Wi-Fi RSCv6

• Wi-Fi 7 disabled and adapter forced to 802.11ax

• Wi-Fi power-saving settings

• Different Wi-Fi networks

• Ethernet instead of Wi-Fi

• Phone hotspot

• Different CloudFront IPv6 addresses

Raw TCP connection tests succeeded even when HTTPS failed:

maps.skygeo.com via 2600:9000:20a0:b400:0:94c0:9180:93a1 — TCP failures: 0 / 30
www.google.com via 2001:4860:482a:7700:: — TCP failures: 0 / 30

This indicated that DNS resolution, IPv6 routing, and the TCP three-way handshake were working, while failure occurred after TCP connection establishment.

Identification of Intel Connectivity Performance Suite

The installed Intel software component was identified using:

Get-PnpDevice -Class SoftwareComponent |
    Where-Object {
        $_.FriendlyName -match "Intel|Connectivity|Bandwidth|Analytics|Provider|Killer|Rivet"
    } |
    Sort-Object FriendlyName |
    Format-Table Status, FriendlyName, InstanceId -AutoSize

Output:

Status FriendlyName                            InstanceId
------ ------------                            ----------
OK     Intel(R) Connectivity Performance Suite SWD\DRIVERENUM\{6D16CC30-AAA7-42FC-90E5-2D3398E2E222}#ICPS&4&211A0146&2

Driver information:

$instanceId = 'SWD\DRIVERENUM\{6D16CC30-AAA7-42FC-90E5-2D3398E2E222}#ICPS&4&211A0146&2'

Get-PnpDeviceProperty -InstanceId $instanceId |
    Where-Object {
        $_.KeyName -in @(
            "DEVPKEY_Device_DriverInfPath",
            "DEVPKEY_Device_DriverVersion",
            "DEVPKEY_Device_DriverProvider",
            "DEVPKEY_Device_DriverDate"
        )
    } |
    Format-Table KeyName, Data -AutoSize

pnputil /enum-devices /instanceid "$instanceId" /drivers

Output:

DEVPKEY_Device_DriverDate     25/07/2025 02:00:00
DEVPKEY_Device_DriverVersion  40.25.725.165
DEVPKEY_Device_DriverInfPath  oem9.inf
DEVPKEY_Device_DriverProvider Intel Corporation

PnPUtil output:

Device Description:         Intel(R) Connectivity Performance Suite
Class Name:                 SoftwareComponent
Manufacturer Name:          Intel Corporation
Status:                     Disabled
Driver Name:                oem9.inf

Original Name:              icpscomponent.inf
Provider Name:              Intel Corporation
Driver Version:             07/25/2025 40.25.725.165
Matching Device ID:         SWC\VID_8086&PID_ICPS&SID_0001
Driver Status:              Best Ranked / Installed

Associated services:

IDBWM
Intel Analytics Service
Intel Connectivity Network Service
Intel Provider Data Helper Service

Their executables were located under:

C:\Windows\System32\drivers\Intel\ICPS\

Clean isolation test

Disabling only the PnP software component or stopping individual services was not sufficient because the remaining ICPS services and filtering components could continue running or enter an inconsistent state.

The clean test was:

1. Disable the ICPS PnP software component.

2. Disable all four ICPS services.

3. Reboot.

4. Retest IPv6 without changing any other networking features.

The component was disabled with:

Disable-PnpDevice `
  -InstanceId 'SWD\DRIVERENUM\{6D16CC30-AAA7-42FC-90E5-2D3398E2E222}#ICPS&4&211A0146&2' `
  -Confirm:$false

Confirmation:

Get-CimInstance Win32_PnPEntity |
    Where-Object PNPDeviceID -eq 'SWD\DRIVERENUM\{6D16CC30-AAA7-42FC-90E5-2D3398E2E222}#ICPS&4&211A0146&2' |
    Select-Object Name, Status, ConfigManagerErrorCode

Output:

Name                                    Status ConfigManagerErrorCode
----                                    ------ ----------------------
Intel(R) Connectivity Performance Suite Error CM_PROB_DISABLED

The services were disabled before reboot:

$services = @(
    "IDBWM",
    "Intel Analytics Service",
    "Intel Connectivity Network Service",
    "Intel Provider Data Helper Service"
)

foreach ($service in $services) {
    Set-Service -Name $service -StartupType Disabled
    Stop-Service -Name $service -Force -ErrorAction SilentlyContinue
}

Output before reboot:

Name                                Status StartType
----                                ------ ---------
IDBWM                              Stopped Disabled
Intel Analytics Service            Stopped Disabled
Intel Connectivity Network Service Stopped Disabled
Intel Provider Data Helper Service Stopped Disabled

After reboot, on the same mobile hotspot that had previously produced 60 failures out of 100:

ICPS device:
Intel(R) Connectivity Performance Suite
Status: Error
ConfigManagerErrorCode: 22

ICPS services:
IDBWM                              Stopped Disabled
Intel Analytics Service            Stopped Disabled
Intel Connectivity Network Service Stopped Disabled
Intel Provider Data Helper Service Stopped Disabled

IPv6 remained enabled and valid global IPv6 addresses were present:

2a02:a420:2597:9036:a783:2e38:d534:7040
2a02:a420:2597:9036:2999:3f76:160d:2ca1

The test result changed from approximately 60% failure to zero failures:

Progress: 20 / 100 — failures: 0
Progress: 40 / 100 — failures: 0
Progress: 60 / 100 — failures: 0
Progress: 80 / 100 — failures: 0
Progress: 100 / 100 — failures: 0
FINAL: 0 / 100 failures

Wi-Fi 7 and RSCv6 were then restored to their original values:

RSCv6                          Enabled      {1}
802.11n/ac/ax/be Wireless Mode 5. 802.11be  {4}

The test still passed:

Progress: 20 / 100 — failures: 0
Progress: 40 / 100 — failures: 0
Progress: 60 / 100 — failures: 0
Progress: 80 / 100 — failures: 0
Progress: 100 / 100 — failures: 0
FINAL: 0 / 100 failures

Permanent removal

The ICPS package was removed using:

pnputil /delete-driver oem9.inf /uninstall /force

Output:

Microsoft PnP Utility

Ignoring /force when used with /uninstall to delete driver package.
Driver package uninstalled.
Driver package deleted successfully.

The four orphaned service registrations were then deleted:

$services = @(
    "IDBWM",
    "Intel Analytics Service",
    "Intel Connectivity Network Service",
    "Intel Provider Data Helper Service"
)

foreach ($service in $services) {
    sc.exe delete "$service"
}

Output:

IDBWM: [SC] DeleteService SUCCESS
Intel Analytics Service: [SC] DeleteService SUCCESS
Intel Connectivity Network Service: [SC] DeleteService SUCCESS
Intel Provider Data Helper Service: [SC] DeleteService SUCCESS

The leftover directory was removed:

Remove-Item `
    "C:\Windows\System32\drivers\Intel\ICPS" `
    -Recurse `
    -Force

Verification after reboot:

ICPS device: not present
icpscomponent.inf package: not present
ICPS services: not present
ICPS directory exists: False

Final IPv6 verification:

$failures=0; 1..100 | ForEach-Object { curl.exe -6 -sS --connect-timeout 3 --max-time 5 -o NUL "https://maps.skygeo.com/api/v2/event_categories/" 2>$null; if ($LASTEXITCODE -ne 0) { $failures++ } }; Write-Host "FINAL: $failures / 100 failures"

Output:

FINAL: 0 / 100 failures

A final 50-request test also passed:

$failures=0; 1..50 | ForEach-Object { curl.exe -6 -sS --connect-timeout 3 --max-time 5 -o NUL "https://maps.skygeo.com/api/v2/event_categories/" 2>$null; if ($LASTEXITCODE -ne 0) { $failures++ } }; Write-Host "FINAL: $failures / 50 failures"

Output:

FINAL: 0 / 50 failures

Prevention of automatic reinstallation

The ICPS device ID was blocked from automatic installation:

reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions" /v DenyDeviceIDs /t REG_DWORD /d 1 /f; reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceIDs" /v 1 /t REG_SZ /d "SWC\VID_8086&PID_ICPS&SID_0001" /f

Output:

The operation completed successfully.
The operation completed successfully.

Registry state:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions
    DenyDeviceIDs    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceIDs
    1    REG_SZ    SWC\VID_8086&PID_ICPS&SID_0001

Expected behavior

Intel Connectivity Performance Suite should not reset or interfere with valid IPv6 HTTPS connections.

IPv6 HTTPS connections should behave the same with ICPS installed as they do after ICPS is removed.

Actual behavior

With ICPS installed and active:

Approximately 40–60% of IPv6 HTTPS requests to the tested AWS CloudFront distribution failed with connection resets.

With ICPS fully disabled or uninstalled and the computer rebooted:

0 failures out of repeated 50-request and 100-request tests.

IPv4 was stable throughout.

Questions for Intel

1. Is this a known defect in Intel Connectivity Performance Suite version 40.25.725.165?

2. Is there a newer ICPS version that corrects IPv6 TLS/WFP filtering issues?

3. Why is ICPS installed on this ASUS Vivobook when it provides no required functionality for the Intel BE201 Wi-Fi adapter?

4. Can Intel confirm whether ICPS uses Rivet/Killer-derived Windows Filtering Platform callouts?

5. Can the Intel Wi-Fi package be installed or updated without reinstalling ICPS?

6. Is there an official supported method to permanently opt out of ICPS while retaining the Intel BE201 driver and Intel PROSet/Wireless components?

[AlHill]

@andretheronsa   No one is going to read a post this long, especially since MS issued an OOB patch for this issue.

Doc (not an Intel employee or contractor)
[Success breeds complacency. Complacency breeds failure. (Andy Grove)]

[andretheronsa]

This is a bug ticket with all the context needed to reproduce the issue that I was hoping someone at Intel can ask their AI to look into. Not a blog. I certainly didn't plan on spending my day debugging the office internet, AWS cloudfront distributions, chrome browser, Asus power configuration, my Windows services or Intel drivers.

This issue has been affecting my work for months and I've kept my Laptop & Windows up to date with all available updates I could find. How do I configure my updates to install this OOB patch? I was on Windows insiders for a while but that did not pay off.

Can you at least be helpful and link the issue and patch for me?

Now knowing what to search for all I can find is this poor soul who was asked to provide more context for debugging.
https://community.intel.com/t5/Wireless/Intel-Connectivity-Network-Service-is-causing-the-ipv6-flowtable/m-p/1727313

[Jonzyl_Intel · Accepted solution]

Hi andretheronsa, 

Thank you so much for reaching out to Intel! We really appreciate the detailed report you put together. The level of effort and investigation you have done is truly impressive and it definitely helps us get a much clearer picture of what is going on.

We would like to go ahead and address each of your six questions one by one:

1. Is this a known defect in Intel Connectivity Performance Suite version 40.25.725.165? At this point in time, we do not have a confirmed public advisory for this specific behavior, but we want you to know that your report has been taken seriously and will be forwarded to the appropriate team for further review.

2. Is there a newer ICPS version that corrects IPv6 TLS/WFP filtering issues? The version currently installed on your system is the OEM version that came directly from your manufacturer. You are welcome to try the generic version 50.26.220.212, however please keep in mind that ICPS is typically an out-of-the-box program that comes bundled with your computer and is most of the time only fully compatible with the OEM version. That said, feel free to give it a try for testing purposes!

Before installing ICPS 50.26.220.212, please make sure your system has the following:

• Intel Wi-Fi drivers (version 24.50)
• Intel Management Engine drivers installed

You can download the generic ICPS version from Intel® Connectivity Performance Suite (ICPS) for Intel® Wireless Products, and Intel® Connectivity Manager (ICM)

3. Why is ICPS installed on this ASUS Vivobook when it provides no required functionality for the Intel BE201 Wi-Fi adapter? Intel Connectivity Performance Suite (ICPS) is a software package designed to optimize and enhance your network connectivity experience. It provides features such as improved network performance, intelligent switching between Wi-Fi networks, and better overall connection stability. While it may not be strictly required for the BE201 adapter to function, it is often bundled with OEM systems as an added value software to enhance the overall wireless experience.

4. Can Intel confirm whether ICPS uses Rivet/Killer-derived Windows Filtering Platform callouts? We will go ahead and check this with our team and get back to you with more information as soon as we have an update on this.

5. Can the Intel Wi-Fi package be installed or updated without reinstalling ICPS?

6. Is there an official supported method to permanently opt out of ICPS while retaining the Intel BE201 driver and Intel PROSet/Wireless components? Good news on both of these! After checking the ASUS website for your specific model (ASUS Vivobook S 14 OLED S5406), we can confirm that the Wireless driver and ICPS are available as separate standalone driver packages. This means that if you prefer not to use ICPS, you can simply uninstall it without affecting your Wi-Fi driver or PROSet/Wireless components.

To properly uninstall ICPS, please follow the steps below:

1. Open a Command Prompt as Administrator
2. Type the following command and press Enter: pnputil /enum-drivers >c:\icps.log
3. Navigate to C:\ and open the icps.log file. Press Ctrl+F to open the search box and type "icps" to find all "oem#.inf" entries with icpsExtension and icpsComponent
4. Switch back to the Command Prompt and type the following command to completely uninstall all matching drivers: pnputil /delete-driver oem#.inf /uninstall
5. Go to Add or Remove Programs and uninstall the Intel® Connectivity Performance Suite software
6. Reboot your system
7. (Optional) You may also try reinstalling ICPS to see if the issue persists after a fresh installation

You can check this link for detailed information: How to Uninstall or Roll Back to an Older Version of Intel®...

Please do not hesitate to reach out if you have any further questions. We are looking forward to hearing from you and hope this helps get things sorted out for you!

Best Regards,

Jonzyl B.

Intel Customer Support Technician

[Jonzyl_Intel]

Hi andretheronsa, 

I wanted to check if you had the chance to review the questions I posted. Please let me know at your earliest convenience so that we can determine the best course of action to resolve this matter.

Best Regards,

Jonzyl B.

Intel Customer Support Technician

[andretheronsa]

1. Thanks!
2. I did not try the later OEM driver (it also wasn't suggested by Asus / windows updates) - I already deactivated the enitre performance suite and blocked it from reinstalling (see permanent removal at the end of my message). My laptop works now again so I don't want to risk testing the new driver if its not definitely resolved.
3. Clear - this is why I normally removed such bloatware
4. Thanks!
5. 
6. Clear - it's removed. Thanks.