How does freeRadius track requests? I get errors along the lines of "Error: Discarding duplicate request from client [IP REDACTED]:49603 - ID: 204 due to unfinished request 298385" Far more often than I believe I should. What does it mean for a request to be unfinished, and how does freeRadius determine that a request is a duplicate? Travis Dimmig Software Development Specialist Impulse Point www.impulse.com<http://www.impulse.com>
Hi,
“Error: Discarding duplicate request from client [IP REDACTED]:49603 - ID: 204 due to unfinished request 298385”
Far more often than I believe I should. What does it mean for a request to be unfinished, and how does freeRadius determine that a request is a duplicate?
each packet has an ID - this is kept in a process buffer - so if a matching packet comes in, then the server knows its already dealing with that one and hasnt finished with it...so it marks the new as a duplicate - the cause for this is often that the backend dealing with a packet is too slow - eg SQL insert for an accounting packet is often the issue alan
I assume this ID is generated by the device generating radius, and not something that is calculated by freeRadius? Is this ID a radius attribute, such as either Acct-Session-Id or Acct-Unique-Session-Id? Is there a standard method used to derive this ID for devices that output RADIUS? I am developing an application that outputs RADIUS accounting, and suspect that the issue is caused by not properly constructing the RADIUS packets, not that the other end is taking too long to process the requests and respond as Mr. Dekok suggests. Travis
-----Original Message----- From: freeradius-users-bounces+tdimmig=impulse.com@lists.freeradius.org [mailto:freeradius-users- bounces+tdimmig=impulse.com@lists.freeradius.org] On Behalf Of Alan Buxey Sent: Tuesday, January 24, 2012 4:52 PM To: FreeRadius users mailing list Subject: Re: request tracking
Hi,
“Error: Discarding duplicate request from client [IP REDACTED]:49603 - ID: 204 due to unfinished request 298385”
Far more often than I believe I should. What does it mean for a request to be unfinished, and how does freeRadius determine that a request is a duplicate?
each packet has an ID - this is kept in a process buffer - so if a matching packet comes in, then the server knows its already dealing with that one and hasnt finished with it...so it marks the new as a duplicate - the cause for this is often that the backend dealing with a packet is too slow - eg SQL insert for an accounting packet is often the issue
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Travis Dimmig wrote:
I assume this ID is generated by the device generating radius, and not something that is calculated by freeRadius?
See Wikipedia. That's what it's for.
Is this ID a radius attribute, such as either Acct-Session-Id or Acct-Unique-Session-Id?
Again, see Wikipedia.
Is there a standard method used to derive this ID for devices that output RADIUS?
I have no idea what that means.
I am developing an application that outputs RADIUS accounting, and suspect that the issue is caused by not properly constructing the RADIUS packets, not that the other end is taking too long to process the requests and respond as Mr. Dekok suggests.
If you're writing a RADIUS client, you really need to read and understand the RFCs. Wikipedia won't be enough. If you just want to do RADIUS accounting, use "radclient". It's a RADIUS client that works. Alan DeKok.
Travis Dimmig wrote:
How does freeRadius track requests?
See RFC 5080, Section 2.2.2. I wrote the FreeRADIUS code first, then the RFC.
I get errors along the lines of
“Error: Discarding duplicate request from client [IP REDACTED]:49603 - ID: 204 due to unfinished request 298385”
Far more often than I believe I should. What does it mean for a request to be unfinished, and how does freeRadius determine that a request is a duplicate?
It means that if you're building a NAC solution, you should really understand the underlying protocols. The usual reason is that you're putting the requests into a DB, and the DB is slow (not indexed, contention, etc.) This has been discussed many times on this list. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Travis Dimmig