starting from version 1.0.2 dbus can start services on-demand. To do so it needs to have .service file located in /usr/share/dbus-1/ wpa_supplicant ebuild doesn't create such service file which results it cannot be started from dbus. to fix it, ebuild needs to create a file /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service credit: steev@gentoo.org Reproducible: Always
Created attachment 145565 [details, diff] fi.epitest.hostap.WPASupplicant.service
Have you submitted this upstream?
The file is included in 0.5.10 of wpa_supplicant, we just don't install it (yet) - I am planning on adding this when I bump wpa_supplicant. I believe the filename is dbus-wpa_supplicant.service in the tarball (I haven't looked recently)
(In reply to comment #3) > The file is included in 0.5.10 of wpa_supplicant, we just don't install it > (yet) - I am planning on adding this when I bump wpa_supplicant. I believe the > filename is dbus-wpa_supplicant.service in the tarball (I haven't looked > recently) > yes. The file is included in tarball. I just updated my wpa_supplicant to 0.6.3 and noticed my wpa_supplicant doesn't start again. I had to grep Steev's repo to find what was it.
This should now be fixed with 0.5.10 - Please let me know if it doesn't - It might require changes to the wpa_supplicant.conf file.
This is now also fixed in =net-wireless/wpa_supplicant-0.6.4
Have a look at http://bugzilla.gnome.org/show_bug.cgi?id=560334 pls. The fix doesn't work here
I haven't bumped up to 0.7 myself - it does in fact work on 0.6.6 here - I am going to look at my machine and install 0.7 on a different machine and look at the differences - I am sorry I've been slacking so much lately.
(In reply to comment #7) > Have a look at http://bugzilla.gnome.org/show_bug.cgi?id=560334 pls. The fix > doesn't work here > Richard, I'm afraid it's a different bug in this case. It seems that NM is running the supplicant, but for some reason it dies on your machine (I've tested it on 5 different laptops with 3 different wireless cards and it works every time). Let's try to do it that way: 1) stop NetworkManager 1a) killall -9 nm-system-settings 2) killall -9 wpa_supplicant 3) edit /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service and change it, so it looks like: [D-BUS Service] Name=fi.epitest.hostap.WPASupplicant Exec=/usr/sbin/wpa_supplicant -dddt -u -f /var/log/wpa_supplicant.log User=root 4) reload dbus 5) run $ /usr/sbin/NetworkManager --no-daemon 6) post lots from NetworkManager and from /var/log/wpa_supplicant.log
Networkmanager don't start wpa_supplicant and nm-system-settings.conf too. There is no /var/log/wpa_supplicant.log an ps axu don't show nm-system-settings or wpa_supplicant running. # NetworkManager --no-daemon NetworkManager: <info> starting... net.lo | * status: started NetworkManager: <info> Found radio killswitch /org/freedesktop/Hal/devices/ipw_wlan_switch NetworkManager: <info> eth0: driver is '8139too'. NetworkManager: <info> Found new Ethernet device 'eth0'. NetworkManager: <info> (eth0): exported as /org/freedesktop/Hal/devices/net_00_0a_e4_a7_f9_e6 NetworkManager: <info> eth1: driver is 'ipw2200'. NetworkManager: <info> eth1: driver supports SSID scans (scan_capa 0x21). NetworkManager: <info> Found new 802.11 WiFi device 'eth1'. NetworkManager: <info> (eth1): exported as /org/freedesktop/Hal/devices/net_00_12_f0_15_d0_0c NetworkManager: <info> Trying to start the supplicant... NetworkManager: <info> Trying to start the system settings daemon... NetworkManager: <info> (eth0): device state change: 1 -> 2 NetworkManager: <info> (eth0): bringing up device. NetworkManager: <info> (eth0): preparing device. NetworkManager: <info> (eth0): deactivating device (reason: 2). NetworkManager: <info> Setting system hostname to 'localhost.localdomain' (no default device) NetworkManager: <info> (eth1): device state change: 1 -> 2 NetworkManager: <info> (eth1): bringing up device. NetworkManager: <info> (eth1): preparing device. NetworkManager: <info> (eth1): deactivating device (reason: 2). NetworkManager: supplicant_interface_acquire: assertion `mgr_state == NM_SUPPLICANT_MANAGER_STATE_IDLE' failed NetworkManager: <info> (eth0): carrier now ON (device state 2) NetworkManager: <info> (eth0): device state change: 2 -> 3 NetworkManager: <info> Activation (eth0) starting connection 'Netwerk' NetworkManager: <info> (eth0): device state change: 3 -> 4 NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started... NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete. NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting... NetworkManager: <info> (eth0): device state change: 4 -> 5 NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful. NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled. NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete. NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started... NetworkManager: <info> (eth0): device state change: 5 -> 7 NetworkManager: <info> Activation (eth0) Beginning DHCP transaction. NetworkManager: <info> dhcpcd started with pid 5106 NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. NetworkManager: <info> (eth0): carrier now OFF (device state 7) NetworkManager: <info> (eth0): device state change: 7 -> 2 NetworkManager: <info> (eth0): deactivating device (reason: 40). NetworkManager: <info> eth0: canceled DHCP transaction, dhcp client pid 5106
Please, reopen, because I can't make it work either (with same assertion failure)
(In reply to comment #11) > Please, reopen, because I can't make it work either (with same assertion > failure) > Sorry, it was a problem with nasty LDFLAGS (--as-needed possibly), I didn't realize I had them enabled in /etc/make.conf Recompiled dbus, hal, networkmanager and wpa_supplicant without LDFLAGS solved the issue, sorry
as-needed should not be breaking any of this, it works fine for me. Which other LDFLAGS do you have enabled?
I had O1, as-needed and sort-common. I disabled all of them and recompiled the whole world. It worked since then
(In reply to comment #14) > I had O1, as-needed and sort-common. I disabled all of them and recompiled the > whole world. It worked since then > As far as I'm aware none should affect. I've got pretty random CXX/LDFLAGS for normal user, but it works ok. I've seen the problem where dbus-1.2.2+ didn't start services automatically. Downdrading to 1.2.1, restarting and updating again was fixing it.
(In reply to comment #15) > (In reply to comment #14) > > I had O1, as-needed and sort-common. I disabled all of them and recompiled the > > whole world. It worked since then > > > > As far as I'm aware none should affect. I've got pretty random CXX/LDFLAGS for > normal user, but it works ok. > > I've seen the problem where dbus-1.2.2+ didn't start services automatically. > Downdrading to 1.2.1, restarting and updating again was fixing it. > In my case, setting LDFLAGS="" in make.conf and recompiling dbus,hal,wpa_supplicant and networkmanager solved the issue without downgrading
No LDFLAG in make.conf but i ran into similar issue. The wpa_supplicant started only once, when NM starts, but this needs i overwrite the wpa_supplicant's path in /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service to a non-symlinked version (/usr/sbin/wpa_supplicant). Nothing can gather network list, dhclient doesn't starts (even if i start dhcdbd), but wpa_supplicant sets up the wlan0 interface to the nearest AP. I tried run hald with verbose, but no more relevant info. I cannot guess, what a heck happened. I can test anything, so notify me if some tests needed Versions: [ebuild R ] sys-apps/dbus-1.2.3-r1 USE="X -debug -doc (-selinux)" 1,528 kB [ebuild R ] net-misc/dhcp-3.1.1 USE="-doc -minimal (-selinux) -static" 780 kB [ebuild R ] net-misc/dhcdbd-3.0 USE="-debug" 56 kB [ebuild R ] net-wireless/wpa_supplicant-0.6.4 USE="dbus gnutls readline ssl -debug -gsm -madwifi -ps3 -qt3 -qt4" 0 kB [ebuild R ] sys-apps/hal-0.5.11-r8 USE="X acpi crypt laptop -apm -debug -dell -disk-partition -doc (-selinux)" 0 kB [ebuild R ] app-misc/hal-info-20090202 0 kB [ebuild R ] net-misc/networkmanager-0.7.0 USE="dhclient -dhcpcd -doc -gnutls -nss -resolvconf" 0 kB Log snippet: Feb 28 09:02:55 omicron sudo: pam_unix(sudo:session): session closed for user root Feb 28 09:02:55 omicron NetworkManager: <info> Trying to start the supplicant... Feb 28 09:02:55 omicron NetworkManager: <info> Trying to start the system settings daemon... Feb 28 09:04:55 omicron NetworkManager: <info> Trying to start the supplicant... Feb 28 09:04:55 omicron NetworkManager: <info> Trying to start the system settings daemon... Feb 28 09:06:55 omicron NetworkManager: <info> Trying to start the supplicant... Feb 28 09:06:55 omicron NetworkManager: <info> Trying to start the system settings daemon... Feb 28 09:08:55 omicron NetworkManager: <info> Trying to start the supplicant... Feb 28 09:08:55 omicron NetworkManager: <info> Trying to start the system settings daemon... Feb 28 09:10:01 omicron cron[8196]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
ohh... i forgotten: wpa_supplicant exits after nm starts it once (after w_s set wlan0 correctly), but no segfault here, just exits.
(In reply to comment #17) > No LDFLAG in make.conf but i ran into similar issue. The wpa_supplicant started > only once, when NM starts, but this needs i overwrite the wpa_supplicant's path > in /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service to > a non-symlinked version (/usr/sbin/wpa_supplicant). > > Nothing can gather network list, dhclient doesn't starts (even if i start > dhcdbd), but wpa_supplicant sets up the wlan0 interface to the nearest AP. > > I tried run hald with verbose, but no more relevant info. I cannot guess, what > a heck happened. > > I can test anything, so notify me if some tests needed > > Versions: > [ebuild R ] sys-apps/dbus-1.2.3-r1 USE="X -debug -doc (-selinux)" 1,528 kB > [ebuild R ] net-misc/dhcp-3.1.1 USE="-doc -minimal (-selinux) -static" 780 > kB > [ebuild R ] net-misc/dhcdbd-3.0 USE="-debug" 56 kB > [ebuild R ] net-wireless/wpa_supplicant-0.6.4 USE="dbus gnutls readline > ssl -debug -gsm -madwifi -ps3 -qt3 -qt4" 0 kB > [ebuild R ] sys-apps/hal-0.5.11-r8 USE="X acpi crypt laptop -apm -debug > -dell -disk-partition -doc (-selinux)" 0 kB > [ebuild R ] app-misc/hal-info-20090202 0 kB > [ebuild R ] net-misc/networkmanager-0.7.0 USE="dhclient -dhcpcd -doc > -gnutls -nss -resolvconf" 0 kB > Networkmanager needs working dbus service activation in order to work correctly. From attached log I can see, that networkmanger can't activate either wpa_supplicant or nm-system-settings. Have you tried restarting dbus after NM installation?
I was able to get my NM working too by setting LDFLAGS="" in my paludis' config. The original was "-Wl,-O1". We should probably open another bug for this...
I experienced this issue (which seems to be the same as bug #263705) and use LDFLAGS="-Wl,-O1,--as-needed,--hash-style=gnu,--sort-common". Note that this was on a freshly installed 64 bit system with gcc 4.4 and glibc 2.10. Rebuilding dbus without changing my LDFLAGS fixed it. So it is definitely weird. Denis.
I've verified that dbus built with --as-needed doesn't do activation. Just rebuilding dbus (1.2.12 here) and restarting it was enough to fix this.
I can confirm #22 rebuilding dbus with LDFLAGS="" solves the prob. I have been updating from 0.6.6 to 0.7.1 when the problem occured.
Tested on amd64, x86 - two different computers. Recompilation of dbus is required to gain WiFi scanning/connecting functionality. Without dbus recompilation seems to NM is unable run wpa_supplicant. I propose add warning after install NM, there is probably needed recompile dbus.
(In reply to comment #24) > Tested on amd64, x86 - two different computers. Recompilation of dbus is > required to gain WiFi scanning/connecting functionality. Without dbus > recompilation seems to NM is unable run wpa_supplicant. I propose add warning > after install NM, there is probably needed recompile dbus. > I second that. Just installed Gentoo fresh last weekend and couldn't get networkmanager to start properly. Saw this thread, re-emerged dbus and the world is gravy again. Didn't have to change any LDFLAGS or anything, just re-emerged and all was good.
I also had dbus/wpa_supplicant issues on a new ~amd64 system. Re-emerging dbus solved the issues.
thank you, re-emerging dbus solved it. (note to myself: re-emerge dbus after emerging any package that depends on it.)
I can confirm this bug as well. I made a tarball of my root directory on an external disk with the following exclusion file: .bash_history /etc/mtab /media/disk/* /mnt/*/* /proc/* /sys/* /tmp/* /var/tmp/binpkgs/* /var/tmp/kdecache* /var/tmp/portage/* Then I repartitioned my hard drive, reformatted and restored the tarball. KNetworkManager could not detect any wireless networks. Some troubleshooting with "NetworkManager --no-daemon" revealed that it was hanging when trying to start "the supplicant". Some troubleshooting into wpa_supplicant revealed that it wanted /etc/wpa_supplicant/wpa_supplicant.conf, so I ran "touch /etc/wpa_supplicant/wpa_supplicant.conf" to make supplicant happy, but NetworkManager was still hanging when trying to start supplicant. To make things work, I had to run "wpa_supplicant -B -u" and then NetworkManager magically unhung and started working normally. I had to do this every boot. Eventually, I modified /etc/conf.d/wpa_supplicant to instruct the wpa_supplicant daemon to start with those flags and then I was able to run "/etc/init.d/wpa_supplicant start" to make things work. I later tried doing "rc-update add wpa_supplicant default" to get the rc scripts to start it automatically for me, but then at boot, wpa_supplicant failed to start. When I had a terminal, I could run "/etc/init.d/wpa_supplicant start" and it would start without an error, but the init scripts would not start it without an error. It was at this point that I ran across this bug. I ran "emerge -1v dbus" and rebooted (because I am lazy). Things magically started working like they had in the past. I reverted the other changes I had made while troubleshooting and things still worked. I have a bit of documentation regarding my troubleshooting in the following thread at the Gentoo forums, but I think I am posting a more complete summary of things in this comment. I am providing a link in case it is of any help to anyone, although I do not see how it would be: http://forums.gentoo.org/viewtopic-p-6288653.html I think that this issue is timestamp related, because the only meaningful difference between my disk before I repartitioned it and after I repartitioned it was that the timestamps had changed because I passed the -m flag to tar. If someone can write a script to get a list of all of the timestamps of the files provided by "equery files dbus" on a a system with this problem and then get a list of the timestamps of the same files from the same system after dbus is re-emerged, it should be possible to work out exactly what timestamp was causing the issue, at which point, we could work backwards to figure out why it was significant, perhaps in conjunction with upstream.
Not sure this bug should be 'trivial' any longer it at least is a blocker for NM and connman when using the dbus interfaces. source: http://wireless.kernel.org/en/users/Documentation/wpa_supplicant "The wpa_supplicant service file is typically available on systems in the following location: /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service This service file typically looks like this: [D-BUS Service] Name=fi.epitest.hostap.WPASupplicant Exec=/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log User=root Change it as follows to enable usage of wpa_cli or wpa_gui and also to use nl80211 when available: [D-BUS Service] Name=fi.epitest.hostap.WPASupplicant Exec=/sbin/wpa_supplicant -u -onl80211 -O/var/run/wpa_supplicant User=root If you are compiling the supplicant you will want CONFIG_CTRL_IFACE_DBUS=y to enable -u, CONFIG_DRIVER_NL80211=y for -onl80211 and CONFIG_CTRL_IFACE=y for the control interface. To enable usage of wpa_cli you will also want CONFIG_READLINE=y. Also enable CONFIG_DEBUG_FILE=y for the debug file. " Now looking at that file there the driver would need to be 'nl80211' I have that much working here as I no longer have -Dwext in wpa_supplicant.conf random connman # cat /etc/conf.d/net | grep supplicant modules=( "wpa_supplicant" ) echo "Loading driver as: -Dnl80211 and loading wpa_supplicant.conf" wpa_supplicant_wlan0="-d -u -Dnl80211 -c /etc/wpa_supplicant/wpa_supplicant.conf -d" Not sure '-u' is needed in conf.d/net though But connection works fine since I changed over. iirc connman-0.72 would work if I add the correct routing tables and /etc/resolv.conf but blow away the working ones and doesn't use the nameservers provided by the dhcp server when it actually did call the start script properly
adding CC and noting I use p54pci and ath9k_htc
this WORKSFORME
Original problem looks to be fixed for a long time, later other different bugs appeared. If still valid with fully updated system, please open a new bug report as this is now a mess