Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, November 1, 2017 9:12 AM
Hi,
It's been a while I'm facing the following issue.
When I connect my laptop to my wired LAN, WiFi gets priority over Ethernet.
The interface metric for WiFi is 1, that for the Ethernet connection is 9.
If I change the metric for WiFi to 99, then Ethernet gets priority, as expected.
But this change doesn't stick: something keeps resetting the metric to 1.
Any clue as to how I can make Ethernet always have a smaller metric than WiFi, in a permanent and persistent way, that will survive reboots, cable disconnects / reconnects, connecting to different WiFi networks...?
(just like it used to be in the past)
All replies (18)
Thursday, November 2, 2017 7:47 AM
Hi,
Try these steps:
1. Go to Network and Sharing Center, click on Change adapter settings then press the 'Alt key' to show menus and select Advanced Settings...
2. Under Adapters and Bindings section, select Ethernet, and use the arrows to the right to move Ethernet above WiFi.
3. Click OK.
After that, you can run route print to confirm the configuration.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Sunday, November 5, 2017 4:47 PM
Well...
Here's what I get under "Provider Order":
Monday, November 6, 2017 10:17 AM
Hi,
Based on my deep research, with Windows 10, you may not see an ‘Adapters and Bindings’ dialog box. Even if you get the ‘Adapters and Bindings’ dialog box, when you make adjustments to the binding order and save, and you re-open the Adapters and Bindings dialog box, you will notice that your changes do not persist.
What if you want to change the priority of a specific network card?
1. .Launch Windows PowerShell as Admin.
2.Type the following command in the window and press Enter
netstat –rn
3. Use Set-NetIPInterface -InterfaceMetric to define the weight for the interface.
For Example: Set-NetIPInterface –InterfaceIndex “xx”–InterfaceMetric “xxx”
For more information, please read this article:
Adjusting the Network Protocol Bindings in Windows 10
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Tuesday, November 7, 2017 7:43 PM
Hi,
I hate to say, but this doesn't solve my problem.
This gives me a programmatic way to get/set the interface metric, which is interesting, but doesn't answer the question of why the metrics keep being changed back to unwanted values.
At this point I have:
PS> Get-NetIPInterface | ? { $_.InterfaceAlias -match '^(ether|wi)' } | select InterfaceAlias,AddressFamily,InterfaceMetric
InterfaceAlias AddressFamily InterfaceMetric
Ethernet IPv6 9
Wi-Fi IPv6 1
Ethernet IPv4 9
Wi-Fi IPv4 1
Wi-Fi has a lower metric than Ethernet, so it has priority. This is not what I want, but if I set the metric to 99, at some point it'll be set back to 1. How do I prevent this???
Wednesday, November 8, 2017 5:29 AM
I see no reason why changing how the address is set (DHCP vs. manual) would affect the metric, and thus the priority...
Wednesday, November 8, 2017 10:01 AM
Hi,
It's hard to figure out the root cause that prevent it from changing.
Here I suggest you reinstall all of your WiFi and Ethernet network card driver. And then change the metric again for test.
If the issue persist, check the following registry value:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\your wifi and ethenet interface\InterfaceMetric
Meanwhile, perform a Clean Boot to see if it's caused by third-party software and service:
How to perform a clean boot in Windows
https://support.microsoft.com/en-us/help/929135/how-to-perform-a-clean-boot-in-windows
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, November 8, 2017 8:50 PM
I will give the approach a try, just for testing purposes, but there are two points where my situation differs from yours:
1. I don't want to set a fixed address for the Ethernet NIC, as this would require changing it every time I connect to a different network
2. Your Ethernet and Wi-Fi NICs are connected to two different subnets. In my case, I have only one subnet which is my home Internet box's. In particular, this means the gateway will always be identical for both interfaces.
Here's what I currently have with the Ethernet cable connected, and the system tray showing the "Wi-Fi" icon, not the "wired network" one:
PS>
Get-NetIPInterface | ? { $_.InterfaceAlias -match '^(ether|wi)' } | select Interfac
eAlias,InterfaceIndex,AddressFamily,InterfaceMetric
InterfaceAlias InterfaceIndex AddressFamily InterfaceMetric
Ethernet 8 IPv6 9
Wi-Fi 14 IPv6 1
Ethernet 8 IPv4 9
Wi-Fi 14 IPv4 1
PS> route print
=========================================================================== Interface List 14...9c b6 d0 18 67 7b ......Killer Wireless-n/a/ac 1535 Wireless Network Adapter 8...78 f2 9e fd a9 c9 ......Killer E2400 Gigabit Ethernet Controller 13...7e 15 85 56 0c 60 ......Hyper-V Virtual Ethernet Adapter 2...9e b6 d0 18 67 7b ......Microsoft Wi-Fi Direct Virtual Adapter 3...9c b6 d0 18 67 7c ......Bluetooth Device (Personal Area Network) 1...........................Software Loopback Interface 1
IPv4 Route Table
Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.19 9 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.17 100 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 172.22.186.128 255.255.255.240 On-link 172.22.186.129 271 172.22.186.129 255.255.255.255 On-link 172.22.186.129 271 172.22.186.143 255.255.255.255 On-link 172.22.186.129 271 192.168.1.0 255.255.255.0 On-link 192.168.1.19 265 192.168.1.0 255.255.255.0 On-link 192.168.1.17 257 192.168.1.17 255.255.255.255 On-link 192.168.1.17 257 192.168.1.19 255.255.255.255 On-link 192.168.1.19 265 192.168.1.255 255.255.255.255 On-link 192.168.1.19 265 192.168.1.255 255.255.255.255 On-link 192.168.1.17 257 224.0.0.0 240.0.0.0 On-link 127.0.0.1 331 224.0.0.0 240.0.0.0 On-link 192.168.1.19 265 224.0.0.0 240.0.0.0 On-link 172.22.186.129 271 224.0.0.0 240.0.0.0 On-link 192.168.1.17 257 255.255.255.255 255.255.255.255 On-link 127.0.0.1 331 255.255.255.255 255.255.255.255 On-link 192.168.1.19 265 255.255.255.255 255.255.255.255 On-link 172.22.186.129 271 255.255.255.255 255.255.255.255 On-link 192.168.1.17 257
Persistent Routes:
None
Wednesday, November 8, 2017 9:14 PM
I've noticed strange things in the registry at HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces:
1. the Ethernet NIC (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\6db11007-1a8c-4def-aa8f-03c3c76908fd}) doesn't have an InterfaceMetric entry--so I presume the value 9 that I see is an automatically-determined one.
2. The Wi-Fi NIC (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\a921a085-48c0-495d-9efe-04a3221a03ac}) has an InterfaceMetric entry with value 99 (the one I previously entered manually) but the UI (and Get-NetIPInterface) show 1 as the metric. How comes the value in the registry is ignored/overruled?
3. there are 10 subkeys under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\a921a085-48c0-495d-9efe-04a3221a03ac}, with various contents.
Before uninstalling/reinstalling, I will need to check on Acer's website whether their drivers are available for manual (re)installation.
Wednesday, November 8, 2017 9:21 PM
Silly question: did you try setting the interface metric of the Ethernet to 1?
Tope (MCITP, MCTS, MCSE)
Wednesday, November 8, 2017 9:27 PM
Actually not, I'd left it to the "default" of 9 and set the Wi-Fi metric to 99... but only for IPv4.
I've just tried setting the Ethernet metric to 1 both for IPv4 and IPv6, and the Wi-Fi metric to 99 both for IPv4 and IPv6, and it seems to work.
Additionally, the registry for the Ethernet NIC (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\6db11007-1a8c-4def-aa8f-03c3c76908fd}) now has an InterfaceMetric value (of 1).
I'll keep monitoring what happens to these 4 metric settings (across reboots, cable disconnects/reconnects...)
Wednesday, November 8, 2017 9:31 PM
IMVHO I can't set the Ethernet IP address to a fixed (static) value that's not part of the current subnet! So every time I would connect the computer to a different infrastructure, I would need to find an available IP address on that subnet, learn the IP address of that subnet's gateway, and set them. Really inconvenient compared to DHCP.
Thursday, November 9, 2017 6:23 AM
The plot thickens (but fortunately the behavior I get is what I want: traffic uses Ethernet, not Wi-Fi, as soon as the cable is connected).
This started after I changed the 4 metrics as described earlier, and rebooted.
1. When the cable is connected, Wi-Fi is just disabled:
((don't ask me why the "wired" network is named after one of my Wi-Fi SSID's -- is there any way to change that?)
2. If I disconnect the cable and wait a few seconds, Wi-Fi gets turned back on, and takes over (I'd prefer that the laptop connects to the PNJ300-5 Wi-Fi network, but that's another issue):
3. If I connect the Ethernet cable again, there is a transient period where both Ethernet and Wi-Fi are enabled, and after a few seconds Wi-Fi gets disabled again (back to #1)
Next to that, the registry entries still specify an InterfaceMetric of 1 for Ethernet and 99 for Wi-Fi, but this just seems to be ignored:
Does anyone understand what's going on (and maybe what "fixed" my initial problem)?
Thursday, November 9, 2017 1:38 PM
Check in the properties of the Wi-Fi adapter if the following is set? If the value is enabled, change to disabled as in the screenshot below
Tope (MCITP, MCTS, MCSE)
Thursday, November 9, 2017 8:16 PM
Same here:
Friday, November 10, 2017 6:37 AM
I've upgraded the Killer driver, JIC.
Behavior is unchanged (but still OK): when the cable is connected, Wi-Fi is disabled, gets re-enabled when cable is disconnected, and disabled again some seconds after the cable is reconnected.
Friday, November 10, 2017 10:04 AM
This is normal behavior.
When the Ethernet and WiFi available same time, it will connect one that metric value lower. This is normal.
So was your issue resolved?
If yes, please mark the helpful reply as answer in order that other community members could find the helpful reply quickly.
If no, please reply and tell us the current situation in order to provide further help.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Saturday, November 11, 2017 7:31 AM
Hi Monominta,
That's exactly what I've done (see elsewhere on the thread), but that hasn't change the situation... from an "unexpectedly working one" to the same "unexpectedly working one."
What I mean by "unexpectedly working":
1. the interface metrics in the registry are still not those displayed in the UI / returned by Get-NetIPInterface
2. the metrics shown in the UI / returned by Get-NetIPInterface are "in the wrong order" (Wi-Fi > Ethernet)
3. For some reason, the Wi-Fi interface gets disabled when the Ethernet cable is connected. This gives me the desired behavior, but not because the metrics are correct.
Bottom line: I'm happy ;-) but I don't know why I previously wasn't, and what has been done that resulted in the current behavior...
Saturday, November 11, 2017 7:33 AM
My issue is resolved... sort of.
But I can't mark anything on this thread as "the answer."
Here's the current situation:
1. the interface metrics in the registry are still not those displayed in the UI / returned by Get-NetIPInterface
2. the metrics shown in the UI / returned by Get-NetIPInterface are "in the wrong order" (Wi-Fi > Ethernet)
3. For some reason, the Wi-Fi interface gets disabled when the Ethernet cable is connected. This gives me the desired behavior, but not because the metrics are correct.
Bottom line: I'm happy ;-) but I don't know why I previously wasn't, and what has been done that resulted in the current behavior...