hostapd: RADIUS client does not reattempt connection to external RADIUS server after hostapd startup first attempt connection fails.

Chrishanton Vethanayagam chrishanton at yahoo.com
Wed Jan 21 21:06:48 EST 2015


I have faced the above subject matter when using thelatest git sources and built hostapd.This issue is not a problem in hostapd stable releaseversions 2.1 and earlier.
Is there intention to reattempt connection to RADIUSserver after start-up first attempt connection fail?If so, the below is an analysis of what changed fromstable release 2.2 onwards.
Steps to reproduce failure environment:1. Start-up hostapd which is configured to connect to asingle external RADIUS server IP address.2. In the case when system has no network connection tosaid IP address (be it the necessary network interface to access the RADIUSserver is not up yet, or relevant routing is not up yet, etc.), system willfail to connect at startup initialisation. (hostapd log output at this point: 'connect[radius]: Network is unreachable ' )3. Subsequent attempts by hostapd to send radius packetsout when WiFi clients associate & negotiate security would continuouslyfail, even though RADIUS server is now pingable by system. (hostapd log outputat this point: ' RADIUS No authentication server configured. ' )
After reviewing the src/radius/radius_client.c file, thefollowing are my findings:a) In step 2 above, startup initialisation would run intothe radius_change_server() function which would attempt to make connect toRADIUS server but fail in the fail case environment of step 2 above. The codewould then exit the function at an earlier point, without setting theradius->auth_sock which occurs at tail end of radius_change_server().b) In step 3 above, hostapd would send out RADIUS packetsto RADIUS server in radius_client_send() function when a WiFi client is insecurity negotiation, but fails and generates the log message in step 3 abovewhich originates from this function. This is due to a conditional check on thesame radius->auth_sock which did not get populated at startup as explainedin step a)
Comparing the radius_client.c code between releases 2.1& 2.2 shows that 2.2 adds this conditional check on radius->auth_sock inradius_client_send().
This is the point which causes the re-connection attemptfailure as  the code does not proceedfurther down the function radius_client_send() to fail at sending packetsthrough the socket, thus triggering radius_client_handle_send_error() to run,which would then trigger radius_change_server() to run again (successfully asand when RADIUS server is pingable), and things will then work when the nexttime the radius packet is retransmitted (I believe this was how it worked instable release 2.1 and earlier).
I have tried removing the radius->auth_sockconditional check from latest git code, and tested it to work successfully,similar to releases 2.1 & earlier with respect to RADIUS serverreconnection attempt.The below is the patch which was used (basically revertingthe radius->auth_sock & radius->acct_sock condition check):
diff --git a/src/radius/radius_client.cb/src/radius/radius_client.cindex 34f5685..9694cb6 100644--- a/src/radius/radius_client.c+++ b/src/radius/radius_client.c@@ -658,7 +658,7 @@ int radius_client_send(structradius_client_data *radius,        }
        if(msg_type == RADIUS_ACCT || msg_type == RADIUS_ACCT_INTERIM) {-               if(conf->acct_server == NULL || radius->acct_sock < 0 ||+               if(conf->acct_server == NULL ||                   conf->acct_server->shared_secret == NULL) {                       hostapd_logger(radius->ctx, NULL,                                      HOSTAPD_MODULE_RADIUS,@@ -673,7 +673,7 @@ int radius_client_send(structradius_client_data *radius,                s =radius->acct_sock;               conf->acct_server->requests++;        } else {-               if(conf->auth_server == NULL || radius->auth_sock < 0 ||+               if(conf->auth_server == NULL ||                    conf->auth_server->shared_secret== NULL) {                       hostapd_logger(radius->ctx, NULL,                                      HOSTAPD_MODULE_RADIUS,
There may be more behind the introduction of thisconditional check from release 2.2 onwards (certainly the radius client code ismore consolidated) and perhaps there are some plans/provisions to handle thisin a more elegant manner (granted that the mechanism to attempt re-connectionpreviously was through a failed attempt at sending a packet through the socketwith the initial invalid socket descriptor).Or perhaps there is no intention to reattempt connectionto RADIUS server altogether?
Just wanted to bring notice to this RADIUS clientbehavioural difference from stable release 2.2 onwards, and leave it to thegood judgement of hostapd developers.Chrishanton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20150122/e4d9d119/attachment.htm>


More information about the HostAP mailing list