Re: wireless hardware disable switch forbids the use of external wifi cards

[Dan Williams <dcbw redhat com>]

On Fri, 2009-02-13 at 21:50 -0500, Mikhail Zakharov wrote:
> I am not sure why disabling faulty card is a good solution - Why is
> this switch interacting with the software anyways? I believe that
> network manager is becoming "too user friendly" - the switch on my
> laptop for example controls only wireless antenna of the wifi card -
> nothing more. It should not affect the operation of other devices
> connected to the machine. Thus, any external components connected to

Here's the problem ^^^

*You* know it's external.  It's a bit harder to figure out that it's
external;  going to that much work isn't really worthwhile.  I suppose
you could go through HAL and see if one of the parents of the card was a
CardBus slot, or a PCMCIA slot, or a CF slot, or an SDIO slot (except
some SDIO slots are internal and so that doesn't work), or an
ExpressCard slot.

But USB?  That simply doesn't work, because there are certainly machines
(OLPC and the Intel Classmate aren't the only examples) that have an
"internal" USB port that they repurpose for wifi; but of course it's
just a USB port and the kernel has no idea if it's internal or external.

So were we to implement this hack, when people who use external USB
adapters complain that their device got killed because the switch
flipped, but their CardBus card didn't, and they don't want their USB
device to turn off, what do we say to them?

How many hacks do we have to put into NetworkManager for fairly uncommon
use-cases?  Each hack is more code to maintain, more potential for bugs,
etc.  

Dan

>  the machine should be operational. Secondly - having two network
> cards in one machine, and one turned off is a valid scenario - I use
> an external one when my bult in one does not have enough juice,
> however most of the cases - I only use the internal one - so
> blacklisting is not an option, not for me at least. Then, again, why
> not just implement a setting such that a user chooses to decide which
> devices are killed by the hw switch and which are not. The wireless
> service itself should not depend on the switch in any case.
> 
> On Fri, 2009-02-13 at 12:27 -0500, Dan Williams wrote: 
> > On Fri, 2009-02-13 at 17:11 +0000, Robert Lazzurs wrote:
> > > On Fri, Feb 13, 2009 at 16:47, Dan Williams <dcbw redhat com> wrote:
> > > > On Thu, 2009-02-12 at 19:53 -0500, Mikhail Zakharov wrote:
> > > >> Hi, I have a really bad internal wireless card. If I disable it and try
> > > >> to use an external PCIMCA card, the network manager will not let me do
> > > >> this since wireless option is automatically disabled based on the switch
> > > >> state. I was wondering whether anyone has noted this, since imho this is
> > > >> a serious issue. Why can't we have a per device control like in windows,
> > > >> where each network adaptor has its own set of enable/disable controls. A
> > > >> quick solution to this problem would be I think to revert to Nm 0.6
> > > >> behaviour, where hardware switch did not affect the software state and
> > > >> everything worked fine. If anyone has worked on a patch that does this,
> > > >> please let me know. Thanks, Mikhail
> > > >
> > > > For a number of reasons, NetworkManager does not support per-device
> > > > rfkill.  For starters, "rfkill" means "turn the radio off", and that's
> > > > exactly what NetworkManager does.  It turns off the radios.
> > > >
> > > > Second, it's not really possible to match up rfkill switches with
> > > > specific wireless devices.  On some machines they are tied to the
> > > > specific card, but these days most of them are implemented through BIOS
> > > > or via keyboard softkeys, and you simply cannot figure out which device
> > > > the rfkill switch is intended for, if that's even a valid assumption
> > > > that an rfkill switch is paired with a specific device.
> > > >
> > > > The option Windows uses is to bring up huge vendor-specific "Laptop
> > > > control" panels every time you hit a killswitch, which are ugly, require
> > > > many more clicks to disable things, and not something we should be doing
> > > > here.  We should be making the 90% use-cases easy, enabling the next 5%
> > > > with some effort on the part of the user, and usually ignoring the other
> > > > 5% completely (for good reason; if you try do everything, you succeed at
> > > > nothing).
> > > 
> > > Without repeating my self does it not make sense then to allow
> > > NetworkManager to re-enable cards on a per card basis after the rfkill
> > > switch has been activated.
> > 
> > A per-card basis would require UI to pop up and ask you which cards you
> > wanted to un-kill when you flipped the switch back, right?  What if you
> > want rfkill to work on all devices?
> > 
> > > I agree once that switch has been turned off it should by default kill
> > > all radio signals from the device however it would be nice to be able
> > > to then turn on a selected device if required without turning them all
> > > on again, for me this seems to be a win for everyone.
> > 
> > Depends; again, its a tradeoff between functionality and usability.  Now
> > I'd agree that we may be able to do better here and show such UI only if
> > there's more than one device on the system.  However, as I stated a bit
> > before, that's not something we can reliably do until we have (a) a
> > better way to detect what killswitches apply to which devices, and (b)
> > better rfkill support in HAL.
> > 
> > The problem is that some devices are tied to specific cards, others are
> > not.  There's no way to detect which devices are which.  So in the case
> > of, say, Intel 3945 cards, which are in millions of laptops, the switch
> > actually kills the intel radio directly.  Thus when the switch is turned
> > off, we don't always know which radios can be un-killed by software, and
> > which can be unkilled by hardware.
> > 
> > Dan
> > 
> > _______________________________________________
> > NetworkManager-list mailing list
> > NetworkManager-list gnome org
> > http://mail.gnome.org/mailman/listinfo/networkmanager-list