<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div>FreeRADIUS 1.1.3 - Reemission bug in multi-threaded mode - FreeRADIUS does not wake up properly<br><br><br>When receiving a request to proxy, FreeRADIUS should wake up in (at most) the proxied request retransmission delay parameter.<br><br>This does not work.<br><br>Note that in the case of the NAS reemitting the request, the problem does not appear, because when receiving new requests, FreeRADIUS wakes up and process its request list.<br><br>The problem happens when a request is received, the request has to be proxied, but the NAS does not reemit (and no other request is received by FreeRADIUS from any NAS).<br><br><br><br>The "wake up" delay is then set to 31 (probably max_request_time + 1) seconds instead of 5 (retry_delay), as we can see in debug mode:<br><br>rad_recv: Accounting-Request packet from host
*****:16384, id=233, length=53<br>Mon Nov 6 15:11:57 2006 : Debug: --- Walking the entire request list ---<br>Mon Nov 6 15:11:57 2006 : Debug: Thread 4 got semaphore<br>Mon Nov 6 15:11:57 2006 : Debug: Waking up in 31 seconds...<br>Mon Nov 6 15:11:57 2006 : Debug: Thread 4 handling request 3, (1 handled so far)<br><br>The behaviour is the same in normal (non debug) mode : the proxy server does only receive the request once, thus FreeRADIUS is not reemitting.<br><br><br><br>In function refresh_request of file request_list.c, we should pass in the following condition :<br><br>if (request->proxy && !request->proxy_reply) { ...<br><br>(ie, request unfinished, but has been proxied and we are waiting for response from proxy server)<br><br>It seems the condition is not met, so the next condition (ie, request unfinished but no proxy) is fulfilled. Thus, FreeRADIUS computes the time difference with:<br><br>difference = (request->timestamp +
mainconfig.max_request_time) - info->now;<br><br><br><br><br>If FreeRADIUS is launched in single-thread mode (-X), the problem does not occur.<br><br><br>It seems that "request->proxy" is 0 when the condition is tested, thus, FreeRADIUS considers there is no proxy outstanding for this request.<br><br>From what I understand, when receiving a request, the thread that handles the list of requests wakes up, process its list and goes back to sleep. This thread finishes its work *before* the thread handling the request has proxied the request.<br><br>This is the cause of the problem described above.<br><br><br><br>Any hint as how to fix this ? (the problem is not critical: it appears on a test environment but will not happen in production, as a RADIUS server receives lots of requests)<br><br>Should I log this in bugzilla ?<br><br><br>Thanks.<br><br><br>Best regards,<br>Nicolas.<br><br><br><br></div></div><br>
<hr size=1> Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
<a href="http://us.rd.yahoo.com/messenger/mail_taglines/default/*http://fr.beta.messenger.yahoo.com">Téléchargez</a> la version beta.</body></html>