WLAN WPA2 configuration ignored

doktornotor

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>

jimp

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)

doktornotor

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.

jimp

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.

doktornotor

This one was full install. NFC really…

jimp

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.

Maybe because "ieee8021x=1" always in /var/etc/hostapd_ath0_wlan0.conf now?

eri--

Michael,

thanks that was it.
Fixed on 2.1.1