Re: howto ignore rfkill switch

[Larry Finger <Larry Finger lwfinger net>]

On 04/26/2010 11:32 AM, Jim Cromie wrote:
> On Thu, Apr 22, 2010 at 9:44 AM, Dan Williams <dcbw redhat com> wrote:
>> On Wed, 2010-04-21 at 18:49 -0600, Jim Cromie wrote:
> 
>>> 1 - with only built-in wifi card, I get a blank list.
> 
>>> 2 - once I plug in the pcmcia and usb cards, theyre both unblocked,
>>> but the builtin (ipw2200) is still missing.
> 
>>> Blocking and unblocking alters the displayed state (as above)
>>> but NM-applet says that all 3 are disabled.
>>
>> Yes, for a number of reasons.  First, we can't usually figure out which
>> killswitch is for which wifi device.  It's often just not possible, plus
>> "platform" killswitches provided by your laptop BIOS aren't tied to a
>> specific wifi device.  Second, you're probably better off blacklisting
>> the internal wifi driver modules so they simply don't load in the first
>> place.  Add the names (libipw, ipw2200) to
>> to /etc/modprobe.d/blacklist.conf to do this.
>>
>> If you rmmod ipw2200, what happens?
> 
> 
> Interesting. At 1st, I failed to see this as responsive;
> how could removing a driver enable others ?
> but I tried anyway, and lo-and-behold:
> 
> with ipw2200 rmmod'd, I can now enable the pcmcia card
> (which didnt work before), after a few tries, it connected !!
> It held for several minutes, then dropped, and wont reconnect,
> but that appears to be something else
> So laptop is usable (w/o a leash) again, thanks!
> 
> so, what happened ?  Is this a teachable moment ?

This is expected behavior. My box has a PCIe card that usually contains
one of the Broadcom flavors. If I turn off the switch, that will disable
any of my USB cards unless I unload b43, which also unloads its copy of
rfkill. Even though the b43 driver is not active on the air, its
feedback through rfkill is still active.

> 1- I re-modprobed ipw2200, and NM promptly killed the
> pcmcia card's connection, and shows both wifis as disabled.

As described above, that is predictable.

> 2- rmmod again removes both cards from NM-applets
> available wifi-interfaces list, but ejecting and reinserting pcmcia
> card reconnects.
> 
> 3- doing this also increments phy#, Im now on phy3
> (this isnt surprising/noteworthy really)

Each invocation is a new instance for mac80211 and is expected. When
testing, I sometimes get to 3 digit phy#.

> 
> Im also a bit unclear on soft/hard/platform distinctions,
> perhaps others are too.
> 
> 1- my kill switch affects plugin devices, so it cant be a hardware kill switch;
> hardware kills are directly connected to internal devices, and theres
> no such pcb-trace that crosses the USB plug  ( there *could* be in the
> pcmcia connector, but that too seems unlikely )
> Or do I read 'hardware' too literally ?

Once any hardware switch kills the radio, it kills it for ALL devices.
That is for safety and compliance with regulations. There is no physical
connection to the USB. The interaction is through the rfkill software.
It is a hard block because some hardware device is blocking.

> 2- the rfkill-LED is hard-wired to switch.
> I cant prove this though; since I cant toggle the switch,
> "udevadm monitor" cant see events that dont happen.

That depends on the device. On my box, b43 controls the LED. If b43 is
unloaded, the LED is always off; however, USB devices are not blocked,
even if the switch is off. Only if b43 is loaded does the switch
block/unblock.

> 3- why doesnt "rfkill list all" show the internal wifi device ?
> Is there a way for it to read and report a platform rfkill ?
> (presumably just once)

Pass on this one.

> 4- rfkill module is used by sony_laptop module,
> does this make my kill switch a 'platform kill' ?

Ditto.

Larry