|Summary:||initscripts-9.51-1 doesn't bring up wlan0|
|Product:||[Fedora] Fedora||Reporter:||Henrique Martins <fedora>|
|Component:||initscripts||Assignee:||Pavel Šimerda (pavlix) <psimerda>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||20||CC:||dcbw, fedora, jonathan, lnykryn, mkovarik, psimerda, vpavlin|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-01-24 11:54:56 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Henrique Martins 2014-01-22 14:33:10 UTC
Description of problem: After updating initscripts fom initscripts-9.50-1.fc20.x86_64 to initscripts-9.51-1.fc20.x86_64 my wireless doesn't start. Downgrading with yum and it works. Version-Release number of selected component (if applicable): initscripts-9.51-1.fc20.x86_64 How reproducible: Always. Steps to Reproduce: 1. Power up computer Actual results: No wlan0 in the output of ifconfig. ifup wlan0 doesn't work. Expected results: Working wlan0 Additional info: I have NetworkManager disabled, use network instead. I disabled the renaming of wlan0 to whatever it was via udev. Comparing the output of systemctl before and after and it seems like dhclient is not being called. A dhclient -4 wlan0 brings the network up, but after that ifdown/ifup will fail (I need to double check this, but that's my recollection) and I need to kill/restart dhclient to get it going again.
Comment 1 Lukáš Nykrýn 2014-01-22 14:45:51 UTC
Can you post here your ifcfg?
Comment 2 Henrique Martins 2014-01-22 15:10:09 UTC
ifcfg-eth0 BOOTPROTO=dhcp DEFROUTE=yes DEVICE=eth0 DHCP_HOSTNAME=XXXXXX HWADDR=XX:XX:XX:XX:XX:XX IPV4_FAILURE_FATAL=yes IPV6INIT=no NM_CONTROLLED=no ONBOOT=yes PEERDNS=yes PEERROUTES=yes TYPE=Ethernet ifcfg-wlan0: BOOTPROTO=dhcp DEFROUTE=yes DEVICE=wlan0 DHCP_HOSTNAME=XXXXXX HWADDR=XX:XX:XX:XX:XX:XX IPV4_FAILURE_FATAL=no IPV6INIT=no NM_CONTROLLED=no ONBOOT=yes PEERDNS=yes PEERROUTES=yes TYPE=Wireless And now that I look at it again for the first time in a long while, I will change IPV4_FAILURE_FATAL to no for eth0 ..
Comment 3 Henrique Martins 2014-01-23 02:01:25 UTC
From a cursory comparison of the files on both versions of initscripts, I'd bet that the new, much shorter, /etc/sysconfig/network-scripts/ifup-wireless, is the culprit here. If I run the old version with 'set -x' it does a bunch of things,like /sbin/ip link set dev wlan0 up iwconfig wlan0 key off iwconfig wlan0 essid any etc, and then calls dhclient. The new ifup-wireless, does absolutely nothing and exits, like it expecting that environment variables, MODE, ESSID, DEVICE, and others, are set somewhere else but aren't.
Comment 4 Pavel Šimerda (pavlix) 2014-01-23 11:35:58 UTC
(In reply to Henrique Martins from comment #3) > From a cursory comparison of the files on both versions of initscripts, I'd > bet that the new, much shorter, > /etc/sysconfig/network-scripts/ifup-wireless, is the culprit here. The new 'ifup-wireless' script was created to keep up with the current status of kernel and userspace wireless networking implementation. The 'iw' command has different capabilities and the 'ifup-wireless' is there to continue supporting the very basic setups. For unencripted wireless connection, you need to set DEVICE, MODE and ESSID. The problem is that in your setup you don't have the MODE and ESSID set. The old version of the script performed the commands you noted below, without setting the wireless mode. I think that is a surprising and possibly wrong behavior, as it doesn't configure the device properly. Was your configuration written by hand or generated by some sort of tool? We could possibly default MODE to Managed (which wasn't the case even with the old script) but we can't accept a configuration without ESSID, as 'iw' apparently doesn't support connecting to a random essid. For your configuration, you just need to add: MODE=Managed ESSID=your-essid > If I run the old version with 'set -x' it does a bunch of things,like > /sbin/ip link set dev wlan0 up > iwconfig wlan0 key off > iwconfig wlan0 essid any > etc, and then calls dhclient. Are you sure about that? Where did the 'wlan0' value come from? See my result (shortened, F18 machine): # bash -x /etc/sysconfig/network-scripts/ifup-wireless + /sbin/ip link set dev up Cannot find device "up" + iwconfig key off iwconfig: unknown command "off" + iwconfig essid any You probably set the DEVICE variable yourself for testing purposes: # DEVICE=some-device-name bash -x /etc/sysconfig/network-scripts/ifup-wireless + /sbin/ip link set dev some-device-name up Cannot find device "some-device-name" + iwconfig some-device-name key off Error for wireless request "Set Encode" (8B2A) : SET failed on device some-device-name ; No such device. + iwconfig some-device-name essid any > The new ifup-wireless, does absolutely nothing and exits, like it expecting > that environment variables, MODE, ESSID, DEVICE, and others, are set > somewhere else but aren't. Of course they aren't. The script is called by ifup/ifdown with variables from one of your connection configurations. If you want to test it directly, you have to supply the variables yourself. This was the case with the former script as well, the only difference is that it didn't enforce the MODE and ESSID requirement. DEVICE=some-device MODE=Managed ESSID=some-essid bash -x /etc/sysconfig/network-scripts/ifup-wireless Does it work for you now?
Comment 5 Henrique Martins 2014-01-23 14:18:47 UTC
My ifcfg files were initially written by anaconda or whatever existed before anaconda, several Fedora versions back (maybe even RH), before NM existed, as part of the network service configuration. They may have been written on another system and "copied" to this one, but I didn't write the original versions by hand, or at least not completely. I don't run ifup-wireless directly, I simply do 'ifdown wlan0', 'ifup wlan0', and thus DEVICE is set to $1=wlan0 and sent over to ifup-wireless by ifdown/ifup. I have entries for all the unencripted wireless connections that I use on wpa_supplicant.conf. Whenever I go from within range of one or another, I run ifdown wlan0, then ifup wlan0, and, with the previous initscripts, I'm connected. With the most recent initscripts it doesn't work. For new unencripted (or encripted for that matter) wireless connections, I add an entry to wpa_supplicant.conf, restart that service, and then an ifdown/ifup connects me (though sometimes I also need to restart the network service.) With the previous initscripts I don't need to add MODE and ESSID to the ifcfg files, not sure why I do now. I do understand that NM may or may not do all that for me, let's not argue that here.
Comment 6 Henrique Martins 2014-01-23 14:35:47 UTC
Created attachment 854419 [details] output of ifup Added set -x to some scripts, output attached. Seems like MODE is never set and that ESSID is set to any iwconfig wlan0 essid any So maybe if I'm within range of more than one AP I'm randomly connected?, but it seems to work in most cases.
Comment 7 Henrique Martins 2014-01-23 14:58:32 UTC
With the new initscripts, adding MODE=managed ESSID=any to ifcfg-wlan0 then issuing ifdown wlan0 ifup wlan0 connects fine, though ifdown outputs this error message command failed: Network is down (-100) more on this below. Maybe I can also take the ESSID line out of there and do ESSID=<essid> ifdown wlan0 if I want to select between two available APs? The error line is generated by this ifup-wireless line iw dev wlan0 connect -w any whether essid is any or a specfic essid, but somehow it still connects me?
Comment 8 Michal Kovarik 2014-01-23 19:21:26 UTC
hi, I have similar issue, I use my device with fedora as AP with hostapd. My ifcfg-wlp3s0 (just for ip addr setting, wifi itself is configured by hostapd): DEVICE=wlp3s0 ONBOOT=yes NM_CONTOROLLED=no BOOTPROTO=static IPADDR=10.10.0.1 NETMASK=255.0.0.0 This configuration has stopped working after update to initscripts-9.51-1.
Comment 9 Pavel Šimerda (pavlix) 2014-01-24 11:35:07 UTC
(In reply to Michal Kovarik from comment #8) > hi, I have similar issue, I use my device with fedora as AP with hostapd. Hi, AP mode is not supported by 'iw' and therefore is no longer supported by initscripts that use 'iw'. You can either remove NM_CONTROLLED=no and let Networkmanager handle it via wpa_supplicant's hotspot feature or you can configure hostapd/wpa_supplicant directly.
Comment 10 Pavel Šimerda (pavlix) 2014-01-24 11:54:56 UTC
(In reply to Henrique Martins from comment #5) > I have entries for all the unencripted wireless connections that I use on > wpa_supplicant.conf. wpa_supplicant and initscripts are (and were) AFAIK two distinct solutions for wireless connectivity. If you have your wpa_supplicant.conf set up, you shouldn't need to have wifi configuration in /etc/sysconfig. > Whenever I go from within range of one or another, I > run ifdown wlan0, then ifup wlan0, and, with the previous initscripts, I'm > connected. With the most recent initscripts it doesn't work. wpa_supplicant can AFAIK handle (auto)connection for you. > For new unencripted (or encripted for that matter) wireless connections, I > add an entry to wpa_supplicant.conf, restart that service, and then an > ifdown/ifup connects me (though sometimes I also need to restart the network > service.) It sounds like wpa_supplicant detects your changes and reacts on them. That sounds more like a side effect than intention. You should be able to talk to wpa_supplicant directly e.g. via wpa_cli. > With the previous initscripts I don't need to add MODE and ESSID to the > ifcfg files, not sure why I do now. When MODE wasn't specified, initscripts performed a bunch of commands without any real sense. When ESSID wasn't specified, it used the 'iwconfig' feature to connect to any essid which also doesn't make much sense and which is not supported with 'iw'. The new 'iw' tool uses the new kernel API which is supported by new wireless drivers. Fedora still includes the wireless-tools package featuring the 'iwconfig' for those who need to use the old API. The old API is also still supported by NetworkManager, wpa_supplicant and possibly other packages. We no longer want to use the 'iwconfig' in initscripts tool which supports *only* the old API. As you already noted, you are using wpa_supplicant. Talking to wpa_supplicant via initscripts wasn't supported and the hack you used is no longer available. Please use wpa_supplicant tools instead.
Comment 11 Pavel Šimerda (pavlix) 2014-01-24 11:57:11 UTC
Also please let me apologize for the inconvenience. It wouldn't be very practical to revert the change, now. Feel free to ask if something isn't clear.