Wi-Fi turns off when 'connected' with Ethernet

[Robert141]

The issue

Recently my Wi-Fi has started turning off when I plug in an Ethernet cable, and currently I'm not able to figure out how to address this issue. It used to work just fine, but I cannot exactly pinpoint when this started happening. However, I suspect this started after updating a bunch of drivers and my BIOS using the HP Support Assistant.

I'm using Windows 10 Home version 1809 (build 17763) on a HP ZBook 15 G2 with an Intel Dual Band Wireless-N 7260.

Why it is an issue and how does it manifest

Sometimes I want to use my laptop as mobile hotspot when connected to Ethernet. I enable the Wi-Fi adapter with the button on the ZBook, it turns on for less than 5 seconds before turning off again.

Other times I want to use a VPN while being connected to wireless, using OpenVPN. Once the VPN connection is made the notebook detects this as being a wired network and turns off the Wi-Fi. Then OpenVPN figures out the connection was broken, releases the connection and the Wi-Fi turns back on again, until OpenVPN has regained connection, and so on. This somehow doesn't happen when I'm using the Cisco AnyConnect client.

What I already tried to solve it

• Bios settings > Advanced > Device Configuration
  LAN-WLAN switching was already disabled
• Network and Sharing center > Change adapter settings > Wi-Fi > Properties > Configure > Power Management
  Disabled 'Allow the computer to turn off this device to save power'
  Did not work
• Network and Sharing center > Change adapter settings > Advanced > Advaced settings > Provider Order
  Changed 'Microsoft Windows Network' from the 3rd to the 1st position.
  Did not work
• Powershell > Get-NetIPInterface
  ifIndex 20 (Wi-Fi) changed InterfaceMetric from 50 to 4 by
  Set-NetIPInterface -InterfaceIndex 20 -InterfaceMetric 4
  Did not work
• reinstalling Intel WLAN Drivers
  Did not work

Any suggestions what I might overlook?

[Stalwart · Accepted solution]

This seems to be a known problem with the HP Hotkey Support driver. HP claims to have fixed it with regard to a proprietary Cisco VPN, but it does not work with regard to Private Internet Access VPN or another VPN that I have tried, both of which use OpenVPN.

Your description is essentially correct. The HP Hotkey Support driver causes Wi-Fi to be closed when it detects a hardwired LAN port in use. It seems to think that OpenVPN ports (known as TAP adapters) are hardwired LAN ports. So, what happens is:

1. You establish a Wi-Fi link.

2. You start your VPN software.

3. The VPN software starts the TAP adapter port.

4. The HP Hotkey Support driver notes that there is a "hardwired" port in use and disables the Wi-Fi link.

5. The VPN software - and therefore the TAP adapter port fails.

6. The Wi-Fi link is re-enabled by the HP Hotkey Support driver.

7. Repeat 3 through 6 until you get mad and turn off the machine!

There is a fix, although I am not sure how wise it is:

To enable OpenVPN offerings to work over Wi-Fi, it is necessary to disable one or two services in Windows 10 that have been set up by the Hotkey Support Driver.

• Press Windows+R, type "services.msc" in the box, and press OK.
• Search for a service called "HP LAN/WLAN/WWAN Switching UWP Service"
• If it is present, right click on the service, and select Properties
• Change the startup type to Manual
• Click Apply 
• Search for a service called "LAN/WLAN/WWAN Switching Service"
• If it is present, right click on the service, and select Properties
• Change the startup type to Manual
• Click Apply 
• Reboot the computer and try the VPN on Wi-Fi.

I got some of this information from Private Internet Access, and refined it on my own HP EliteBook 840 G2, so kudos are hereby sent to PIA.

Good luck!

[Robert141]

Bingo, that does the trick! Indeed, the "HP LAN/WLAN/WWAN Switching UWP Service" turns out to be culprit. Stopping it also enables the mobile hotspot function to work properly again.

Thank you (and PIA) for the solution. Very slim chance that I would've found this without help. No clue what I mess up by having this service disabled, but so far I don't see any side effects.