Brian Biales

because blogging is just the easiest way to remember things

  Home  |   Contact  |   Syndication    |   Login
  23 Posts | 0 Stories | 26 Comments | 9 Trackbacks

News



Archives

Post Categories

.NET Development

Open Source and FOSS topics

Patterns And Practices

Web Development

Windows Administration

I’ve been fighting this issue for a long time, and just the other day discovered the solution to my problem.  Here is the issue…

My laptop is connected to my home / work / internet via its wireless (WiFi) adapter.  But I test trunk mounted modems that plug into the Ethernet port.  These often use “private” APN’s, and have no access to the internet. But when I plug them in, they use DHCP and define a default gateway to go through the WAN modem.  Great for most people, but because Ethernet is faster than WiFi, the OS automatically assigns the Ethernet gateway higher priority, because it is “faster”.  So a lot of connections go dead once I plug the modem in.

I tried using ROUTE CHANGE, and even ROUTE DELETE / ROUTE ADD to give my WiFi adapter’s gateway priority.  The commands let me specify a Metric value, but it never changed.  Well, the article below explains the default process of automatically determining the metric for gateways on a particular adapter.  Fastest one always wins.  And no overrides as long as the feature is active…

The article below explains how to “turn off” this automatic metric feature for a particular adapter, and simply hard code it.  So I set the metric for the WiFi adapter to a very low number (higher priority), then plugged the modem in.  Sure enough it added a gateway, but for the first time, its gateway had a “higher” metric than the WiFi.  So the WiFi adapter remained my default gateway even when the Ethernet cable was plugged in.  Why can’t the ROUTE command have an option to just let me even temporarily tell it which gateway metrics to use??  Ah, well, at least now I have the tool to change it when I need to…

An explanation of the Automatic Metric feature for Internet Protocol routes

posted on Monday, January 7, 2013 2:46 PM