hostapd 0.5.7: failover to secondary RADIUS problem

[Jouni Malinen]

On Tue, Apr 08, 2008 at 02:52:27PM +0200, Lambert Anne wrote:

> Here is the configuration I am testing:
> 
> PC1 - 10.0.0.27 -> freeRADIUS
> PC2 - 10.0.0.25 -> freeRADIUS
> PC3 - 10.0.0.26 -> hostapd 0.5.7 + madwifi
> PC4 - 10.0.0.22 -> the wireless station
> 
> hostapd is configured with primary authentication RADIUS = 10.0.0.27 and
> secondary = 10.0.0.25.
> 
> Case1: PC1 and 2 are switched on but freeRADIUS runs only on PC2.
> The log case1.txt a failed attempt by the station to authenticate (using
> EAP-TLS). The failover does not take place.

I think I've now fully understood the setup and I have build a testbed
with more or less identical configuration. I can generate a similar
debug log from hostapd all the way to the failover point (about 48
seconds from the start of authentication attempt). However, in my tests,
failover to the secondary RADIUS server works fine and authentication is
completed successfully.

Your debug log from case 1 is also indicating that there was a failover:

1207644887.377801: ath0: RADIUS No response from Authentication server 10.0.0.27:1812 - failover
1207644887.377908: ath0: RADIUS Authentication server 10.0.0.25:1812

However, the attempts to PC2 do not produce any response. Interestingly,
this differs from the time before the failover by not showing the failed
UDP sends (i.e., "recv[RADIUS]: Connection refused" does not show up in
the log.

Are you sure PC2 was in working condition at this point and that the
configuration (mainly, shared secret for the client) was correct? Could
you please try to capture all frames between the devices (e.g., with
wireshark or tcpdump) and verify that hostapd is indeed changing the
destination address for the UDP packets after about 48 seconds from the
first RADIUS request? Since the debug log from hostapd seems to indicate
that everything goes fine apart from PC2 not replying to RADIUS
requests, this would require more debugging to figure out where exactly
the UDP packets are sent and why there is no reply if they are indeed
going to the correct destination.

-- 
Jouni Malinen                                            PGP id EFC895FA