Re: "Adapter Switching" option which powers down the wireless radio when a wired ethernet connection is detected

[Dan Williams <dcbw redhat com>]

On Mon, 2012-09-17 at 17:00 -0400, John Walicki wrote:
> Dan Williams <dcbw redhat com> wrote on 09/17/2012 04:32:56 PM:
> 
> > On Mon, 2012-09-17 at 14:11 -0400, John Walicki wrote:
> > > In the Intel ProSet utility on Windows there is an "Adapter Switching" 
> 
> > > option which powers down the wireless radio when a wired ethernet 
> > > connection is detected.  The wireless radio is powered down when the 
> > > ethernet cable is inserted and the wireless adapter is powered on once 
> 
> > > again when the ethernet cable is removed. 
> > > 
> > > Normally, a dual homed environment with both wired and wireless having 
> 
> > > assigned IP addresses is preferable.  Routing will send the packets 
> over 
> > > the preferred interface.   We're constrained by the available IP range 
> for 
> > > wireless devices and only want to assign the IP address if the laptop 
> is 
> > > untethered.
> > > 
> > > Is this possible with NetworkManager?
> > 
> > Hi John,
> > 
> > This was brought up in the last two weeks, and we approached it by using
> > Dispatcher scripts to "airplane mode" the wifi.  That should work for
> > you if you don't mind a short period of time (like 1 second) where both
> > the wired and the wifi networks are connected with IP addresses.  This
> > would entail a dispatcher script that:
> > 
> > 1) whenever it gets an "up" event, runs "nmcli dev" and looks for any
> > line that contains *both* "802-3-ethernet" and "connected"; if one is
> > found, it executes "nmcli nm wifi off".
> > 
> > 2) whenever it gets a "down" even, runs "nmcli dev" and looks for any
> > line that contains *both* "802-3-ethernet" and [ "connecting" or
> > "connected" ].  If none of these lines around found, it runs "nmcli nm
> > wifi on".
> 
> That approach works for me.  Are there some sample dispatcher scripts that 
> we could leverage?
> Thanks for the tip.  I had proposed flipping the hard wireless kill switch 
> but that requires teaching users to participate in helping the network 
> infrastructure.  That rarely works out well.
> 
> We have some locations that have so many smart phone/mobile devices 
> soaking up wireless IP addresses that we're running out of IP ranges. With 
> thousands of Wireless Access Points, we're scaling infrastructure and 
> reconfiguring networks as quickly as we can.  Good thing we have a Class 
> A.  This might be a safety valve.
> 
> > 
> > The previous query had a network that simply would not give a DHCP lease
> > when the wifi still had an IP, and the dispatcher scripts could not
> > handle that case (yet).  However, all that information is available via
> > D-Bus, so that's another option.
> > 
> > That said, this is something that might make sense to integrate into NM
> > on a more permanent basis in the future.
> 
> Yes, this would be a nice feature to fully integrate into NM.

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/dispatcher

Which should do the trick. Note that I don't believe that when the WiFi
gets killed, that it actually release the DHCP lease.  We could add that
functionality to NM when setting airplane mode, but in general we don't
want to *always* release the DHCP lease, since that makes all
connections go through the lengthy DISCOVER + OFFER + ACCEPT stages of
DHCP, while simply trying to renew an existing lease is actually pretty
quick.  The difference there is often 5 - 10 seconds longer, especially
on wifi where the DHCP DISCOVER packets tend to get lost on congested
networks.

Dan