Pre mga3 alpha2 LiveCD Gnome i586 Live mode The hardware in this laptop is not well supported since mga1 See also bug 6077 which may or may not be relevant. Once I managed to get it to boot (acpi=off xdriver=fbdev or vesa) I tried to connect the wifi. It can see networks and once configured (WPA2-PSK) tried to connect at first but couldn't. On checking settings it has moved back to OpenWEP. Setting back to WPA2 and clicking connect opened the configuration screen again. lsmod showed the ipw2200 module is loaded and unloading/reloading made no difference. Could this be missing firmware? Also tried with networkmanager, ticked the allow to be managed by networkmanager. NM can see networks but clicking on one says Insufficient Privileges (32) I don't know if this is relevant here but once NM has control of the interface there is no way to switch it back, drak tools don't show any networks to remove the setting so it has to be manually altered in ifcfg-eth0.
CC: (none) => tmb
NM is notorious for wrapping its paws around things it's been told to leave alone. I've never had the chip you mention, but I've had several machines where just having NM running interferes with the ability of non-NM wireless to connect. Try "systemctl disable NetworkManage.service" and rebooting. Also, you should be able to rvert NM controlling an interface by reruning drakconnect (MCC Add an Interface) for the interface.
CC: (none) => ftg
Whiteboard: (none) => 3alpha2
Valid still latest (10/10) Live ISOs (Live DVD Gnome i586)(10/10)
Summary: Mga3 alpha2 LiveCD Gnome i586 ipw2200 Wifi can see networks but not connect => Mga3 alpha2 Live Gnome i586 ipw2200 Wifi can see networks but not connect
rpm -qa | grep ipw ipw2100-firmware-1.3-4.mga1 ipw2200-firmware-3.1-2.mga1 I have a feeling this laptop actually has ipw2100 rather than ipw2200 but lspci reports it as : 02:07.0 Network controller: Intel Corporation Pro/Wireless 2200BG [Calexico2] Network Connection (rev 05)
What happens if you enable NM in configuration and after that run "service network restart && service NetworkManager restart" Is NM able to configure networks after that? If not then how many wpa_supplicants are running? (ps aux |grep wpa)
Keywords: (none) => NEEDINFOCC: (none) => sander.lepik
Component: Release (media or process) => RPM Packages
I'll test this beta3 tomorrow, thanks for the reminder
NM takes control of the wired interface despite it being set automatically not to. I think this is likely the problem. service network restart fails and systemctl status network.service shows RTNETLINK answers: File exists. There are two wpa_supplicants running with different options. /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant.conf -P /run/wpa_supplicant.pid /usr/sbin/wpa_supplicant-B -i eth1 -c /etc/wpa_supplicant.conf -D wext
Keywords: NEEDINFO => (none)Whiteboard: 3alpha2 => 3alpha2 3beta3
Summary: Mga3 alpha2 Live Gnome i586 ipw2200 Wifi can see networks but not connect => Live Gnome i586 ipw2200 Wifi can see networks but not connect
valid 3beta4 (live gnome 32 dvd) Different machine, different adapter. from lsusb.. Netgear WN111(v2) Rangemax Next Wireless [Atheros AR9170+AR9101] uses carl9170 driver.
Summary: Live Gnome i586 ipw2200 Wifi can see networks but not connect => Gnome - Wifi can see networks but not connect
Whiteboard: 3alpha2 3beta3 => 3alpha2 3beta3 3beta4
Priority: Normal => release_blocker
/var/log/wpa_supplicant.log has repeating lines.. wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason 3 wlan0: No network configuration found for the current AP
Once it's installed it remembers the net-applet settings and connects fine, although NM is still controlling the wired interface.
"systemctl disable NetworkManage.service" and rebooting did solve my problem (bug 9631) similar to the bug signaled by Claire.
CC: (none) => danielpf
*** Bug 9631 has been marked as a duplicate of this bug. ***
CC: (none) => mageia, olav
CC: (none) => pierre-malo.denielou
Claire, no test with RC. Can you please test?
Sorry I have lots of bugs open, I can't update each of them for every iso. I noticed though that NM seems to be the default for both wired and wifi now in Gnome and it works alot better. It connects to wifi and wired without issues, to the extent I probably didn't test with drak* I need to test something on the laptop from comment 0 tomorrow so I'll check this too.
Ping :)
Doing it now before i forget, sorry Sander.
It's not about me, but well.. it's marked as release critical and we really should try to get rid of those bugs :)
Booting acpi=off and xdriver=vesa again for bug 6077 from gnome livedvd 3RC NM has control of wired and wifi and shows wifi networks and can connect. I'll reboot and attempt the same with net applet.
Unable to connect using net applet, two wpa_supplicants running. Worse is that once attempting to connect with net applet and failing due to this bug, due to bug 7317 it leaves the user unable to connect with either NM or net applet.
Whiteboard: 3alpha2 3beta3 3beta4 => 3alpha2 3beta3 3beta4 3RC
Anybody can test this btw ;)
Can you test one more thing. Can you install from this live iso and see if it would keep working. We can't have both of them working with Gnome. But I would call it a working solution when NM keeps working after installing.
not on that computer unfortunately
I'll dig out my wifi dongle and try it on a desktop, unless you beat me to it.
After install NM connection still works until the point where net applet is opened and OK'd. The NM connection then disconnects silently but the icon still shows as being connected. Clicking the icon shows wifi is now unmanaged. No wifi connection can then be made in net applet, leaving the user with no wifi. It would be better in gnome if net applet were disabled. At the moment it is a bit of a timebomb. If bug 7317 were tackled instead it may not be so much of an issue.
Well, even if we disable it on live isos there is still the standard install media where we can't do much about it. net_applet should have a checkbox enabled by default that would tell it to not run in Gnome. But that would mean that the user can't use Gnome and other desktops at the same time. Well, this is way too complicated :)
CC: sysadmin-bugs => (none)
I think the problem is that this is a race. NM as we install it will honor an ifcfg-xxx that tells it not to manage an interface, but absent that, it grabs it. So if NM runs before you run drakconnect (or anything else that creates a non-NM ifcfg), you'll have problems. I don't know if NM will honor an ifcfg that appears after the fact. Ideally, since net-applet appears to be not long for this world, it would detect that NM was running and use the NM CLI to see if NM is handling an interface, and if so, leave it alone. That would cover both the use of GNOME and the use of other desktops when the user chooses to use NM.
(In reply to Frank Griffin from comment #25) > I think the problem is that this is a race. Yes, it is a race issue in NetworkManager, which I described in bug 6675: https://bugs.mageia.org/show_bug.cgi?id=6675#c0 This bug is likely a duplicate.
Hi, I have similar wifi issues on 2 computers. Same as here, they are unable to connect to a wifi spot that they see, even when the link is very strong (with router very close for instance). Most of the time though, they manage to connect to the wifi I set up at startup! So my "new" method of connecting to a ESSID is configuring it with the Network Manager (but it will fail to connect), then reboot. Not very funny... :-/ Sometimes for some reason, even rebooting does not work (I'm think this is when the link is not strong enough). But yeah that makes me thin that's probably a race issue and when the computer boots only, the successful connection wins the race. One of the computer has a "Centrino Wireless-N 1000 [Condor Peak]", using iwlwifi. I don't have the other with me right now, so I can't say. I believe it was using ipw2200 though. In any case, that's a very very annoying bug.
CC: (none) => jehan.marmottard
Oh by the way, I tried "systemctl disable NetworkManager.service". I think it may have improved things, but as I said, connection was usually successful on reboot once configured once. So I won't be able to say for sure if it is better until I try to connect to a new ESSID I never configured.
What's the status of this bug? Can we mark it as a dupe of #6675 as blino suggested?
CC: (none) => mageia
I think it likely is a duplicate of that bug Colin. I haven't noticed it as bad as it was with mga3 but have fallen foul of it nevertheless. Closing this one. *** This bug has been marked as a duplicate of bug 6675 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE