Although I've been updating my Cauldron notebook daily, I haven't rebooted it in awhile. I did this morning, and found something interesting. My wireless (RTL8191SEvB) hadn't come up, and when I clicked on the icon to open the net applet, the interface was gone. Reviewing syslog, I found: NetworkManager[4416]: ifcfg-rh warning: NM_CONTROLLED was false but HWADDR or SUBCHANNELS was missing; device will be managed The ifcfg-wlan0 is still there with NM_CONTROLLED=no, but the net applet doesn't recognize it, and drakconnect won't recognize it now either, giving only the ndiswrapper option for the interface (presumably these tools have been updated to disregard any interface that NM has "claimed"). WTF ?? I had NM_CONTROLLED=no in there for a reason, as NM has never been able to deal with this device. Can't somebody teach this immature package to keep its paws off of things it's been told to leave alone ? As in the past, rpm -e --nodeps networkmanager and a reboot put everything back to normal.
So NetworkManager doesn't work for your wireless card, but I cannot tell what the issue is. Could you please explain the issue a bit more?
CC: (none) => olavSummary: networkmanager strikes again => NetworkManager doesn't work with RTL8191SEvB
The problem of NM not working with the RTL819x family is covered and documented in https://bugs.mageia.org/show_bug.cgi?id=2160 , last updated in January. This bug is about NM suddenly deciding that it knows better than the user who configures NM_CONTROLLED=NO in the ifcfg. Prior to this, as detailed in bug#2160, I had NM installed, and it was finally respecting NM_CONTROLLED=NO. All was well. Now, as shown by the syslog message above, NM is deliberately controlling the device in spite of NM_CONTROLLED=NO. What additional info do you need ? Googling the syslog message shows that many people are having problems with this, cf https://bugzilla.redhat.com/show_bug.cgi?id=691327 I don't so much mind NM not supporting my device, as long as I can turn it off.
Summary: NetworkManager doesn't work with RTL8191SEvB => NetworkManager overrides NM_CONTROLLED=NO
I could actually only make out that you're having issues and that you do not like NetworkManager as a result of bugs. Regarding NetworkManager managing your device: > NetworkManager[4416]: ifcfg-rh warning: NM_CONTROLLED was false but HWADDR or SUBCHANNELS was missing; device will be managed Most of the discussion in bug 2160 is advocacy to remove networkmanager. It is a dependency for gnome-control-center; so I rather have bugs in networkmanager fixed. But then I need more information about the actual bugs. FYI, not the networkmanager maintainer, just interested that it works. I didn't notice that bug 2160 was about networkmanager though.
(In reply to comment #3) > > Regarding NetworkManager managing your device: > > NetworkManager[4416]: ifcfg-rh warning: NM_CONTROLLED was false but HWADDR or > SUBCHANNELS was missing; device will be managed ?? What about it ? > > Most of the discussion in bug 2160 is advocacy to remove networkmanager. It is > a dependency for gnome-control-center; so I rather have bugs in networkmanager > fixed. But then I need more information about the actual bugs. Incorrect. There are 21 comments in bug#2160, and only one of them (comment 8) advocates removing NM. The rest consists of diagnostic information and logs. Please read the *entire* bug, and tell me what else you need.
(In reply to comment #4) > ?? What about it ? It saying it will manage it right as it wants some other info. So put the info in there and see if it ignores it properly now. > Incorrect. There are 21 comments in bug#2160, and only one of them (comment 8) > advocates removing NM. The rest consists of diagnostic information and logs. But mostly about disabling NM. After careful checking in that bug I can see something about "timeouts" and 2 comments with details: bug 2160 comment 19, bug 2160 comment 20. I'll try to look into that.
Blocks: (none) => 5015
Targetting for Mageia 2. Whatever the case, NM should just be made only look for NM_CONTROLLED=NO. I cannot though. Patch welcome!
Priority: Normal => release_blockerTarget Milestone: --- => Mageia 2
Colin, Could you make a patch for this pretty please?
Assignee: bugsquad => mageia
Actually is this not fixed in latest initscripts? If NM_CONTROLLED var is not in the ifcfg file our network scripts will now assume NM will take over if it runs. If NM is not running then our initscripts will take over. In other words I think this has been addressed, but addressed differently. One bug may remain in draknetcenter in that it probably doesn't tick the NM box when no NM_CONTROLLED var exists (i.e. it defaults to no, not yes).
This has been fixed a while ago in networkmanager: * mar. mars 06 2012 blino <blino> 0.9.3.995-3.mga2 + Revision: 220666 - add back "discover mac address" patch, to fix handling of NM_CONTROLLED=no in ifcfg file (incorrectly dropped by fwang in r209998) - add back "discover mac address" patch, to fix handling of NM_CONTROLLED=no in ifcfg file (incorrectly dropped by fwang in r209998)
Status: NEW => RESOLVEDCC: (none) => mageiaResolution: (none) => FIXED