(In reply to comment #0)
> /sbin/ifdown: interface wlan0 is controlled by NetworkManager; skipping.
> /sbin/ifup: interface wlan0 is controlled by NetworkManager; skipping.



If you want to use drakroam or draknetcenter then you have to configure it that way. Uncheck NM when you configure your network.

CC: (none) => sander.lepik

That's another problem I forgot to mention: I'm not using NetworkManager, and there seems to be a bug with the "Allow this interface to be controlled by NetworkManager" checkbox. It always appear checked and I never have checked it. If you uncheck it and quit drakroam then it will correctly set NM_CONTROLLED=no in the ifcfg-xxx file, but when you open again drakroam and open the configuration dialog for the interface, the NetworkManager checkbox will appear checked again and NM_CONTROLLED=yes on the config file.

I noticed that too. But you can open bugreport about it. I'm quite sure it would solve this one as well..

what is the real issue ?

(In reply to comment #3)
> I noticed that too. But you can open bugreport about it. I'm quite sure it
> would solve this one as well..

I'm not that sure because if I manually set NM_CONTROLLED=no in the wireless interface and then try to bring it up using ifup command it still will fail.

(In reply to comment #4)
> what is the real issue ?

There seem to be two different issues here:

1. For some reason /var/run/wpa_supplicant is being removed and thus the wireless connection can't be established by wpa_supplicant. 

2. drakroam has an issue reading/saving the "Allow this interface to be controlled by NetworkManager" checkbox. And I'm not sure this one affects the other issue.

I opened the issue for the first one but then commented about the second one, which could be related or not.

If /var/run is not yet linked to /run then it soon will be which means it will be tmpfs. So /var/run should be emty when system starts.

(In reply to comment #7)
> If /var/run is not yet linked to /run then it soon will be which means it will
> be tmpfs. So /var/run should be emty when system starts.

It still isn't /run exists but is empty whereas /var/run is not. In any case, whether /run or /var/run is used, the wpa_supplicant directory has to be created with the named pipes it needs to work in there, which is what isn't happening.

Is this the same as bug 2160 ?

CC: (none) => davidwhodgins

I don't think so, that one seems more to be a regression with the driver for RTL8192SE cards on kernel 3.1.x and networkmanager, which I don't even have installed:

[mageia@dci-laptop ~]$ rpm -qa|grep -i networkmanager
[mageia@dci-laptop ~]$ 

than a problem with wpa_supplicant which seems to be the problem here.

Also in my case booting with the old 2.6.38.7-desktop-1.mga kernel doesn't help.

This is what appears on /var/log/messages when doing an ifup wlan0 and NM_CONTROLLED=no for wlan0:

Nov 15 17:59:00 dci-laptop radvd[3184]: attempting to reread config file
Nov 15 17:59:00 dci-laptop radvd[3184]: no linklocal address configured for eth0
Nov 15 17:59:00 dci-laptop radvd[3184]: resuming normal operation
Nov 15 17:59:00 dci-laptop kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Nov 15 17:59:06 dci-laptop radvd[3184]: attempting to reread config file
Nov 15 17:59:06 dci-laptop radvd[3184]: no linklocal address configured for eth0
Nov 15 17:59:06 dci-laptop radvd[3184]: resuming normal operation

Since last days I got the wireless connection back but just at boot time. Trying to bring up the wireless interface with drakroam will produce the same result as described initially on this bug report. Also using ifup wlan0 doesn't work:

[root@dci-laptop mageia]# ifup wlan0
Wireless device wlan0 is configured with a roaming daemon but isn't associated

Determining IP information for wlan0... failed; no link present.  Check cable?


But using "ifup wlan0 boot" works albeit the error message:

[root@dci-laptop mageia]# ifup wlan0 boot
Error for wireless request "Set Encode" (8B2A) :
    SET failed on device wlan0 ; Invalid argument.

There was a bug in drakx-net that wrote NM_CONTROLLED=yes if the NM_CONTROLLED variable was present in ifcfg.
This is now fixed in drakx-net 1.0

There is now another bug when restarting the connection from drakroam or draknetcenter if NetworkManager is enabled.
It occurs at the moment the drakx-net tools overwrite the ifcfg file.
It seems NM detects that the ifcfg file is deleted, then puts the interface in MANAGED mode and starts its own wpa_supplicant. After a very short time, it detects that the ifcfg file is written back, puts the interface in UNMANAGED mode, but it seems it does not kill its wpa_supplicant.
Then conflicts occur between the two wpa_supplicant instances (one from drakx-net/initscripts, one from NM that should not be managing wlan0).

CC: (none) => mageia
Assignee: bugsquad => mageia

(In reply to comment #13)
> There is now another bug when restarting the connection from drakroam or
> draknetcenter if NetworkManager is enabled.
> It occurs at the moment the drakx-net tools overwrite the ifcfg file.
> It seems NM detects that the ifcfg file is deleted, then puts the interface in
> MANAGED mode and starts its own wpa_supplicant. After a very short time, it
> detects that the ifcfg file is written back, puts the interface in UNMANAGED
> mode, but it seems it does not kill its wpa_supplicant.
> Then conflicts occur between the two wpa_supplicant instances (one from
> drakx-net/initscripts, one from NM that should not be managing wlan0).

But that must be a different problem from this one as I don't have NetworkManager installed.

I'll test tomorrow with the new drakx-net to see if there's any difference.

Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.

CC: (none) => marja11

It still happens. This is the current output from draknetcenter on a terminal:

Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
Failed to create client object: Daemon not running
run-parts: /etc/sysconfig/network-scripts/hostname.d/avahi exited with return code 1
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
Failed to kill daemon. (No such file or directory)
Interface "wlan0" is already disabled.
Error for wireless request "Set Encode" (8B2A) :
    SET failed on device wlan0 ; Invalid argument.


The network doesn't come up using draknetcenter but it does using drakconnect or at boot.

I can confirm it, I faced it with Cauldron - I can't use Cauldron anymore because of this bug.

This should be a release blocker.

There are at least 2 major bugs: NM link against the drak application + wpa supplicant isn't working.

# lspci|grep Broadcom
04:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01)

CC: (none) => n54

I do have the 

"Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory" 

bug too, since installing Mga2b2, but not all the time. Other times there is no complaint but then I get 

"WPA 4-way handshake fails"

And after a lot of trying again I just was finally able to connect to my accespoint.

(It won't survive a reboot, however, because of bug 4557)

I don't have networkmanager installed. 

$ lspcidrake -v | grep ipw2200
ipw2200         : Intel Corporation|PRO/Wireless 2200BG [Calexico2] Network
Connection [NETWORK_OTHER] (vendor:8086 device:4220 subv:8086 subd:2712) (rev:
05)

(In reply to comment #18)
> I do have the 
> 
> "Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or
> directory" 
> 
> bug too, since installing Mga2b2, but not all the time. 

I saw nor this, nor my other wpa issue since over 36 hours ago. Either my wpa issues had a different cause, or this bug got solved.

Juan, can you test with new initscripts (9.34-12)?

Keywords: (none) => NEEDINFO

Trying with drakroam I still get these messages when connecting:


Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory                                                        
Failed to kill daemon. (No such file or directory)                                                                                    
Interface "wlan0" is already disabled.
Error for wireless request "Set Encode" (8B2A) :
    SET failed on device wlan0 ; Invalid argument.

But now network comes up, although drakroam doesn't refresh, thus still shows the wireless network as disconnected until I hit the Refresh button.

Do you have networkmanager enabled or not?

If yes then you probably get this error.

As I hae said multiple times on this report, I do NOT have networkmanager enabled.

OK, wifi is working now for me.
The problem is with some conflicts NM/wpa/drakconnect/etc - it can load two wpa_supplicant instances.

@ Juan Luis and others affected:

Is this bug still valid with Mageia 2 beta 3?

Sorry for the late reply:

Well it still shows the reported error messages but draknetcenter successfully connects, although after I see the popup notification with the new network configuration, the "Connecting..." dialog remains for some seconds, then it disappears as it couldn't connect to the network, and the connect/disconnect button remains in "Connect" instead of "Disconnect" as it should because the network was successfully connected.

Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
Failed to kill daemon. (No such file or directory)
Interface "wlan0" is already disabled.
Error for wireless request "Set Encode" (8B2A) :
    SET failed on device wlan0 ; Invalid argument.
got wireless event: <2>WPA: Key negotiation completed with c0:c1:c0:2e:08:10 [PTK=CCMP GTK=TKIP] wlan0
got wireless event: <2>CTRL-EVENT-CONNECTED - Connection to c0:c1:c0:2e:08:10 completed (auth) [id=0 id_str=] wlan0

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

*** Bug 5651 has been marked as a duplicate of this bug. ***

I understand, from doktor5000's list of most reported forum issues and from one forum thread I saw recently myself, that this bug is still valid in Mageia 2

Keywords: NEEDINFO => (none)
Whiteboard: (none) => MGA2TOO

Yes, this bug still happens in Mageia 2.

But the description is not quite correct. Even with the networkmanager packeges uninstalled Mga2 STILL spawns multiple wpa_supplicant processes.  This happens following

a. a suspend/resume
b. "service network restart"

This seems to be due to an error in /etc/wpa_supplicant.conf, which is generating
error messages

Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
which are written to stderr (NOT syslog) if drakroam is started from the command line.

There appears to be a workaround:  Adding

   ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

to /etc/wpa_supplicant.conf appears to fix the particular issue and allow reconnection.  With this addition, my wifi reconnects automatically and
apparently correctly following a suspend/resume or a "service network restart"

As comment #30 says, this bug has nothing to do exclusively with NM. I, as the original reporter have said several times in comments # 2,10,14 and 23, that I DO NOT have NM installed, so this issue exists without it. I do not understand why the subject was changed to reflect that.

(In reply to comment #31)
> As comment #30 says, this bug has nothing to do exclusively with NM. I, as the
> original reporter have said several times in comments # 2,10,14 and 23, that I
> DO NOT have NM installed, so this issue exists without it. I do not understand
> why the subject was changed to reflect that.

OK, you reported this bug, so changing the summary back to what it was.

(In reply to comment #30)

> There appears to be a workaround:  Adding
> 
>    ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
> 
> to /etc/wpa_supplicant.conf appears to fix the particular issue and allow
> reconnection.  With this addition, my wifi reconnects automatically and
> apparently correctly following a suspend/resume or a "service network restart"

Thx, Keith


@ blino,

This bug can't be used for NetworkManager conflicts with drakx-net anymore.

Is bug 2160 caused by that conflict?

Summary: NetworkManager spawns a wpa_supplicant instead even if interface is unmanaged, conflicting with drakx-net tools => Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory

I have opened bug 6675 about the wpa_supplicant + NetworkManager conflict.

Juan Luis, please quote the output of this command:
ps ax | grep wpa

Here it is:

[mageia@dci-laptop ~]$ ps ax | grep wpa
 2144 ?        S      0:06 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant.conf -u -P /var/run/wpa_supplicant.pid

Fixed for me with update wpa_supplicant-1.0-3.mga3

Is this bug still present in cauldron?

Keywords: (none) => NEEDINFO

I'm still experiencing this bug. I can only connect wirelessly on bootup. If after booting, I decide to disconnect from the access point and reconnect to the same one a few moments later, I get this from draknetcenter running from the terminal:

got wireless event: <3>CTRL-EVENT-TERMINATING - signal 15 received eth1
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
Failed to kill daemon. (No such file or directory)
Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1 ; Invalid argument.
Error for wireless request "Set Encode" (8B2A) :
    invalid argument "s:".

This results in the reconnection attempt failing. Still present as of MGA3RC. The only way I can connect to an access point is to configure the connection as usual, but when asked to start the connection, I must answer no otherwise it results in a failed connection. After answering no, I then reboot and end up with a system connected to desired access point.

My ifcfg-eth1 is:

[root@localhost network-scripts]# cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=dhcp
ONBOOT=yes
METRIC=35
MII_NOT_SUPPORTED=no
USERCTL=no
RESOLV_MODS=no
WIRELESS_MODE=Managed
WIRELESS_ESSID=UNR-WPA
WIRELESS_ENC_KEY=s:
WIRELESS_WPA_DRIVER=wext
WIRELESS_WPA_REASSOCIATE=no
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
DHCP_CLIENT=dhclient
NEEDHOSTNAME=no
PEERDNS=yes
PEERYP=yes
PEERNTPD=no

CC: (none) => philippe.l

Does anybody know if this affects the LiveCDs? If it does, it may prove complicated or difficult to connect to a wireless access point from a live session. In my experience, a reboot is needed to succesfully connect. In the context of a live session, a reboot means wiping the session clean which would make impossible to connect. Any thoughts?

Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as OLD.

Status: NEW => RESOLVED
CC: (none) => nic
Resolution: (none) => OLD