NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

Aarboard's avatar
Aarboard
Aspirant
Jun 01, 2017
Solved

wndap360 radius failover with 3.6.9.0 firmware not working

Hello,

 

we are just cleaning up our WLAN infrastructure, and for this we upgrade the WNDAP360 AP from firmware 3.5.6.0 to the most recent 3.6.9.0.

In the same step we also change the radius infrastructure to use two new servers instead of one old server.

 

Upgrade and Radius work fine under normal conditions.

But what is not working, is the failover to the secondary radius server, when the first one is not responding.

 

The primary Radius server is 192.168.163.9:1812, the secondary one at 192.168.163.10:1812

Both servers are running Windows 2016 Server, with NPS installed and configured for Radius.

 

In the log of the AP I see this:

Jun  1 17:36:05 hostapd: wifi1vap7: RADIUS Authentication server 192.168.163.9:1812

 

Here a station connects with WPA2-Enterprise and auth via the primary radius server works fine

Jun  1 17:36:18 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: associated
Jun  1 17:36:18 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 17:36:18 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: EAP Identifier of the Response-Identity does not match (was 0, expected 1) - ignored
Jun  1 17:36:19 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 WPA: pairwise key handshake completed (RSN)
Jun  1 17:36:19 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: authenticated - EAP type: 25 (PEAP)

 

We then disconnect the station, and shut down the primary radius server.

Then we try to connect to the station again, but here we see repeated auth failures:

 

Jun  1 17:38:17 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: associated
Jun  1 17:38:17 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 17:38:17 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: EAP Identifier of the Response-Identity does not match (was 0, expected 1) - ignored
Jun  1 17:38:35 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 17:38:53 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: recvd disassoc msg from STA, reason code (8), rssi (67)
Jun  1 17:38:53 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: disassociated

 

At the same time, we see many ARP requests on the LAN for the IP 192.168.163.9 from the AP (So the AP is trying to find the now gone radius server)

We did leave the primary radius server turned off for about 15 minutes, and the AP did still try to find the 192.168.163.9 radius server, no failover

 

Then we turned the primary radius server on again, and authentication works fine again:

Jun  1 17:52:37 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 17:52:37 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: EAP Identifier of the Response-Identity does not match (was 0, expected 1) - ignored
Jun  1 17:52:38 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 WPA: pairwise key handshake completed (RSN)
Jun  1 17:52:38 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: authenticated - EAP type: 25 (PEAP)

 

Also when we reboot the AP with the primary radius offline, it does not pick the secondary radius server.

FW Version WNDAP360_V3.6.9.0
Config Version 4.0
CMAPD Version: 1701.27.1803.40
Jun  1 02:00:50 init: init: starting pid 1808, tty '/dev/ttyS0': '/sbin/getty -L ttyS0 9600 vt100'
Mar 17 15:29:06 udhcpc[656]: Sending discover...
Mar 17 15:29:06 udhcpc[656]: Sending select for 192.168.163.233...
Mar 17 15:29:06 udhcpc[656]: Lease of 192.168.163.233 obtained, lease time 2678400
Mar 17 15:29:10 kernel: php used greatest stack depth: 5092 bytes left
Mar 17 15:29:10 kernel: php used greatest stack depth: 4764 bytes left
Jun  1 18:25:17 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: associated
Jun  1 18:25:17 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 18:25:17 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: EAP Identifier of the Response-Identity does not match (was 0, expected 1) - ignored
Jun  1 18:25:17 hostapd: wifi0vap2: RADIUS Send failed - maybe interface status changed - try to connect again
Jun  1 18:25:17 hostapd: wifi0vap2: RADIUS Authentication server 192.168.163.9:1812
Jun  1 18:25:35 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 18:25:53 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: recvd disassoc msg from STA, reason code (8), rssi (67)
Jun  1 18:25:53 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: disassociated
Jun  1 18:26:07 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: associated
Jun  1 18:26:07 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 18:26:07 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: EAP Identifier of the Response-Identity does not match (was 0, expected 1) - ignored
Jun  1 18:26:25 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 18:26:43 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: recvd disassoc msg from STA, reason code (8), rssi (67)
Jun  1 18:26:43 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: disassociated
Jun  1 18:26:58 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: associated
Jun  1 18:26:58 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 18:26:58 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: EAP Identifier of the Response-Identity does not match (was 0, expected 1) - ignored
Jun  1 18:27:16 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.1X: aborting authentication
Jun  1 18:27:34 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: recvd disassoc msg from STA, reason code (8), rssi (68)
Jun  1 18:27:34 hostapd: wifi0vap2: STA 74:de:2b:9f:3e:e4 IEEE 802.11: disassociated

 

Any ideas what I can try, to get the failover working?

 

  • Hi Aarboard

     

    You can use 3.5.23.0 firmware as we have some issues in picking up the secondary radius server in 3.6.9.0 firmware. But you can use still 3.6.9.0 if you dont need failover.

     

    Thanks

    Raghu

4 Replies

  • RaghuHR's avatar
    RaghuHR
    NETGEAR Expert

    Hi Aarboard

     

    Could you please let us know that you are observing  this issue after upgrading to 3.6.9.0 firmware or in earlier firmware also you have the same issue?

     

    Thanks

    Raghu

    • Aarboard's avatar
      Aarboard
      Aspirant

      Before the upgrade we did not have two radius servers, so I can't compare

      • RaghuHR's avatar
        RaghuHR
        NETGEAR Expert

        Hi Aarboard

         

        You can use 3.5.23.0 firmware as we have some issues in picking up the secondary radius server in 3.6.9.0 firmware. But you can use still 3.6.9.0 if you dont need failover.

         

        Thanks

        Raghu

NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology! 

Join Us!

ProSupport for Business

Comprehensive support plans for maximum network uptime and business peace of mind.

 

Learn More