Netgate w/ pfSense 2.0, EnGenius 8602+S no WPA/WPA2?
-
If anyone can help me get past my current wireless issue, I'd appreciate it.
The problem:
After switching the CF card used in my nanobsd pfSense firewall from a functioning pfSense 1.2.3 CF card to a new pfSense 2.0 CF card, it appears everything I can test works… except WPA and WPA2 wireless encryption, with either AES or TKIP, and whether or not glxsb is checked in Advanced->Misc or not. WEP and Open authentication function fine, however.Symptom:
Windows, upon a WPA authentication attempt, merely says "Windows was unable to connect to <ssid>".
pfSense System Log merely shows the client associates and them immediately disassociates, without a given reason.Additional information: Cloning the interface and assigning the clone doesn't change anything. ifconfig shows the device is running, and on a Windows client, inSSIDer shows a good, strong broadcast with the correct encryption type. Switching channels and bands between 802.11g and 802.11a has no effect (both worked fine on 1.2.3). I've changed SSID and passphrase both - still no difference, even with a numeric only passphrase. Open and WEP work, WPA and WPA2 do not.
I've reset to Factory Default and loaded my 1.2.3 backup with packages, same result (and oddly two broken OpenVPN links under "Status").
I've reset to Factory Default and loaded my 1.2.3 backup without packages, same result (and oddly no OpenVPN interface set up, but the firewall rules remain).
I've reset to Factory Default and set up a wireless interface without loading any backup at all, same result.
Hardware:
Netgate m1n1wall ALIX 2D2
EnGenius EMP8602+S (Atheros AR5006, or AR5006X, AR5413, per Netgate or Wikidevi respectively)BIOS:
dmesg | grep -i bios
shows I have BIOS 0.99hOS:
The CF card was purchased from Netgate with their own install of pfSense preloaded. It took me throughWhat other information can I provide that would be useful?</ssid>
-
Some suggestions:
-
Check your WPA2 encryption key is exactly the same on pfSense and Windows. Be especially careful about leading and trailing spaces.
-
Boot your Windows system to a Linux live CD and see if the same hardware and different software gives different outcomes. Be prepared to play with the encryption options. I did a Linux update some time ago that broke WPA2/TKIP on my netbook but WPA2/AES still worked. I just locked pfSense to WPA2/AES. The Windows systems didn't care (though I can't recall if they needed a reboot)
-
Check your Windows system has the most up to date wireless drivers. Newer is often, but not always, better.
-
-
Thank you for your suggestions.
-
Three test setups had all been working 45 minutes earlier when the Netgate had pfSense 1.2.3 on it. I actually did a brief test with one Windows Vista laptop and an Intel 3945 card, and then extensive testing with a Windows 7 laptop using both an Intel 6200 and an Alfa AWUS051NH.
-
During the pfSense restore testing, the key appeared to be correctly restored, and did not work (it had not been changed on the laptops. I also tried two other keys, neither with leading or trailing spaces or any nonprintable characters, either on the pfSense or on the laptop.
1.5) Does anyone know where in the pfSense file system the WPA(2) key is stored? One of my suspicions is that it's not saving quite what I'm typing in.
-
I've tried two Windows OS's and three wireless NICs, all of which had been working fine 45 minutes prior with pfSense 1.2.3.
-
I'd updated the Alfa AWUS051NH drivers only a few hours before with the drivers off the site, which claimed to uninstall a previous version. The Win7 Intel drivers had been updated from the version on Intel's site a few months ago. The Windows Vista drivers were older, perhaps a year and a half or more.
-
-
1.5) Does anyone know where in the pfSense file system the WPA(2) key is stored?
In the master configuration file: /conf/config.xml Here's what the appropriate section (ssid and passphrase blanked out) of my configuration file looks like (see the passphrase section):
<opt2><if>ath0</if> <wireless><standard>11g</standard> <mode>hostap</mode> <protmode>off</protmode> <ssid>...</ssid> <channel>0</channel> <authmode><txpower>99</txpower> <distance><regdomain><regcountry>AU</regcountry> <reglocation><wpa><macaddr_acl><auth_algs>2</auth_algs> <wpa_mode>2</wpa_mode> <wpa_key_mgmt>WPA-PSK</wpa_key_mgmt> <wpa_pairwise>CCMP</wpa_pairwise> <wpa_group_rekey>60</wpa_group_rekey> <wpa_gmk_rekey>3600</wpa_gmk_rekey> <passphrase>***</passphrase> <ext_wpa_sw></ext_wpa_sw></macaddr_acl></wpa></reglocation></regdomain></distance></authmode></wireless></opt2>
Do all your WPA parameters match?
-
Thank you, wallabybob, for the excellent snippet.
I've reset to defaults again, and tried:
Open works
Shared WEP works
WPA2 does not.I used the Edit File diagnostic option to look at /conf/config.xml; the passwords (13 characters, just for testing) are precise, with no spaces at all (as expected).
Differences, apart from SSID and password:
I don't have any regulatory domain set (I choose channel 48 deliberately; 5Ghz isn't common around here)
auth_algs on mine was 1, and yours was 2. Using Edit File to save a 2 instead of a 1 in that field had no effect.Further analysis of my system log shows some oddities:
Lots of
siproxd[62468]: register.c:149 ERROR: unable to write registration fileseveral:
dhclient: FAIL
Note the DHCP log doesn't show this, just the system log.A few:
apinger: Exiting on signal 15
apinger: Error while feeding rrdtool: Broken pipe -
I've also ruled out the m1n1wall wireless NIC at this point, and proved the Windows 7 client can connect to pfSense 2.0 WLAN access points with WPA2:
I loaded up a VMWare pfSense 2.0 VM I've been playing with, and assigned it my Alfa AWUS036NH; and my Windows 7 testbed (with the Intel 6200) was able to connect to it using WPA without a problem, and receive a DHCP lease.
I them moved the same NIC, antenna, and USB cable to the Netgate m1n1wall, assigned the new interface, set it up, and was unable to connect in WPA mode.
As the Alfa gives the same results as the EnGenius on the m1n1wall, but works as an Access Point on the VMWare image, I don't think it's the NIC, the NIC driver, or even the mini-PCI socket (the Alfa is an Ralink chipset via USB, the EnGenius is an Atheros chipset via mini-PCI).
ETA: The VMWare image was also showing dhclient: FAIL in the logs, but wasn't complaining about siproxd.
-
I don't have any regulatory domain set (I choose channel 48 deliberately; 5Ghz isn't common around here)
Your AP is 5GHz capable? How about your clients?
Further analysis of my system log shows some oddities:
Lots of
siproxd[62468]: register.c:149 ERROR: unable to write registration fileseveral:
dhclient: FAIL
Note the DHCP log doesn't show this, just the system log.The DHCP log is for DHCP server. DHCP client logs to the system log. Perhaps your box is running the nano-BSD variant of pfSense which restricts hard drive writes so siproxd can't write its registration file.
I've also ruled out the m1n1wall wireless NIC at this point, and proved the Windows 7 client can connect to pfSense 2.0 WLAN access points with WPA2:
You moved the m1n1wall wireless NIC to another box to prove this? Have you proved a client can connect in WPA2 mode to the m1n1wall NIC?
I them moved the same NIC, antenna, and USB cable to the Netgate m1n1wall, assigned the new interface, set it up, and was unable to connect in WPA mode.
I presume this Alfa USB NIC is driven by the FreeBSD run driver. This NIC needs firmware loaded. The firmware doesn't get loaded if the NIC is in the system at startup. A tweak is needed to get the firmware loaded at startup. Please post the output of pfSense shell command ifconfig -a
As the Alfa gives the same results as the EnGenius on the m1n1wall, but works as an Access Point on the VMWare image, I don't think it's the NIC, the NIC driver, or even the mini-PCI socket (the Alfa is an Ralink chipset via USB, the EnGenius is an Atheros chipset via mini-PCI).
What do you think it is then?
Sometimes seemingly unimportant details turn out to be important. When you changed AP from WEP to WAP2 did you also change the wireless SSID so the client wouldn't retain memory of the previous encryption parameters for that SSID? (If you think I'm clutching at straws you're correct.)
-
I don't have any regulatory domain set (I choose channel 48 deliberately; 5Ghz isn't common around here)
Your AP is 5GHz capable? How about your clients?
Further analysis of my system log shows some oddities:
Lots of
siproxd[62468]: register.c:149 ERROR: unable to write registration fileseveral:
dhclient: FAIL
Note the DHCP log doesn't show this, just the system log.The DHCP log is for DHCP server. DHCP client logs to the system log. Perhaps your box is running the nano-BSD variant of pfSense which restricts hard drive writes so siproxd can't write its registration file.
I've also ruled out the m1n1wall wireless NIC at this point, and proved the Windows 7 client can connect to pfSense 2.0 WLAN access points with WPA2:
You moved the m1n1wall wireless NIC to another box to prove this? Have you proved a client can connect in WPA2 mode to the m1n1wall NIC?
I them moved the same NIC, antenna, and USB cable to the Netgate m1n1wall, assigned the new interface, set it up, and was unable to connect in WPA mode.
I presume this Alfa USB NIC is driven by the FreeBSD run driver. This NIC needs firmware loaded. The firmware doesn't get loaded if the NIC is in the system at startup. A tweak is needed to get the firmware loaded at startup. Please post the output of pfSense shell command ifconfig -a
As the Alfa gives the same results as the EnGenius on the m1n1wall, but works as an Access Point on the VMWare image, I don't think it's the NIC, the NIC driver, or even the mini-PCI socket (the Alfa is an Ralink chipset via USB, the EnGenius is an Atheros chipset via mini-PCI).
What do you think it is then?
Sometimes seemingly unimportant details turn out to be important. When you changed AP from WEP to WAP2 did you also change the wireless SSID so the client wouldn't retain memory of the previous encryption parameters for that SSID? (If you think I'm clutching at straws you're correct.)
Not much time, but again, thank you.
Yes, all hardware (AP, clients) worked on all three of 2.4Ghz, "4.9Ghz" and 5.8ghz three hours prior to changing the Netgate pfSense 1.2.3 NanoBSD CF card for a Netgate pfSense 2.0 NanoBSD CF card with the precise antennas tested, and specifically in WPA2 mode (which had been working with the same [EnGenius miniPCI] hardware for over a year. Not to mention the client picks up the 5Ghz SSID and will successfully connect with WEP or Open authentication.
Thank you for explaining the NanoBSD siproxd logging; can I turn siproxd off, since I don't use SIP?
The AWUS036NH USB NIC was plugging to the m1n1wall while pfSense was already running and I immediately set up the new Interface; I was already logged into the WebConfigurator before I plugged in the AWUS036NH. I'll post the ifconfig -a output in the next 18 hours, though not within the next four.
At this point, I think the Netgate pfSense 2.0 CF card I received may need a little tweak to work right; it's a (slightly?) customized build of pfSense for Netgate's products (NetGate is mentioned at the bottom of the screens). The AWUS036NH test ruled out the EnGenius somehow not being supported on 2.0, which was my other worry (it's a great card), so I'm pretty much down to the pfSense 2.0 choice; I didn't want to try and set up a pfSense 2.0 CF card myself, but that may be the only reasonable option at this point.
No, I did not change the SSID; every time I change the config on the AP, I use Win7's "Manage Wireless Networks", call up the Properties on that SID for the client adapter I'm using, and change the security settings to match. If I do not do this, Win7 shows a red X on the SSID and states that the parameters do not match what the AP requires. This technique works going back and forth, including between WEP (working) and Open (working).
P.S. Is the tweak easy to find with a forum search? I might like to have it later, for a different project.
-
Thank you for explaining the NanoBSD siproxd logging; can I turn siproxd off, since I don't use SIP?
You probably need to uninstall it: System -> Packages, click on Installed Packages, click on "x" button on the right of the siproxd row.
P.S. Is the tweak easy to find with a forum search? I might like to have it later, for a different project.
Yes, search for runfw. The tweak is to add the line```
runfw_load="YES"A forum search will give more background.
-
this is the same as my comment here: http://forum.pfsense.org/index.php/topic,43975.msg228119.html#msg228119
-
@cmb:
this is the same as my comment here: http://forum.pfsense.org/index.php/topic,43975.msg228119.html#msg228119
The Atheros driver bug reported there might explain the problem with the Atheros card reported in the thread but its not obvious it would explain the problem with the Ralink chipset in the AWUS036NH USB WiFi NIC.
-
Thank you both for your time so far; and the other thread mentions any security - WEP works for me.
As a note, I've lost all communication with the pfSense 2.0 after powering it down and back up, and either the console serial port isn't showing anything either, or (more likely) the ridiculous mishmash of a USB to serial converter plus three fifteen year old serial cables chained to try and emulate a female-female DB9 cable is incapable of working properly… or (also likely) I haven't gotten Linux serial comunication working right.
Regrettably, I've pulled the pfSense 2.0 card and reinstalled the pfSense 1.2.3 card (and everything is, of course, working again, including my original WPA2+OpenVPN WiFi setup).
My next step is likely buy a null modem cable first, and second start going through the "build a CF card with a pfSense image" steps which I suspect are quite clear, if something I wanted to avoid
Again, thank you both for your help so far!
-
@cmb:
this is the same as my comment here: http://forum.pfsense.org/index.php/topic,43975.msg228119.html#msg228119
The Atheros driver bug reported there might explain the problem with the Atheros card reported in the thread but its not obvious it would explain the problem with the Ralink chipset in the AWUS036NH USB WiFi NIC.
Correct, no it wouldn't, I missed the card change mid-thread. That only applies to the Atheros.