Hi, Many thanks for the reference and explanations. Here's what I see. The following flows correspond to a single transaction. Duplicate Packets are marked based on the id.
However, I'm actually talking about retransmissions. Please Refer to Accounting-Request IDs 142,134 and 236. They are retransmissions due to delay in response. -------------- NAS - 10.10.10.17; AAA Server 1.1.1.4 # SRC DST RADIUS 1 10.10.10.17 1.1.1.4 Access-Request(1) (id=185, l=135 2 10.10.10.17 1.1.1.4 Access-Request(1) (id=185, l=135), Duplicate Request ID:185 3 1.1.1.4 10.10.10.17 Access-Accept(2) (id=185, l=38) 4 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215) 5 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215), Duplicate Request ID:142 6 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215), Duplicate Request ID:142 7 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257) 8 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257), Duplicate Request ID:134 9 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257) 10 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257) 11 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257), Duplicate Request ID:236 12 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=142, l=20) 13 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257) 14 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=134, l=20) 15 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=236, l=20) Auth process fails at the client end. Simply speaking, the client does not get the Framed-IP-Address. This occurs, when the (NAS <=> AAA) response delay exceeds ~5 seconds. So according to RFC 5080: Is this an example of "Note that changing the Request ID for a retransmission may have undesirable side effects." ? How could one tackle with this issue? As Ivan described could "NAS retransmit timer" be increased to handle delayed responses? Thanks, If duplicate requests are identified (based on the identifier), On Fri, May 2, 2008 at 3:47 PM, Alan DeKok <[EMAIL PROTECTED]> wrote: > Ivan Kalik wrote: > > They are discarded. Standard setting on most radius clients is to resend > > the request after 2 seconds without reply. And for most of them it can > > be configured. > > RFC 5080 also specifies a better way to handle retransmits, than the > old "try T times, with delay of D seconds between each try". > > Of course, FreeRADIUS implements it. :) > > Alan DeKok. > > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html