Re: wpa_supplicant cli works, but NM insists "wireless is disabled"

[Andrew <andrew2006 flight us>]

>On Tue, 2008-09-30 at 15:18 -0400, Andrew wrote:
>> >On Tue, 2008-09-30 at 12:22 -0400, Andrew wrote:
>> >> >On Tue, 2008-09-30 at 06:30 -0400, Andrew wrote:
>> >> >> >On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote:
>> >> >> >> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote:
>> >> >> >> >>> Hello, 
>> >> >> >> >>> 
>> >> >> >> >>> I have appealed to the Fedora Forum, but no one seems to have a 
>
>> >clue 
>> >> >
>> >> >> >> >there.
>> >> >> >> >>> 
>> >> >> >> >>> Here is the thread:
>> >> >> >> >>> http://forums.fedoraforum.org/showthread.php?t=199562
>> >> >> >> >>> 
>> >> >> >> >>> (A quick synopsis of the thread:
>> >> >> >> >>> 
>> >> >> >> >>> I've activated/deactivated everything i could think of, related 
>to 
>> >
>> >> >> >> >>NetworkManager; yet, everything wireless is grayed out in the 
>> >applet.
>> >> >> >> >>> 
>> >> >> >> >>> But wpa_supplicant (cli) works! 
>> >> >> >> >>> 
>> >> >> >> >>> Additional info (beyond above thread):
>> >> >> >> >>> 
>> >> >> >> >>> I compiled the latest NetworkManager svn; still same grayed out 
>
>> >> >> >behavior.
>> >> >> >> >>> 
>> >> >> >> >>> )
>> >> >> >> >>> 
>> >> >> >> >>> I tried looking in the source and tracing the calls to and from 
> 
>> >> >> >> >>nm_client_wireless_get_enabled (if that's even a function) but, 
>> >> >ignorant 
>> >> >> >of 
>> >> >> >> >C, 
>> >> >> >> >>didn't get far.
>> >> >> >> >>> 
>> >> >> >> >>> Please help!
>> >> >> >> >>
>> >> >> >> >>Does NM think wireless is disabled because a HAL killswitch is 
>> >> >reporting
>> >> >> >> >
>> >> >> >> >Don't know enough about HAL to answer the above.  (Where would i 
>> >look?)
>> >> >> >> >
>> >> >> >> >>that it's off?  Could you post some logs from /var/log/messages 
>> >from
>> >> >> >> >>when NM starts up?  
>> >> >> >> >
>> >> >> >> >please see attachment.  (i've X'ed out some addresses 
>> >(xxxx:xxxx:....)
>> >> >> >> 
>> >> >> >> 
>> >> >> >> ooops.  The list strips attachment.  Here is a web link to the same 
>
>> >> >> >/var/log/messages chunk:
>> >> >> >> 
>> >> >> >>      http://www.flight.us/bugs/var_messages_nm_chunk.txt
>> >> >> >
>> >> >> >What's the output of:
>> >> >> >
>> >> >> >dellWirelessCtl
>> >> >> 
>> >> >> Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt
>> >> >> 
>> >> >> OK, it appears that the "problem"(?) /does/ originate in the BIOS (I 
>did 
>> >
>> >> >present this hypothesis at the Fedora forum, but no one took that path, 
>
>> >which 
>> >> >now seems correct)
>> >> >
>> >> >Yeah, if dellWirelessCtl says the WLAN is disabled, then that's what 
>the
>> >> >BIOS thinks.  The best thing I think you could do is file a bug against
>> >> >'libsmbios' package in Fedora bugzilla and the Dell guys will try to
>> >> >help you debug.
>> >> 
>> >> Yes, of course, my **internal** wifi card /is/ disabled in the BIOS!
>> >> (You may not have read my FedoraForum thread)
>> >> 
>> >> dellWirelessCtl is reporting correctly regarding the internal card 
>(only).
>> >> 
>> >> But why should this concern the external, removable cards??
>> >
>> >Because you've flipped the "kill my wireless" button.  If you didn't
>> >want to kill your wireless, don't flip the button.  It's a decision to
>> >treat any killswitch as killing all wireless devices of the same class.
>> >I don't believe it's useful to have individual killswitches apply to
>> >individual devices of the same class.
>> 
>> I certainly did not intentionally disable _ALL_ wifi devices; only the 
>onboard one is disabled.
>
>You flipped the "kill my wireless" switch which NetworkManager (by
>design) takes as the sign you wish to disable all your wireless devices.
>
>> So, why does wpa_supplicant see my external wifi device (wlanX), and use and 
>connect with it happily, inspite of this killswitch?
>
>Because the kernel rfkill layer isn't completely integrated yet and thus
>its not actually getting killed, though NM should be setting the
>device's TX power off.
>
>> Does anyone know where in the NM code is the querying of the status at 
>issue? I would like to play with the code.
>> 
>> (perhaps in src/nm-hal-manager.c ? There seems to be a kswitch_err method)
>
>That's the right place, but upstream isn't going to accept that code at
>this time.  It's a policy decision; I made the decision to keep things
>simple and direct and interpret the user's intent as disabling wireless
>when the rfkill switch is turned on.

Dan,

even if I were some sort of C and networking guru and veteran member of your development team, still i would not seek to impose any modifications to your code.  (And I am light years away from all the above)  (I say this in response to your mentioning "upstream" -- a word i've not heard before but assume has something to do with committing code changes for general use). Your generous contribution of skill has made things easier for millions.

However, could you please provide a quick hack to meet my rare need, to keep my wifi class always enabled, regardless of what the BIOS is reporting?  It would be confined to my system strictly.

Would be extremely grateful!

Andrew

>Dan
>
>> TIA
>> andrew
>> 
>> >Dan
>> >
>> >> Why should NetworkManager get info from the BIOS regarding the *internal* 
>
>> >device, and, based on that, disable Wifi globally, for ALL the cards, 
>> >including the removable ones, which are configured and working perfectly 
>(with 
>> >wpa_supplicant)
>> >> 
>> >> (the goal here is to use my external, removable Atheros card, and keep 
>the 
>> >built-in card disabled in the BIOS)
>> >> 
>> >> This looks like an algorithmic oversight in the NM's code. Also, I would 
>
>> >think, an easy fix (if only i knew C!)
>> >> 
>> >> Thanks in advance!
>> >> 
>> >> andrew
>> >> 
>> >> 
>> >> >Dan
>> >> >
>> >> >> For a quick & dirty fix: any way to force the disabled/enabled switch 
>in 
>> >the 
>> >> >NM source?  Again, i tried to find this in the source and failed.  Where 
>is 
>> >
>> >> >it?
>> >> >> 
>> >> >> I wonder if this can be considered a bug or glitch -- my situation 
>> >> >apparently presents a need for NM to be more user-configurable here.
>> >> >> 
>> >> >> Thanks.
>> >> >> 
>> >> >> >HAL found a killswitch and NM is honoring the setting of that 
>> >killswitch
>> >> >> >apparently.
>> >> >> >
>> >> >> >Dan
>> >> >> >
>> >> >> >> 
>> >> >> >> 
>> >> >> >> >NM keeps saying "wlan1: link is not ready"
>> >> >> >> >
>> >> >> >> >Yet, I can do "iwconfig" and "iwlist" with NO problem whatsoever, 
>
>> >with 
>> >> >good 
>> >> >> >
>> >> >> >> >results.  Plus, as i said earlier (this seems VERY significant), i 
>
>> >can 
>> >> >> >connect 
>> >> >> >> >with wpa_supplicant no prob (all the while NM is saying "wireless 
>is 
>> >
>> >> >> >> >disabled"!)
>> >> >> >> >
>> >> >> >> >>It could also be that you've disabled the device in
>> >> >> >> >>system-config-network, in which case the menu will say the device 
>
>> >is
>> >> >> >> >>"unmanaged".
>> >> >> >> >
>> >> >> >> >I have played with system-config-network every which way, before. 
>
>> >> >"wlan1" 
>> >> >> >(and 
>> >> >> >> >"wlan0") are both assigned to NM, ("Controlled by NM" is checked). 
>
>> >> >(wlan0 
>> >> >> >> >versus wlan1 is created depending on which atheros card i insert 
>-- i 
>> >
>> >> >have 
>> >> >> >two 
>> >> >> >> >at my disposal)
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>dan
>> >> >
>> >
>