When having 2 network connections open at the same time, such as wired Ethernet and also wireless, is it possible to somehow give priority to one or the other?
Right now, it seems to be a race condition in the routing table: whichever interface comes up last, ends up winning. Since Wi-Fi always is slower (due to password negotiation and such), it will win. This is a disadvantage when in a corporate environment that has good connectivity for both Wi-Fi and wired Ethernet. I’d like to have it prefer to use wired Ethernet, and only fall back to Wi-Fi when the wired Ethernet is unavailable (unplugged cable, or whatever).
Is it possible to do this? The routing metric would most likely be the answer (I could give Wi-Fi a higher metric, so that the kernel would prefer the wired Ethernet for making new outbound connections). I couldn’t find a field in the network configuration that would let me select a routing metric to be applied to each interface, unfortunately. Is there a way to do this cleanly within OpenSUSE’s network configuration design? I could probably roll my own with a shellscript that changes the metric, but this would be a kludge. Surely there’s got to be a better way to do it.
openSUSE 11.4 is out of date now (not long, but it is).
are you using “traditionla with ifup” or network manager? Nerworlmanager does what you want automaticaly if I am correct. And NetworkManager is of courde to be used when you walk around with the system from network connection to network connection as you seem to do.
Back when I was using 11.4, I setup my wifi connection using the Gnome NetworkManager applet (named “nm-applet”). There, I set the connection to be shared by all users. In KDE, the equivalent is to make the connection a system connection, but with 11.4, that option was always grayed out.
Once the WiFi is configured as a system connection, it connects on boot without having to first login.
It is actually possible to run “nm-applet” under KDE.
Since 11.4 has passed its support period, you might not be able to install nm-applet and any needed libraries. Your best bet is to switch to 12.1 or 12.2, and then configure your connection as a system connection in KDE.
I recommend 12.2. As I recall, there was still some brokenness for NetworkManager in 12.1, which was fixed in a patch to 12.2. I’m not sure whether that fix was back-ported to 12.1.
so if both of them are setup as ‘system connection’ in NM which one will have priority? Just trying to understand how the system will choose (will it choose the fastest?), when will it switch from one to the other? if one drops ? or slowdowns? how would you know which is used? which IP to connect to? just some questions. Thanks
In my experience, it will connect to both, so you will have two IP addresses. It will route to the Internet via the ethernet connection. It will configure wifi routing only to the LAN for the wifi. If ethernet and wifi connect to the same LAN, I presume that it will actually send packets via ethernet, but I have not tested that.
If you unplug the ethernet, it will then setup Internet routing via the wifi connection, though I don’t recall whether I have thoroughly tested that.
For a laptop, it seems to be making reasonable choices that fit most situations.
On 11/28/2012 07:26 PM, nrickert wrote:
>
> dmera;2507398 Wrote:
>> so if both of them are setup as ‘system connection’ in NM which one will
>> have priority?
> In my experience, it will connect to both, so you will have two IP
> addresses. It will route to the Internet via the ethernet connection.
> It will configure wifi routing only to the LAN for the wifi. If
> ethernet and wifi connect to the same LAN, I presume that it will
> actually send packets via ethernet, but I have not tested that.
>
> If you unplug the ethernet, it will then setup Internet routing via the
> wifi connection, though I don’t recall whether I have thoroughly tested
> that.
>
> For a laptop, it seems to be making reasonable choices that fit most
> situations.
The above is correct. The wired connection is always preferred as it will be
faster and more stable, but if you unplug the wire, or down the connection in
the applet, it switches to wireless. Early in the 12.2 development process, the
change in routing did not work, but that was fixed some time ago.
That’s nice! I’m glad this usage scenario has been thought about.
I’m using “Traditional” now, in order to get things to start up at boot time, without waiting for me to log in. I tried doing this in NetworkManager, but as already said, the option for making the connection a “system connection” is grayed out all the time, in 11.4. I’m pleased to learn this has been fixed, in 12.2.
While at my desk, I prefer to have a wired connection, for speed and stability. However, when moving about, the only choice is wireless. I don’t want to have to manually administer the network configuration every time I change between wired and wireless.
Sounds like an upgrade to 12.2 is in order, to pick up these two features!
Actually,
I’ll disagree with the practices described in this thread.
Over the years, I’ve had an opportunity to experiment and observe both wired/wireless and wired/wired scenarios(sometimes unintentionally) where a multi-homed machine was configured with two NICs on the same network (but not in a recommended configuration like bonding).
All such situations are not recommended at all and will always result in increased amount of wasteful chatter, failures and re-sends. The reason why is that TCP/IP is a two-way communications protocol. Whenever you send a packet, it should be acknowledged with a message sent back to the same IP address. If the packet arrives at the machine on the wrong interface, the acknowledgement will not succeed. Same thing at the session level. If your “conversation” is initiated through one interface but packets are returned to the other interface, you’ll experience failures and re-sends.
So, if someone <really> wanted push the idea, for example trying to setup some kind of “poor man’s fail-over” it’s theoretically possible to assign routing costs that will utilize only one connection and only if that connection “fails” then the other is utilized, but even that is not foolproof… Heavy congestion and other transient causes of latency can still screw up how things should work.
In the end, I can only recommend
Unless you are using a device specially designed to manage failover, physically disconnect or disable connections. Wired connections can be physically disconnected. If your laptop doesn’t have a hardware wireless switch, you can use rfkill from the openSUSE repos to disable through software.
Keeping your connections simple and clean will greatly improve your throughput.