WLAN WPA2 configuration ignored
I think someone mentioned similar stuff recently. Among snapshot upgrades, I noticed that a WLAN configured like below is OPEN. Did no changes to it for ages, and trying to do any changes there was completely futile, even across reboots. Had to totally remove the interface, assign again and reconfigure. The "broken" (NFC what's broken there] config snippet below:
<opt2><if>ath0</if> <wireless><standard>11g</standard> <mode>hostap</mode> <protmode>off</protmode> <ssid>OFFICE-WLAN</ssid> <channel>0</channel> <authmode></authmode> <txpower>30</txpower> <distance><regdomain><regcountry>CZ</regcountry> <reglocation>indoor</reglocation> <wpa><macaddr_acl></macaddr_acl> <auth_algs>1</auth_algs> <wpa_mode>2</wpa_mode> <wpa_key_mgmt>WPA-PSK</wpa_key_mgmt> <wpa_pairwise>CCMP</wpa_pairwise> <wpa_group_rekey>120</wpa_group_rekey> <wpa_gmk_rekey>3600</wpa_gmk_rekey> <passphrase>s3cr3tp4ss</passphrase> <ext_wpa_sw></ext_wpa_sw> <ieee8021x><enable></enable></ieee8021x></wpa> <auth_server_addr><auth_server_port><auth_server_shared_secret><auth_server_addr2><auth_server_port2><auth_server_shared_secret2><wme><enable></enable></wme> <pureg><enable></enable></pureg> <apbridge><enable></enable></apbridge></auth_server_shared_secret2></auth_server_port2></auth_server_addr2></auth_server_shared_secret></auth_server_port></auth_server_addr></regdomain></distance></wireless> <enable><spoofmac><ipaddr>192.168.88.1</ipaddr> <subnet>24</subnet> <ipaddrv6>2001:470:dead:beef:dead:beef:dead:beef</ipaddrv6> <subnetv6>64</subnetv6></spoofmac></enable></opt2>
Now, comparing that to the recreated, reconfigured and properly working interface, the only difference there seems to be a couple of "short" tags like <authmode>instead of <authmode></authmode>.
What's up here? :o ???</authmode>
I still have not seen that happen to me and I update my ALIX regularly (or I did, before it was kicked out of its case in favor of an APU board)
If you can replicate it, compare the ifconfig output for the wireless interface and the contents of /tmp/ath0_wlan0_setup.sh and /var/etc/hostapd_ath0_wlan0.conf (adjust to match your actual interface name)
Hmmm, yeah… reproducing it is the problem... :D Regarding the /tmp stuff, I can recall some syslog message about failing to delete /tmp/* apparently due to some syntax error, so that'd explain why this problem persisted even across reboots.
Was this NanoBSD or a full install? NanoBSD's /tmp is a RAM disk no way for that to persist across reboots.
I'm running a full install on my APU at the moment so if it's specific to NanoBSD I wouldn't see it right now.
This one was full install. NFC really…
If the config is practically identical (empty tags are the same if they are in either format) then it must have been something generated differently in the scripts I mentioned. I can't imagine what, but it's the most likely explanation. Would be interesting to see if the other files were different and maybe check if there were any errors in the wireless log tab
Michael Sh. last edited by
Maybe because "ieee8021x=1" always in /var/etc/hostapd_ath0_wlan0.conf now?
eri-- last edited by
thanks that was it.
Fixed on 2.1.1