Reemission bug in multi-threaded mode - FreeRADIUS does not wake up properly

[Geoffroy Arnoud]

> FreeRADIUS 1.1.3 - Reemission bug in multi-threaded
> mode - FreeRADIUS does not wake up properly
> 
> 
> When receiving a request to proxy, FreeRADIUS should
> wake up in (at most) the proxied request
> retransmission delay parameter.
> 
> This does not work.
> 
> 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.
> 
> 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).
> 
> 
> 
> 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:
> 
> rad_recv: Accounting-Request packet from host
> *****:16384, id=233, length=53
> Mon Nov  6 15:11:57 2006 : Debug: --- Walking the
> entire request list ---
> Mon Nov  6 15:11:57 2006 : Debug: Thread 4 got
> semaphore
> Mon Nov  6 15:11:57 2006 : Debug: Waking up in 31
> seconds...
> Mon Nov  6 15:11:57 2006 : Debug: Thread 4 handling
> request 3, (1 handled so far)
> 
> The behaviour is the same in normal (non debug) mode
> : the proxy server does only receive the request
> once, thus FreeRADIUS is not reemitting.
> 
> 
> 
> In function refresh_request of file request_list.c,
> we should pass in the following condition :
> 
> if (request->proxy && !request->proxy_reply) { ...
> 
> (ie, request unfinished, but has been proxied and we
> are waiting for response from proxy server)
> 
> 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:
> 
> difference = (request->timestamp +
> mainconfig.max_request_time) - info->now;
> 
> 

I think there is also an issue when dealing with local
traffic,
when reject_delay is > 0.
When there is not much traffic, FreeRADIUS goes to
sleep and 'forgets' to send
the Access-Reject after 'reject_delay' seconds.

The Access-Reject is sent only when the NAS re-sends
the Access-Request.
FreeRADIUS then sends 2 Access-Rejects in quite the
same time.

The bug doesn't appear is reject_delay is set to 0.

Best regards,

Geoff.


	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com