Thanks Alan for reply. Connection to another backup DB from the same radius server will help only if the primary DB has real problem. But if there is a network issue to connect to DB and DB is fine just radius daemon fails to communicate to the database so in this case radius needs not to respond to the NAS instead of sending "reject". Killing radius daemon from a script is not a very clean solution. it would be much easier if auth.c file rad_authenticate function would not set request->reply->code = PW_AUTHENTICATION_REJECT; for RLM_MODULE_FAIL What RFC is saying about returning reject for actual hardware/network issue as this is not a real reject(like user does not exist or password is wrong) and NAS treats this reject as radius server is UP but authentication failed. result = module_authorize(autz_type, request); switch (result) { case RLM_MODULE_NOOP: case RLM_MODULE_NOTFOUND: case RLM_MODULE_OK: case RLM_MODULE_UPDATED: break; case RLM_MODULE_HANDLED: return result; case RLM_MODULE_FAIL: case RLM_MODULE_INVALID: case RLM_MODULE_REJECT: case RLM_MODULE_USERLOCK: default: if ((module_msg = pairfind(request->packet->vps, PW_MODULE_FAILURE_MESSAGE)) != NULL) { char msg[MAX_STRING_LEN + 16]; snprintf(msg, sizeof(msg), "Invalid user (%s)", module_msg->vp_strvalue); rad_authlog(msg,request,0); } else { rad_authlog("Invalid user", request, 0); } request->reply->code = PW_AUTHENTICATION_REJECT; return result; } A.L.M.Buxey wrote:
Hi,
Right now FreeRadius returns reject to NAS rlm_sql (sql): Failed to connect DB handle #8 rlm_sql (sql): reconnect failed, database down? rlm_sql_getvpdata: database query error [sql] SQL query error; rejecting user rlm_sql (sql): Released sql socket id: 8 ++[sql] returns fail Sending Access-Reject Say I do not want to return reject in this case and I want the switch to understand that radius is down and retry another radius server (a backup/failover). Because if I return reject the NAS device treats this as radius is UP and running.
if radiusd cannot use the SQL, then its a fail...and a reject. if you dont want this to happen, and radiusd is running, why would you think the NAS should try another radiusd server to get to another DB? if the radius daemon is up, then it should try the other DB instead! this is a much better way - just add the other DB to the SQL config - there are plenty of resouces (and mailing list archives) that show how you can add another sql instance..and use that if the primary fails
alternatively, if the DB is down, have a monitor task that can check this (eg a timed PERL process) and if the DB is down, kill the radius daemon. thats just as bad as what you are suggesting..but is 'clean' from the NAS end (particularly its its got status packet ability)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://www.nabble.com/Freeradius-2.1-1%3A-failure-modes-tp22413666p22418589.... Sent from the FreeRadius - User mailing list archive at Nabble.com.