I've been using the dkms-rtl8192se wireless driver successfully since it landed in cauldron. As of a few days ago, link beat is no longer detected. Check out this snippet of syslog: Jul 15 15:59:43 localhost draknetcenter[21815]: modified file /etc/sysconfig/network-scripts/ifcfg-wlan0 Jul 15 15:59:43 localhost draknetcenter[21815]: modified file /etc/sysconfig/network-scripts/ifcfg-wlan0 Jul 15 15:59:43 localhost draknetcenter[21815]: changed mode of /etc/sysconfig/network-scripts/ifcfg-wlan0 to 755 Jul 15 15:59:43 localhost draknetcenter[21815]: written wlan0 interface configuration in /etc/sysconfig/network-scripts/ifcfg-wlan0 Jul 15 15:59:43 localhost draknetcenter[21815]: running: /sbin/ifdown wlan0 daemon Jul 15 15:59:44 localhost ifplugd(wlan0)[17841]: Exiting. Jul 15 15:59:44 localhost kernel: rtl8192_SetWirelessMode(), wireless_mode:4, bEnableHT = 0 Jul 15 15:59:44 localhost kernel: InitializeAdapter8192SE(): Set MRC settings on as default!! Jul 15 15:59:44 localhost kernel: HW_VAR_MRC: Turn on 1T1R MRC! Jul 15 15:59:44 localhost vnstatd[23999]: SIGHUP received, flushing data to disk and reloading config. Jul 15 15:59:44 localhost draknetcenter[21815]: running: /sbin/ifup wlan0 daemon Jul 15 15:59:45 localhost kernel: rtl8192_SetWirelessMode(), wireless_mode:4, bEnableHT = 0 Jul 15 15:59:45 localhost kernel: InitializeAdapter8192SE(): Set MRC settings on as default!! Jul 15 15:59:45 localhost kernel: HW_VAR_MRC: Turn on 1T1R MRC! Jul 15 15:59:45 localhost kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready Jul 15 15:59:45 localhost kernel: rtl8192_SetWirelessMode(), wireless_mode:4, bEnableHT = 0 Jul 15 15:59:45 localhost kernel: InitializeAdapter8192SE(): Set MRC settings on as default!! Jul 15 15:59:45 localhost kernel: HW_VAR_MRC: Turn on 1T1R MRC! Jul 15 15:59:45 localhost kernel: rtl8192_SetWirelessMode(), wireless_mode:4, bEnableHT = 0 Jul 15 15:59:45 localhost kernel: InitializeAdapter8192SE(): Set MRC settings on as default!! Jul 15 15:59:45 localhost kernel: HW_VAR_MRC: Turn on 1T1R MRC! Jul 15 15:59:45 localhost kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready Jul 15 15:59:45 localhost kernel: Linking with NETGEAR-2.4-G,channel:1, qos:1, myHT:0, networkHT:0, mode:6 cur_net.flags:0x40e Jul 15 15:59:45 localhost ifplugd(wlan0)[22131]: ifplugd 0.28 initializing. Jul 15 15:59:45 localhost ifplugd(wlan0)[22131]: Using interface wlan0/70:1A:04:F9:F9:2B with driver <rtl819xSE> (version: 0019.1207.2010) Jul 15 15:59:45 localhost ifplugd(wlan0)[22131]: Using detection mode: SIOCETHTOOL Jul 15 15:59:45 localhost ifplugd(wlan0)[22131]: Initialization complete, link beat not detected. Jul 15 15:59:45 localhost NetworkManager[3631]: <info> (wlan0): supplicant interface state: inactive -> disconnected Jul 15 15:59:45 localhost kernel: rtllib_associate_procedure_wq(), chan:1 Jul 15 15:59:45 localhost kernel: HTSetConnectBwMode():pHTInfo->bCurBW40MHz:0 Jul 15 15:59:45 localhost kernel: ==============>rtllib_associate_procedure_wq():ieee->current_network.qos_data.qos_mode is 11,ieee->qos_capability is 1 Jul 15 15:59:45 localhost kernel: rtl8192_SetWirelessMode(), wireless_mode:4, bEnableHT = 0 Jul 15 15:59:45 localhost kernel: SetHwReg8192SE():HW_VAR_AC_PARAM eACI:0:a425 Jul 15 15:59:45 localhost kernel: SetHwReg8192SE():HW_VAR_AC_PARAM eACI:1:a449 Jul 15 15:59:45 localhost kernel: SetHwReg8192SE():HW_VAR_AC_PARAM eACI:2:5e431c Jul 15 15:59:45 localhost kernel: SetHwReg8192SE():HW_VAR_AC_PARAM eACI:3:2f321c Jul 15 15:59:45 localhost kernel: Associated successfully Jul 15 15:59:45 localhost kernel: normal associate Jul 15 15:59:45 localhost kernel: Using G rates:108 Jul 15 15:59:45 localhost kernel: Successfully associated, ht not enabled(0, 0) Jul 15 15:59:45 localhost kernel: rtl8192se_update_ratr_table: ratr_index=0 ratr_table=0x00000ff5 Jul 15 15:59:45 localhost kernel: dis associate packet! From what I can see in the code, the 1T1R MRC stuff is a red herring, as it goes ahead and does what it's telling you to do anyway. But it looks like the NETDEV_UP code is concluding that there is no link beat before the AP is associated. Did some timing parameter change that would cause this race ?
could it be related tu bug 1751
CC: (none) => jquelin
Possibly, but in my case the link *never* comes up, and the messages in bug#1761 do not mention "link beat". I'll look forward to testing 3.0, but not until the dkms rtl package can compile.
The problem appears to be networkmanager using overly aggressive timeouts. I upgraded the RTL8192SE driver to the vendor's current release, and had the same problem in the 3.0.x kernel. Doing an rpm -e --nodeps on networkmanager and rebooting solved the problem nicely. In googling this, I find that people are having the same problem with nm and a wide range of wireless chips. Unfortunately, in Mageia, nm is required by networkmanager-applet, which is in turn required by GNOME, so Joe User isn't going to have much luck trying to do this with urpme. This problem occurred whether of not I had nm enabled in the ifcfg-wlan0 file. Please shitcan nm from the distribution until it is either fixed or can at least play nicely with devices that it can't manage properly, i.e. "NO" means "NO".
(In reply to comment #3) > In googling this, I find that people are having the same problem with nm and a > wide range of wireless chips. Unfortunately, in Mageia, nm is required by > networkmanager-applet, which is in turn required by GNOME, so Joe User isn't > going to have much luck trying to do this with urpme. > > This problem occurred whether of not I had nm enabled in the ifcfg-wlan0 file. > Please shitcan nm from the distribution until it is either fixed or can at > least play nicely with devices that it can't manage properly, i.e. "NO" means > "NO". You can disable nm by using the following commands as root: service networkmanager stop chkconfig networkmanager --del Maybe this should be added to Errata.
CC: (none) => jani.valimaa
i confirm that removing networkmanager made the trick: my wifi is now up & running again! \o/ however, i don't really understand, since dkms-r8192 still doesn't compile... lsmod shows that r8169 is loaded - does this module supports r8192 cards?
See https://bugs.mageia.org/show_bug.cgi?id=2399
I had a similar problem, and disabling networkmanager was the right solution for me too. My hardware is the following: [root@cauldron akien]# lspcidrake -v | grep NETWORK 8139too : Realtek Semiconductor Co., Ltd.|RTL-8139/8139C/8139C+ [NETWORK_ETHERNET] (vendor:10ec device:8139 subv:1631 subd:c023) (rev: 10) ath5k : Atheros Communications Inc.|AR5001 Wireless Network Adapter [NETWORK_ETHERNET] (vendor:168c device:001c subv:168c subd:3065) (rev: 01) My Wifi worked out-of-the-box in Mageia 1 and in Cauldron with kernel-desktop-2.x Since the arrival of kernel-desktop-3.0.x in Cauldron my Wifi stopped working: I could see the available cells but whenever I tried to connect to my home Wifi (or any other) it ended up with a "Connection failure" message. Shouldn't this issue with NM be a release_blocker for Mageia 2?
CC: (none) => rverschelde
Assignee: bugsquad => tmb
(In reply to comment #4) > > Maybe this should be added to Errata. Or maybe it should either be fixed or removed. Newbies are not going to read errata. NM is not needed (and is usually not enabled) for wired devices, and apparently it doesn't work very well with wireless devices. What is it doing in here to begin with ? Other, of course, than that it is new cool --- and obviously incomplete. Please drop it back to testing for those who want it. At present, --auto-select keeps reinstalling it.
Created attachment 856 [details] annotated logs I have done a fresh install, and have collected annotated syslog data and other stuff which I will attach. Basically, with NM around, ifplugd sees an initial no-link-beat from the kernel, and exits. However, the kernel isn't done bringing it up, does so successfully, and sends a NETDEV_CHANGE which ifplugd never sees. Without NM, ifplugd hangs around and sees the NETDEV_CHANGE, and all is well. NM appears to start out assuming that it owns everything, and gets told by ifcfg-rh that it doesn't only when the ifcfg-wlan0 is parsed and NM_CONTROLLED=no is found. But when the net applet tries to connect the wireless, ifcfg-rh gets a bogus error during the parse, and may never get around to seeing NM_CONTROLLED=no. The upshot is that NM rewrites the ifcfg-wlan0 with NM_CONTROLLED=yes.
just rebooted for new glibc and am now using 3.1.0-desktop-2.mga2: no more wifi for laptop, even when removing networkmanager (which got re-activated). i do have kernel-firmware-extra-20110817-2.mga2.nonfree & kernel-firmware-20110703-1.mga2 installed. any clue?
rtl8192se should be supported by upstream kernel in 3.1. Do you see any errors in dmesg ?
btw, two module options to test: ips=0 swlps=0 meaning add the line: options rtl8192se ips=0 OR: options rtl8192se swlps=0 OR: options rtl8192se swlps=0 ips=0 to /etc/modprobe.d/rtl8192se.conf
i know it is supported upstream. it was already working fine with 3.x which option should i try first? ips, swlps or both?
only thing in dmesg that i can see: ADDRCONF(NETDEV_UP): wlan0: link is not ready
ok, i found the problem. once again it's network manager - grr. even if networkmanager has been removed (rpm -e --nodeps), i had to mark NM_CONTROLLED=no in /etc/sysconfig/network-scripts/ifcfg-wlan0
Well if nm is not available on your system, i failed to understand how it can prevent you to connect here ;o)
CC: (none) => balcaen.john
Easy. Remove NM via rpm -e --nodeps, edit your ifcfg to say NM_CONTROLLED=yes, and then try "ifup <intf>". You'll get a message back saying "skipping, because interface is controlled by NetworkManager". Apparently the rest of the network software takes the setting of this variable seriously even if NM ignores it :-)
*** Bug 1751 has been marked as a duplicate of this bug. ***
Just to bring this up-to-date... I've done a fresh cauldron install and then booted. NM is installed and unmodified. The problem is still present, although current NM is giving much more detailed messages. I will attach an annotated syslog. Upon first boot, NM creates the wlan0 interface, but is unable to bring it up. Then I try to connect it using net-applet, which fails as well. Then I use drakconnect to redefine the interface, checking the box to allow NM to control it. The resulting attempt to bring it up still fails. I then rebooted. NM still couldn't bring up the interface, and neither could net-applet. I can see only three apparent problem areas in the log. First, NM is still not waiting long enough to detect link beat. Time after time, NM reports no link beat, the kernel reports no link beat, and a second later the driver associates and authenticates the interface. Second, NM keeps reporting errors in parsing the ifcfg because the SSID is not given there. It's not clear whether this causes a problem or not. Third, NM emits messages saying that it is ignoring the only AP connection (NETGEAR-2.4) due to environment variables even though NM_CONTROLLED is consistently set to YES.
Created attachment 1358 [details] more annotated syslog
CC: jani.valimaa => (none)
Some improvement.... Since the last comment, if I boot, run drakconnect for the wireless interface, and de-select "Allow interface to be controlled by NetworkManager", and reboot, the interface now comes up just fine. It doesn't come up fine without the reboot, i. e. during drakconnect's attempt to bring it up as a result of the change/redefinition. So NM is hanging onto something that a reboot clears, even when the ifcfg is changed.
CC: (none) => sebastien.guerin.news
Is Thomas Backlund the NM maintainer ? If not, could this be reassigned to whomever is ?
Summary: RealTek rtl8192se wireless has stopped working => RealTek rtl8192se wireless broken under NetworkManager
According to Sophie, nobody currently maintains NM...
Blocks: (none) => 5015
ping ? NM has a tracker bug, so somebody must be looking at it.
Are you saying that it still doesn't work? When did you try it last time? Or what problems are you actually seeing today? If needed then do a clean install and tell us what's wrong. For me NM is working just fine.
CC: (none) => sander.lepik
OK, we'll start with a working environment with NM disabled at startup (systemctl NetworkManager disable) and stopped, and wlan0 set to NM_CONTROLLED=NO. The wireless is up. Now we'll start NM, and redefine the wlan0 interface through drakconnect as NM_CONTROLLED=YES. The interface now fails to start at the tail end of drakconnect. Now we'll stop NM, and again redefine the interface through drakconnect, but with NM_CONTROLLED=NO, and now the interface comes up just fine (although drakconnect thinks it had a problem, the notification popup for wlan0 being up displays, and the interface is in fact up). I'll attach the syslog, starting with service networkmanager start.
Created attachment 2005 [details] syslog for NM failure
Did you restart the system after enabling NM?
No. Why should that make a difference ?
Well, quite often it seems to make.
Alright, I'll try it that way, although ifplugd didn't seem to be affected by the lack of a reboot. Out of curiosity, what was it in the syslog that suggested it ?
Same result. Enable NM at boot, drakconnect to define the wlan0 device as NM-controlled, reboot, NM fails to bring up wlan0, try doing it through netapplet, fails again, shut down NM, drakconnect to redefine wlan0 as NM_CONTROLLED=NO, activate it and it works. [root@ftglap ftg]# cat /var/log/syslog | grep "Apr 17 08" | grep NetworkManager Apr 17 08:39:03 localhost NetworkManager[3325]: ifcfg-rh: Acquired D-Bus service com.redhat.ifcfgrh1 Apr 17 08:39:03 localhost NetworkManager[3325]: <info> Loaded plugin ifcfg-rh: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Apr 17 08:39:03 localhost NetworkManager[3325]: <info> Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Apr 17 08:39:03 localhost NetworkManager[3325]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... Apr 17 08:39:03 localhost NetworkManager[3325]: <warn> failed to allocate link cache: (-10) Operation not supported Apr 17 08:39:03 localhost NetworkManager[3325]: ifcfg-rh: read connection 'System eth0' Apr 17 08:39:03 localhost NetworkManager[3325]: ifcfg-rh: Ignoring connection 'System eth0' and its device due to NM_CONTROLLED/BRIDGE/VLAN. Apr 17 08:39:03 localhost NetworkManager[3325]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-wlan0 ... Apr 17 08:39:03 localhost NetworkManager[3325]: <warn> failed to allocate link cache: (-10) Operation not supported Apr 17 08:39:03 localhost NetworkManager[3325]: ifcfg-rh: error: Missing SSID Apr 17 08:39:03 localhost NetworkManager[3325]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... Apr 17 08:39:03 localhost NetworkManager[3325]: <info> trying to start the modem manager... Apr 17 08:39:03 localhost NetworkManager[3325]: <info> monitoring kernel firmware directory '/lib/firmware'. Apr 17 08:39:03 localhost NetworkManager[3325]: <info> found WiFi radio killswitch rfkill0 (at /sys/devices/pci0000:00/0000:00:06.0/0000:09:00.0/ieee80211/phy0/rfkill0) (driver (unknown)) Apr 17 08:39:03 localhost NetworkManager[3325]: <info> WiFi enabled by radio killswitch; enabled by state file Apr 17 08:39:03 localhost NetworkManager[3325]: <info> WWAN enabled by radio killswitch; enabled by state file Apr 17 08:39:03 localhost NetworkManager[3325]: <info> WiMAX enabled by radio killswitch; enabled by state file Apr 17 08:39:03 localhost NetworkManager[3325]: <info> Networking is enabled by state file Apr 17 08:39:03 localhost NetworkManager[3325]: <warn> failed to allocate link cache: (-10) Operation not supported Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (eth0): carrier is OFF Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (eth0): new Ethernet device (driver: 'atl1c' ifindex: 2) Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/0 Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (wlan0): using nl80211 for WiFi device control Apr 17 08:39:03 localhost NetworkManager[3325]: <warn> (wlan0): driver supports Access Point (AP) mode Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (wlan0): new 802.11 WiFi device (driver: 'rtl8192se' ifindex: 3) Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (wlan0): exported as /org/freedesktop/NetworkManager/Devices/1 Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (wlan0): now managed Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] Apr 17 08:39:03 localhost NetworkManager[3325]: <info> (wlan0): bringing up device. Apr 17 08:39:04 localhost NetworkManager[3325]: <info> (wlan0): preparing device. Apr 17 08:39:04 localhost NetworkManager[3325]: <info> (wlan0): deactivating device (reason 'managed') [2] Apr 17 08:39:04 localhost NetworkManager[3325]: <info> modem-manager is now available Apr 17 08:39:04 localhost NetworkManager[3325]: <info> wpa_supplicant started Apr 17 08:39:04 localhost NetworkManager[3325]: <info> (wlan0): supplicant interface state: starting -> ready Apr 17 08:39:04 localhost NetworkManager[3325]: <info> (wlan0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] Apr 17 08:39:04 localhost NetworkManager[3325]: <info> (wlan0): supplicant interface state: ready -> inactive Apr 17 08:39:04 localhost NetworkManager[3325]: <warn> Trying to remove a non-existant call id. Apr 17 08:39:05 localhost network[3812]: Bringing up loopback interface: ./ifup: interface ifcfg-lo is controlled by NetworkManager; skipping. Apr 17 08:39:06 localhost network[3812]: Bringing up interface wlan0: ./ifup: interface wlan0 is controlled by NetworkManager; skipping. Apr 17 08:41:50 localhost NetworkManager[3325]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-wlan0 ... Apr 17 08:41:50 localhost NetworkManager[3325]: <warn> failed to allocate link cache: (-10) Operation not supported Apr 17 08:41:50 localhost NetworkManager[3325]: ifcfg-rh: error: Missing SSID Apr 17 08:41:50 localhost NetworkManager[3325]: ifcfg-rh: removed /etc/sysconfig/network-scripts/ifcfg-wlan0. Apr 17 08:41:50 localhost NetworkManager[3325]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-wlan0 ... Apr 17 08:41:50 localhost NetworkManager[3325]: <warn> failed to allocate link cache: (-10) Operation not supported Apr 17 08:41:50 localhost NetworkManager[3325]: ifcfg-rh: error: Missing SSID Apr 17 08:41:50 localhost NetworkManager[3325]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-wlan0 ... Apr 17 08:41:50 localhost NetworkManager[3325]: <warn> failed to allocate link cache: (-10) Operation not supported Apr 17 08:41:50 localhost NetworkManager[3325]: ifcfg-rh: error: Missing SSID Apr 17 08:44:01 localhost NetworkManager[3325]: <info> caught signal 15, shutting down normally. Apr 17 08:44:01 localhost NetworkManager[3325]: <warn> quit request received, terminating... Apr 17 08:44:01 localhost NetworkManager[3325]: <info> (wlan0): now unmanaged Apr 17 08:44:01 localhost NetworkManager[3325]: <info> (wlan0): device state change: disconnected -> unmanaged (reason 'removed') [30 10 36] Apr 17 08:44:01 localhost NetworkManager[3325]: <info> (wlan0): cleaning up... Apr 17 08:44:01 localhost NetworkManager[3325]: <info> (wlan0): taking down device. Apr 17 08:44:02 localhost NetworkManager[3325]: <info> exiting (success) [root@ftglap ftg]# Problem seems to be the error relating to SSID. However, the ifcfg-wlan0 created for NM had an SSID specified.
Interestingly enough, there is no ifcfg-rh file on my system, and rpmdrake doesn't find any such file belonging to any package. So NM must be creating it by itself on the fly.
$ urpmf ifcfg-rh networkmanager:/etc/dbus-1/system.d/nm-ifcfg-rh.conf networkmanager:/usr/lib64/NetworkManager/libnm-settings-plugin-ifcfg-rh.so
(In reply to comment #32) > Same result. Enable NM at boot, drakconnect to define the wlan0 device as > NM-controlled, reboot, NM fails to bring up wlan0 Did you configure it with NM tools? Or do you hope that it will connect automatically? I don't see any ifcfg-YOUR_SSID files mentioned in your log. So i'm not sure if you actually configured NM or not.
(In reply to comment #35) > (In reply to comment #32) > > Same result. Enable NM at boot, drakconnect to define the wlan0 device as > > NM-controlled, reboot, NM fails to bring up wlan0 > > Did you configure it with NM tools? Or do you hope that it will connect > automatically? I don't see any ifcfg-YOUR_SSID files mentioned in your log. So > i'm not sure if you actually configured NM or not. No. I did a fresh Mageia install, and used the Mageia tools (drakconnect), just as I said above. Nothing in the Mageia install says anything about using NM-specific tools. The only SSID-specific files I find are in /etc/sysconfig/network-scripts/wireless.d, they're named with the uppercase version of the SSID and there is one for the SSID mentioned in the ifcfg-wlan0 file.
If you want the connection to work with NM then you have to use NM tools to configure it. Those tools should be integrated into Gnome (AFAIK) ant there is plasma-applet-networkmanagement for KDE. If you configure network with NM tools then NM will create those SSID-specific files.
(In reply to comment #37) > If you want the connection to work with NM then you have to use NM tools to > configure it. Those tools should be integrated into Gnome (AFAIK) ant there is > plasma-applet-networkmanagement for KDE. If you configure network with NM tools > then NM will create those SSID-specific files. I'm using KDE. Is plasma-applet-networkmanagement an executable name, or does one get to it through the KDE GUI ? I'm a KDE newbie - only fled to it when GNOME decided it wanted to be in the SmartPhone business.
It's a package you have to install. Then you have to check your system tray's settings and mark checkbox that will enable NM icon in system tray. Then you can configure networks.
OK. Sander, I appreciate your input and effort. Thank you. <grrr> How in the hell is it that NM got dropped into cauldron without a whisper of the fact that drakconnect can't configure it ? Or that you have to do something NM-specific to make it work ? There have been half-a-dozen bugs opened here about NM not working for wifi. Not ONE has a comment even hinting at the fact that you have to manually install other packages and use something other than the MGA tools to configure the interface. Are we really proposing to release MGA 2 with this mystery stuff ? Why does this work out of the box for you and others, but not for me and others ? </grrr> Any hints on the paqckages that need to be installed ?
Hmm.. Is NM activated by default? ... No, it's not. You don't have to use it. And as i already told you, plasma-applet-networkmanagement is the package that you need if you are using KDE. And that should be all. Then just activate the plasma thingy and configure your network.
(In reply to comment #41) > Hmm.. Is NM activated by default? ... No, it's not. Yes, it is, for wireless but not for wired (see comment 19). Otherwise, a fresh install with default drakconect wireless config would be using ifplugd and would work out of the box. I haven't had a chance to test the NM configuration you mentioned yet. But if that's truly necessary, then those packages should be required by NM at the very least. Better still, drakconnect should be using them.
(In reply to comment #42) > I haven't had a chance to test the NM configuration you mentioned yet. But if > that's truly necessary, then those packages should be required by NM at the > very least. Better still, drakconnect should be using them. What's the point to require KDE tools under Gnome and vice versa?
Well, I'm not an rpm guru, so I'm not sure if there's a way for NM to say "if KDE's installed, then install ..." or for KDE to say "if NM is installed, then install ...". You're right, probably the latter is preferable if it is possible.
(In reply to comment #42) > (In reply to comment #41) > > Hmm.. Is NM activated by default? ... No, it's not. > > Yes, it is, for wireless but not for wired (see comment 19). Actually, this isn't quite true. NM *is* activated automatically, in the sense that installing it sets it to start at boot, but "control via NM" is not set by default for wireless connections. However, if NM is running, it still screws around with wireless before deciding that the device is not controlled, and interferes with ifplugd bringing it up. You have to shut NM down to get the wireless to start correctly. At least I do.
I've installed plasma-applet-networkmanagement, but I'm obviously missing the point of how to use it. Pretty much anything associated with the wireless icon in mt panel activates net_applet or drakconnect. If I open the KDE system settings and go to Network, it shows an empty list for wired interfaces (there is one), and the tab for Wireless is greyed out and can't be selected. How does one activate the configuration tool ?
Do you have the rtlwifi-firmware package installed? I see nothing in your kernel logs stating that the firmware is loaded successfully. Does "iwlist scan" from command line properly detect wireless networks? It could also be a duplicate of #3344
CC: (none) => mageia
(In reply to comment #47) > Do you have the rtlwifi-firmware package installed? > I see nothing in your kernel logs stating that the firmware is loaded > successfully. Yes, it's installed. > > Does "iwlist scan" from command line properly detect wireless networks? Yes. Of course, I can't swear that the install or NM put them there. It might have been drakconnect. But it's sort of a moot point, since if NM is disabled, the device works flawlessly. > > It could also be a duplicate of #3344 bug#3344 cites some symptoms in common, some of which I think are fixed (drak tools forcing NM_CONTROLLED=YES), but mostly it deals with roaming (which I'm not using) and wpa-supplicant. My syslog shows no occurrence of "wpa-supp", so I don't think it's a duplicate. From the logs, this looks for all the world like a combination of NM interfering with interfaces it isn't supposed to be managing and an overly aggressive timeout waiting for link beat.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Keywords: NEEDINFO => (none)Whiteboard: (none) => MGA2TOO
Frank: your logs do show some occurence of wpa_supplicant: Apr 17 08:39:04 localhost NetworkManager[3325]: <info> wpa_supplicant started Apr 17 08:39:04 localhost NetworkManager[3325]: <info> (wlan0): supplicant interface state: starting -> ready I have opened bug 6675 about the wpa_supplicant + NetworkManager conflict. This might be your bug as well.
Thanks Olivier, I'll watch 6675 and retest when it's fixed.
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
For the love of God, please put this info in errata of Mageia 2! When I installed Mageia 2 on my netbook, an Asus Eee PC 1005HA (wireless Atheros AR9285) I had to stay all night up trying to make my wireless work. Just by sheer luck I de-selected ""Allow interface to be controlled by NetworkManager" and rebooted and then I had a working wi-fi. A few weeks later I googled around to find comment 21 by Frank Griffin. But first I had to painstakingly go through the forum posts where only https://forums.mageia.org/en/viewtopic.php?f=25&t=2725#p20409 and https://forums.mageia.org/en/viewtopic.php?f=25&t=2581#p19355 by doktor5000 gave a clue what the problem is. Again, put it in errata, I always read the errata before I install a new distribution.
CC: (none) => dieter.rogiest
The laptop which has the rtl chip is out for repair, and I can't test this using it, but the laptop I'm preparing to replace it temporarily shows the same symptoms with a broadcom chip, so this may help the rest of you... Picking up the above discussion with Sander, he claimed that NM had to be configured with NM tools. I installed the plasma-knetworkmanager-applet, but couldn't figure out how to run it. Just for the hell of it, I thought, "well, since GNOME requires NM, and since the RH pages claim that the GNOME NM interface is nicer, why don't I try it there ?" Having configured the wlan0 interface with drakconnect, log into GNOME, look at the top right of the screen for a network icon, click on it, and see if your wireless SSID is shown as up and works. If not, click on the SSID. That should do it. I found that all of a sudden syslog had a ton of stuff about NM adding SSID and other stuff to the config, and suddenly all was well. Please post back if this works for you. And Sander, exactly what is it that you do with the plasma applet to get it to do the same thing ?
Many thanks, Frank; have made a note for future reference. For now, when I re-installed Mageia-2, I configured the wireless via MCC/Network/Set up a network interface, and it installed a ton of things such as dkms-broadcom, desktop-devel-kernel, gclib, gcc, and the wireless mechanism leapt into action and has performed well. Mind you, when I did exactly the same thing with Mageia-3-Alpha2, although it did find the SSID, it was never able to connect to it. N.B. When I tried Mint-13-KDE and Ubuntu 12.04- LTS, the wireless worked 'right out of the box'... (On the other hand, they both incorrectly show the netbook as having a 800x600 screen, instead of the native 1024x600, but that's another story...)
CC: (none) => maurice
I think you meant to comment on bug#7844 :) But the point of my post was that until the drakx tools are fixed for whatever changed in the new kernel, you may be able to get your wireless to work on cauldron with NM by trying to activate it under GNOME.
Oops - yes, sorry! But point taken, Frank.
> Having configured the wlan0 interface with drakconnect, log into GNOME, > (In reply to comment #54) Decided to give that a try, but could not see how to login to Gnome (on a Mageia-3-Alpha2 KDE install). The Login options are: - Default - Custom - IceWM - KDE4 - drak3D - Failsafe How is it done, please?
urpmi task-gnome-minimal ? :)
If you don't have GNOME, you probably don't want to install it just for this (but if you don't have GNOME, how did you get NM ?). John Balcean says that the KDE network -> network connections will write the NM files if you try to configure the connection with it. Or, you can install plasma-network-management, do "Add widgets" to your panel, select Network Management, and that should write them as well.
(In reply to comment #60) > If you don't have GNOME, you probably don't want to install it just for this > (but if you don't have GNOME, how did you get NM ?). I never said I had NM! Your original posting in https://bugs.mageia.org/show_bug.cgi?id=7844 referring to this Bug Report was responding to my report there w.r.t. the MCC Network Centre (on a KDE system), where I configured the wireless connection. (Never used Gnome (except to have quick try once.)
[Adding this while it's fresh in my mind...] Under mga1, had no problems moving between home, office and back. Shut lid at one location, open at other & running... Since mga2, NEVER been able to get wireless up without "reconfiguring" it. Both configurations are IDENTICAL in every respect except for SSID. Both use the same static IP 192.168.1.217**; even the WiFi channel (1) is the same at both locations. ** I'm the admin for both locations, so yes I know what I'm doing and why :) To get wireless up, I have to go through "configuring" the network accepting every default except the screen which shows the network SSID. No matter whether there is only one, or several SSIDs listed, the "default" selected is always "Unlisted - edit manually". If NM is installed & running, network will not come up. "service networkmanager stop" lets network come up automatically. Not exactly intuitive :) Just issued the commands in Comment 4 (but only after bringing network up to be able to read this bug report). Hoping this will do the trick when I head back home later...
CC: (none) => pf
Don't know why I didn't think to try this before... closed lid as if headed home, waited for all activity to stop; re-opened and network does not come up. OK... removed networkmanager: # urpme networkmanager-0.9.4.0-4.mga2 To satisfy dependencies, the following 3 packages will be removed (10MB): knetworkmanager-common-0.9-3.mga2.x86_64 (due to missing networkmanager) networkmanager-0.9.4.0-4.mga2.x86_64 plasma-applet-networkmanagement-0.9-3.mga2.x86_64 (due to missing knetworkmanager-common) Remove 3 packages? (y/N) y removing knetworkmanager-common-0.9-3.mga2.x86_64 networkmanager-0.9.4.0-4.mga2.x86_64 plasma-applet-networkmanagement-0.9-3.mga2.x86_64 removing package plasma-applet-networkmanagement-1:0.9-3.mga2.x86_64 removing package knetworkmanager-common-1:0.9-3.mga2.x86_64 removing package networkmanager-0.9.4.0-4.mga2.x86_64 writing /var/lib/rpm/installed-through-deps.list Closed lid again... network won't come up. Able to connect with Network Center. BUT... NC shows correct SSID (PWRealty), yet hovering mouse over network icon in tray shows wlan0 info with WRONG SSID (HG) which is my home network. Close/open lid gives same results. Still testing...
CC: (none) => liberforce
Frank, can you confirm that this bug still exists in Mageia 3 beta2? We have a lot of comments here, not sure how many of them are relevant to the topic.
Sorry, I can't. The laptop with the RTL chip is dead. And I switched from using ifplugd to NM when kernel updates broke ifplugd with wireless. I'll close this, since I think there are more recent bug reports about RTL chips.
Status: NEW => RESOLVEDResolution: (none) => OLD