FreeRADIUS 1.1.3 bug - Accounting requests reemission by FreeRADIUS In file "main\request_list.c", function "refresh_request". In the case of an accounting request (request->proxy->code == PW_ACCOUNTING_REQUEST), FreeRADIUS adds to the proxied packet the attribute "Acct-Delay-Time" (or updates it, if it was present in previous emission) with value set to the time difference between current time and time of initial proxied request. According to RFC 2866, chapter 4.1 : "The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged. Note that if Acct-Delay-Time is included in the attributes of an Accounting-Request then the Acct-Delay-Time value will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator." FreeRADIUS updates the content of the packet when reemitting the accounting request, but does not change the Identifier. Thus, those packets sent after the first one are *not* true reemissions. This is a problem to us. For instance, we have the following setup : A client (A) sending an accounting request to FreeRADIUS (B), which retransmits the request to a proxy FreeRADIUS server (C). FreeRADIUS C is slow to respond, so FreeRADIUS B reemits the request, with different packet attributes (Acct-Delay-Time added), but keeps the same identifier. FreeRADIUS C receives the second request, but discards it since it has the same identifier as the request currently being processed. FreeRADIUS C then decides to finally respond (to the first request). FreeRADIUS B receives this response, and verifies if the request (the reemission) and response match. They do not, thus FreeRADIUS B drops the response and logs an error. FreeRADIUS should either : - NOT add Acct-Delay-Time attribute in accounting reemissions, thus preserving the content of the attributes in the packet. - or, add an Acct-Delay-Time, but change the identifier and handle the proxied packet as a new request. The second solution seems overly complicated, because FreeRADIUS would have to handle the second proxied request as a completely new request, but would also have keep the first one, as the proxy server can respond to any of the reemissions. The first solution is very simple to correct: it simply involves removing the block "if (request->proxy->code == PW_ACCOUNTING_REQUEST) {" in function "refresh_request" of file "main\request_list.c". I don't know if Acct-Delay-Time attribute is really useful to someone, I've never seen it used in any implementation of a RADIUS server. Anyhow, it seems way too much hassle to correctly handle this attribute in accounting reemissions. If tehre is any any objection, we will develop a patch to remove Acct-Delay-Time and provide it soon. 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