WAP321 RADIUS MAC filter dont work correctly (FW 1.0.5.3)

[crawler95]

Im having issues with RADIUS MAC filtering in WAP321. I have a network SSID with WPA2-Personal and MAC filtering set to RADIUS.

There are two cases of the error:

With 'Filter' setting in MAC Filtering page set to 'Allow only stations in list', If I try to associate a client the first time I get an error like this:

Going to WAP321 log it shows that the RADIUS server accepted and allowed the request with an Accept-Accept reply, but instead gave an association error in client station:

If I attempt to associate the station again this time associates successfully and log shows this:

Also If I associate again the RADIUS server is NEVER asked to authenticate again and the AP simply accepts and allows the request.

That was the first case, only successfully associating from the second attempt and further.

The second case with 'Filter' setting in MAC Filtering page set to 'Block all stations in list' I NEVER get to associate the station with the WAP, getting the same association error like first attempt, and log showing:

Every attempt to associate results in 'trying to deauthenticate, but not authenticated' message in log:

The 'Filter' setting in MAC Filtering page should be ignored regardless of the setting because the SSID MAC Filtering is set to 'RADIUS' and 'Filter' setting should only be used if network SSID is configured with 'Local' MAC filtering.

I think the problem is some bug with MAC authentication in the firmware's hostapd implementation.

Firmware version is 1.0.5.3

[Michal Bruncko]

Hi crawler95

At first - very nice investigation :-) At first glance there really shouldn't be any relation between "RADIUS" MAC filtering and "Filter:" setting in Local MAC filtering and RADIUS decision (access-accept or access-reject) should be exclusively accepted by WAP.

But this is not true. If you look inside WAP321 "Help" section for "MAC Filter" you will see following:

 

• Allow only stations in the list—Any station that is not in the Stations List is denied access to the network through the WAP device.
• Block all stations in list—Only the stations that appear in the list are denied access to the network through the WAP device. All other stations are permitted access.

NOTE     The filter setting also applies to the MAC filtering list stored on the RADIUS server, if one exists.

Which means that surprisingly "Filter:" setting have direct impact to behavior of RADIUS MAC address filtering as well - which completely meets your investigation results.

The only not corresponding behavior is your first case - i.e. you'll get authenticated only for second or next attempt, but not first one. What happen if you put MAC address of your wireless client in Local MAC List and keeps RADIUS filtering enabled? Will you be able to authenticate/associate during first attempt?

[crawler95]

Hello, thanks for your help I didn't notice the note in help page. I've ran a test again but got the same results. The tests were run using a fresh rebooted AP environment. If I set 'MAC Filtering' to 'Allow only stations in list' and add my client MAC address to the list, I get the same behavior with the first attempt giving an error and only the second or next attempt authenticates successfully: ** LOG ATTACHED - LOG1.TXT ** I did another test using 'Block all stations in list' setting with a bogus MAC address in list and again get the same result not allowing the client to associate giving an error on client side but log saying 'successfully': ** LOG ATTACHED - LOG2.TXT **

[Michal Bruncko]

From log1.txt:

Feb 5 2015 16:48:13 	info 	hostapd[1094] 	wlan0vap1: IEEE 802.11 RADIUS MAC AUTH: c8:3a:35:cf:e8:5e Accepted 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: RADIUS Received RADIUS packet matched with a pending request, round trip time 0.03 sec 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: RADIUS Received RADIUS message 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: RADIUS Received 35 bytes from RADIUS server 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.11: trying to deauthenticate, but not authenticated 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.11: trying to deauthenticate, but not authenticated 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.11: trying to deauthenticate, but not authenticated 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: RADIUS Next RADIUS client retransmit in 3 seconds 	 
Feb 5 2015 16:48:13 	debug 	hostapd[1094] 	wlan0vap1: RADIUS Sending RADIUS message to authentication server 	

this part is fine, as it describes MAC authorization which is in place and was done successfully.

But second thing does not look good to me:

Feb 5 2015 16:48:22 	info 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: pairwise key handshake timed out (no reply was received for the first message) 	 
Feb 5 2015 16:48:22 	info 	hostapd[1094] 	Station c8:3a:35:cf:e8:5e had an authentication failure, reason 16 	 
Feb 5 2015 16:48:19 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.1X: Send EAPOL frame len=99 	 
Feb 5 2015 16:48:19 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending EAPOL-Key(s) (pair=1 mic=0 ack=1 secure=0 usage=0 keyidx=0) 	 
Feb 5 2015 16:48:19 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending 1/4 msg of 4-Way Handshake 	 
Feb 5 2015 16:48:17 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.1X: Send EAPOL frame len=99 	 
Feb 5 2015 16:48:17 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending EAPOL-Key(s) (pair=1 mic=0 ack=1 secure=0 usage=0 keyidx=0) 	 
Feb 5 2015 16:48:17 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending 1/4 msg of 4-Way Handshake 	 
Feb 5 2015 16:48:16 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.1X: Send EAPOL frame len=99 	 
Feb 5 2015 16:48:16 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending EAPOL-Key(s) (pair=1 mic=0 ack=1 secure=0 usage=0 keyidx=0) 	 
Feb 5 2015 16:48:16 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending 1/4 msg of 4-Way Handshake 	 
Feb 5 2015 16:48:15 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.1X: Send EAPOL frame len=99 	 
Feb 5 2015 16:48:15 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending EAPOL-Key(s) (pair=1 mic=0 ack=1 secure=0 usage=0 keyidx=0) 	 
Feb 5 2015 16:48:15 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: sending 1/4 msg of 4-Way Handshake 	 
Feb 5 2015 16:48:15 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e WPA: event - Authentication Request 	 
Feb 5 2015 16:48:15 	debug 	hostapd[1094] 	wlan0vap1: STA c8:3a:35:cf:e8:5e IEEE 802.1X: unauthorizing port 

for some reason client didn't respond to WPA 4-Way Handshake initiated by WAP - you can see that WAP sends same request four times - all the time same packet with same flags.

Now I am not definitely sure, but it looks like WPA2-Enterprise was activated instead of WPA2-PSK (which you mention that you have set WPA-PSK for your SSID, right?) - all four requests are within

IEEE 802.1X: Send EAPOL frame

which points me that 802.1X RADIUS authentication was used for some reason instead of WPA-PSK. And if your client is not activated for 802.1X then it will ignore any such request from WAP.

If this is really true, then I would say that this is wrong behavior and bug.

[Michal Bruncko]

By the way - my suspicion about WPA2-Enterprise used instead of WPA2-PSK during first connection try can be simply confirmed by packet capture from WAP321 unit or packet capture from client side. In WPA2-Enterprise case you should see EAPOL packets crossing between Wifi client and supplicant (WAP). And in that case this is not correct behavior in case you have configured WPA2-PSK.

[crawler95]

Hello, I've done a test with first and next attempt using MS Message Analyzer to capture events from the WiFi subsystem in Windows

Attached is a zip file with the captures from first attempt with error and second attempt which connects successfully. You can open the files with Microsoft Message Analyzer 1.2 from http://www.microsoft.com/en-us/download/details.aspx?id=44226

[Michal Bruncko]

Very nice, thanks! Now it is more clear. EAPOL protocol is used to exchange WPA2-PSK keys. Which means this has nothing to do with 802.1X. In comparison between both output:

• during first attempt - WAP sends EAPOL message to STA (client) four times (message nubmers 1386-1392), but didn't get response.
• during second attempt (second capture) STA sends response (message nubmer 1596) immediately after receiving first EAPOL message (message nubmer 1594).

And why STA didn't respond with EAPOL response during first attempt? I have no idea... you can try to update driver of your Wifi adapter or try same test with different Wifi card or using Smartphone for example. If behavior will be same.

But now I would say this is more incompatibility issue between your Wifi adapter and AP. But you can confirm this with testing with different Wifi adapter (with different vendor ideally).

[crawler95]

Hello, the tests were done with two different adapters, the same result

I attach the files with WAP's log and MSMA capture from first and second attempt using the other adapter.

I also have a SSID in WAP321 configured to do WPA2-Enterprise without RADIUS MAC and it works correctly associating from the first attempt and I suppose it's nothing to do with my test SSID configured with WPA2-PSK and RADIUS MAC.

The only downside with WPA2-Enterprise in WAP is that only sends Account-Start and Account-Stop packets on connect/disconnect and not Account-Interim-Update on the meanwhile so I can't keep my database updated with accounting data but thats a misfeature or another bug.

The WAP is an odyssey. To even get the level of debug of hostapd in the posted log I had to hack inside WAP to get SSH working to manually change the 'logger_syslog_level' setting to value '0' (verbose debug) in hostapd.conf.wlan0 which is hardcoded to value '8' (info) regardless of the setting in 'Administration/Log Settings' and manually send a HUP signal to hostapd process because If I kill it completely the dman process overrides the configuration with original and relaunches hostapd on its own.

I also have couple of HP V-M200 and the same configuration works even better, WPA2-Enterprise with Start, Stop and Interim updates, WPA2-PSK with MAC auth, revalidation with RADIUS server on every association attempt and it costs cheaper. The only thing that it share with Cisco WAP is the banned SSH part for Small Business in the excuse of 'not meant to end user' / 'security risk' (see https://supportforums.cisco.com/discussion/11759941/feature-request-wap321-sshtelnet-support), but I managed to activate it as well because I need it to monitor client association via external scripts.

I though that the more expensive the device is, the quality and features will be better but with WAP321 and seeing a lot of issues of it in this forum make me rethink the idea.

I can post my discoveries somewhere in a blog to show everyone how to do some things but I'm not sure if is appropiate cuz I don't want some weird or 'business strategy'-induced changes in firmware that would close me the posibility. I only want to get things working in a manner I wish if there is the posibility.

The WAP321 uses a patched version of hostapd, thus may be the version is too old/buggy and need to get updated with a recent version reapplying the patches that make it work with the Broadcom platform used in WAP or may be the patches itself are buggy.

[Michal Bruncko]

Hi crawler

I have same opinion in regards to blocking SSH access to WAP devices. For me the "Security concerns" is not valid reason to block that service. For both of accesses (Web and SSH) same account credential is needed. Also both accesses are accessible same way. This means that if someone knows admin credentials, it can be used either way to make bad things with device. Having SSH access is not necessary.

Secondly management access (for both SSH and Web) can be perfectly separated using different management subnet/VLAN and there are no security concerns at all.

The only correct explanation why they decided to prohibit access to SSH is to break possibility of automation solutions (custom admin scripts for example) like they can be used on enterprise devices and avoid bypassing explicit limitations of WebGUI interface.

In regards to your issue: seems you have tested this with various Wifi adapters. Thus I would suggest you to open case to Small Business Support Center (SBSC) where you describe your issue (which seems to be pretty good reproducible) and wait for fix. If you will have a luck, issue will be identified and fix provided within few days and you will be provided with beta firmware which includes fix (it could takes months till new firmware including fix for your issue will be released publicly).

[Bernie Marone]

Crawler95,
Was a case ever opened on this? I purchased the WAP321 just over a year ago so can't open my own, but I'm having exactly the same problem:
1) For testing, MAC is excluded from the RADIUS database.
2) For the first attempt after AP reboots, the MAC auth attempt is seen by the RADIUS server, denied, and the laptop association is prevented.
3) For all subsequent attempts to connect, the RADIUS server sees no traffic and the laptop connection is permitted.

I'm on firmware 1.0.6.5, wondering if downgrading below 1.0.5.3 might be a solution.

Also, if you've posted those "discoveries somewhere in a blog", that might be some interesting reading.
:)

Thanks.

[crawler95]

Well, I was too lazy to create a blog :P, but after two years if I remember correctly there was no solution coming from Cisco, for the SSH access I managed to enable it by modifyng the firmware to start dropbear at boot (disabled intentionally by Cisco since version 1.0.1.10), and for the RADIUS MAC part the problem seems to be the bugged outdated version of hostapd (the software part that handles the AP function) that is bundled with the firmware, and of course there was never a fix from Cisco. In a attempt to fix this, I tried replacing the hostapd with a ARM-compiled version that comes with OpenWRT, unfortunately the version was incompatible and bricked my WAP321 to the point that it became unusable (permanent reboot loop) and I did not allow to upload a good firmware again because it never gets to the point were the Web GUI is usable, and later I ended up even bricking it more. Fortunately I make a backup of the NAND memory before that and I was able to fix that after programming directly the NAND flash using the JTAG port with UrJTAG and OpenOCD, but that really was a hard pain in the ass because the initial mode of the JTAG port was not standard and needed first a series of commands to put the JTAG port in standard mode to be able to talk with UrJTAG to upload a firmware to it, and to upload ~260kB (the bootloader code plus some random bytes to cause a bad checksum check) took about 4+ hours using bit banged serial mode through the slow JTAG port and then the WAP321 was able to show a minimal Web GUI requesting a firmware to upload (like when the firmware upload fails) and completed the rest through it.

Since that I lived with the problem on my WAP321, of couse I never buyed more WAP321 again, and instead buyed a good Nanostation wich can replace the firmware with OpenWRT and do whatever you want with it, with half the cost, more features, no limitations because the firmware is open source. I think that the enterprise features are in the software, if I decide to implement these myself when I buy a hardware then I should be able to make the most of it without limitations from the manufacturer.

I can provide a version of 1.0.6.5 firmware with SSH enabled if you need it, but for RADIUS MAC Auth the only solution is to compile a newer version of hostapd (with the custom patches that Cisco applied) targetting the Broadcom BCM4748 (the SoC of WAP321) and replacing it in the firmware, and at least two years ago that was not easy, even getting the patches will be difficult because they are copyrighted material that Cisco owns and their support team surely will not give it to the public. And today you say you are using the 1.0.6.5 version, last version I proved was 1.0.6.2, so Cisco again did not updated the buggy hostapd version that comes bundled with firmware. Again the bugs aren't resolved by manufacturer and they prevent the user from resolving it, and because of that I decided to switch to another AP that at least can be personallized with open source software and not locked to manufacturer decisions of solving issues (at least software issues). Is like in a baseball game, they do not pitch, do not catch, nor allow to hit.