Hello, on my laptop (Asus U36sd) I had fedora 17 and configured hostapd setting bridge on virbr0 and using wpa2. Reinstalled in fedora 19 with same settings (only changed name of wlan interface) apparently this doesn't work with this same hw. I get: nl80211: Failed to set interface wlp3s0 into AP mode
wireless adapter: 03:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
I see that there is a WIFI hot spot function now on Network Manager (NetworkManager-0.9.8.2-8.git20130709.fc19.x86_64) but I read somewhere (article dated 2012) that it supports only wep, even if you could configure wpa.
Questions: 1) Any hint to have hostapd running in f19 or making further debug actions? It was useful to use it with libvirtd "default" network (manually created in f19 because not automatically defined as before) to automatically get routing and dns information.
2) Is still true that NM as shipped in Fedora 19 only supports wep?
Thanks in advance, Gianluca
On Tue, 16 Jul 2013 15:26:23 +0200 Gianluca Cecchi wrote:
- Any hint to have hostapd running in f19 or making further debug
actions?
I have been running hostapd successfully for a while going from f18 to f19, so I don't think anything fundamental changed, sounds like the new kernel drivers don't believe your adapter supports AP mode anymore.
Perhaps you need some firmware blob that didn't come with f19?
On Tue, Jul 16, 2013 at 3:26 PM, Gianluca Cecchi wrote:
Hello, on my laptop (Asus U36sd) I had fedora 17 and configured hostapd setting bridge on virbr0 and using wpa2. Reinstalled in fedora 19 with same settings (only changed name of wlan interface) apparently this doesn't work with this same hw. I get: nl80211: Failed to set interface wlp3s0 into AP mode
wireless adapter: 03:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
I see that there is a WIFI hot spot function now on Network Manager (NetworkManager-0.9.8.2-8.git20130709.fc19.x86_64) but I read somewhere (article dated 2012) that it supports only wep, even if you could configure wpa.
Questions:
- Any hint to have hostapd running in f19 or making further debug
actions? It was useful to use it with libvirtd "default" network (manually created in f19 because not automatically defined as before) to automatically get routing and dns information.
Possibly NetworkManager that keeps wpa_supplicant running could interfere and prevent hostapd to set AP mode?
[g.cecchi@ope46 ~]$ sudo systemctl status wpa_supplicant wpa_supplicant.service - WPA Supplicant daemon Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled) Active: active (running) since Tue 2013-07-16 09:18:38 CEST; 7h ago Main PID: 497 (wpa_supplicant) CGroup: name=systemd:/system/wpa_supplicant.service └─497 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplican...
Jul 16 09:18:38 ope46 systemd[1]: Starting WPA Supplicant daemon... Jul 16 09:18:38 ope46 systemd[1]: Started WPA Supplicant daemon.
[g.cecchi@ope46 ~]$ sudo systemctl stop wpa_supplicant
But as soon as I stop wpa, NetworkManager starts it again...
Jul 16 17:03:28 ope46 systemd[1]: Stopping WPA Supplicant daemon... Jul 16 17:03:28 ope46 systemd[1]: Stopped WPA Supplicant daemon. Jul 16 17:03:28 ope46 NetworkManager[438]: <info> wpa_supplicant stopped Jul 16 17:03:28 ope46 NetworkManager[438]: <info> (wlp3s0): supplicant interface state: disabled -> down Jul 16 17:03:28 ope46 NetworkManager[438]: <info> (wlp3s0): device state change: disconnected -> unavailable (reason 'supplicant-failed') [30 20 10] Jul 16 17:03:28 ope46 NetworkManager[438]: <info> (wlp3s0): deactivating device (reason 'supplicant-failed') [10] Jul 16 17:03:28 ope46 dbus-daemon[338]: dbus[338]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' Jul 16 17:03:28 ope46 dbus[338]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' Jul 16 17:03:28 ope46 systemd[1]: Starting WPA Supplicant daemon... Jul 16 17:03:28 ope46 dbus-daemon[338]: dbus[338]: [system] Successfully activated service 'fi.w1.wpa_supplicant1' Jul 16 17:03:28 ope46 dbus[338]: [system] Successfully activated service 'fi.w1.wpa_supplicant1' Jul 16 17:03:28 ope46 systemd[1]: Started WPA Supplicant daemon. Jul 16 17:03:28 ope46 NetworkManager[438]: <info> wpa_supplicant started Jul 16 17:03:28 ope46 kernel: [27885.321311] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready Jul 16 17:03:28 ope46 NetworkManager[438]: <info> (wlp3s0) supports 4 scan SSIDs Jul 16 17:03:28 ope46 NetworkManager[438]: <warn> Trying to remove a non-existant call id. Jul 16 17:03:28 ope46 NetworkManager[438]: <info> (wlp3s0) supports 4 scan SSIDs Jul 16 17:03:28 ope46 NetworkManager[438]: <info> (wlp3s0) supports 4 scan SSIDs Jul 16 17:03:28 ope46 NetworkManager[438]: <info> (wlp3s0): supplicant interface state: starting -> ready
In /lib/systemd/system/NetworkManager.service and /lib/systemd/system/wpa_supplicant.service I didn't find any option to prevent NM to keep wpa running... is it hardcoded? How to stop wpa and retry with hostapd?
Thanks Gianluca
Am 16.07.2013 17:14, schrieb Gianluca Cecchi:
Possibly NetworkManager that keeps wpa_supplicant running could interfere and prevent hostapd to set AP mode?
[g.cecchi@ope46 ~]$ sudo systemctl status wpa_supplicant wpa_supplicant.service - WPA Supplicant daemon Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled) Active: active (running) since Tue 2013-07-16 09:18:38 CEST; 7h ago Main PID: 497 (wpa_supplicant) CGroup: name=systemd:/system/wpa_supplicant.service └─497 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplican...t
But as soon as I stop wpa, NetworkManager starts it again...
I didn't find any option to prevent NM to keep wpa running... is it hardcoded? How to stop wpa and retry with hostapd?
* a) file a bug for NM * b) systemctl mask wpa_supplicant.service
or switch to classic network.service for static configured machines and disable the complete NM crap - hence you can even use "BOOTPROTO=dhcp" in "ifcfg-XX"-files
On Tue, Jul 16, 2013 at 5:18 PM, Reindl Harald wrote:
Am 16.07.2013 17:14, schrieb Gianluca Cecchi:
Possibly NetworkManager that keeps wpa_supplicant running could interfere and prevent hostapd to set AP mode?
[g.cecchi@ope46 ~]$ sudo systemctl status wpa_supplicant wpa_supplicant.service - WPA Supplicant daemon Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled) Active: active (running) since Tue 2013-07-16 09:18:38 CEST; 7h ago Main PID: 497 (wpa_supplicant) CGroup: name=systemd:/system/wpa_supplicant.service └─497 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplican...t
But as soon as I stop wpa, NetworkManager starts it again...
I didn't find any option to prevent NM to keep wpa running... is it hardcoded? How to stop wpa and retry with hostapd?
- a) file a bug for NM
- b) systemctl mask wpa_supplicant.service
or switch to classic network.service for static configured machines and disable the complete NM crap - hence you can even use "BOOTPROTO=dhcp" in "ifcfg-XX"-files
OK. I verified that masking and stopping wpa service I can start successfully hostapd.
[g.cecchi@ope46 ~]$ sudo systemctl status hostapd hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator Loaded: loaded (/usr/lib/systemd/system/hostapd.service; disabled) Active: active (running) since Tue 2013-07-16 17:23:54 CEST; 2min 45s ago Process: 10313 ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B (code=exited, status=0/SUCCESS) Main PID: 10314 (hostapd) CGroup: name=systemd:/system/hostapd.service └─10314 /usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B
Jul 16 17:23:54 ope46 systemd[1]: Starting Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator... Jul 16 17:23:54 ope46 systemd[1]: Started Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator. Jul 16 17:24:46 ope46 hostapd[10314]: wlp3s0: STA c8:60:00:12:1f:97 IEEE 802.11: authenticated Jul 16 17:24:46 ope46 hostapd[10314]: wlp3s0: STA c8:60:00:12:1f:97 IEEE 802.11: associated (aid 1) Jul 16 17:24:46 ope46 hostapd[10314]: wlp3s0: STA c8:60:00:12:1f:97 RADIUS: starting accounting session 51E5658A-00000000 Jul 16 17:24:46 ope46.ceda.polimi.it hostapd[10314]: wlp3s0: STA c8:60:00:12:1f:97 WPA: pairwise key handshake completed (RSN)
And I can successfully connect and web surf from a client.
Thanks!
But I begin to continuously get this in messages:
Jul 16 17:25:04 ope46 NetworkManager[438]: <error> [1373988304.394443] [nm-supplicant-interface.c:997] interface_add_cb(): (wlp3s0): error adding interface: Unit wpa_supplicant.service is masked. Jul 16 17:25:04 ope46 NetworkManager[438]: dbus_g_proxy_cancel_call: assertion `pending != NULL' failed Jul 16 17:25:04 ope46 NetworkManager[438]: <info> (wlp3s0): supplicant interface state: starting -> down Jul 16 17:25:04 ope46 NetworkManager[438]: <warn> Trying to remove a non-existant call id. Jul 16 17:25:04 ope46 dbus[338]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' Jul 16 17:25:04 ope46 dbus[338]: [system] Activation via systemd failed for unit 'wpa_supplicant.service': Unit wpa_supplicant.service is masked.
power of my ssd based laptop I have all the system for NetworkManager and systemd-journal ;-)
top - 17:30:51 up 8:12, 7 users, load average: 3.43, 2.57, 1.31 Tasks: 179 total, 5 running, 174 sleeping, 0 stopped, 0 zombie %Cpu(s): 42.3 us, 31.6 sy, 0.0 ni, 25.4 id, 0.0 wa, 0.4 hi, 0.3 si, 0.0 st KiB Mem: 8079764 total, 5558996 used, 2520768 free, 421748 buffers KiB Swap: 10485756 total, 0 used, 10485756 free, 3435816 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 179 root 20 0 1528444 15940 15512 R 97.8 0.2 7:09.69 systemd-journal 438 root 20 0 364916 8108 6332 R 63.2 0.1 4:31.12 NetworkManager ..
In a few minutes messages grew to 1.5Gb... [g.cecchi@ope46 ~]$ ll /var/log/messages -rw------- 1 root root 1497861349 Jul 16 17:32 /var/log/messages
So in the mean time I unmasked again wpa_supplicant... Opened bug: https://bugzilla.redhat.com/show_bug.cgi?id=985041
Gianluca