Sounds like I have a really good reason to look forward to 3.1.x, since our wireless guys have been asking about response-time stats. Since I'll be upgrading from 2.2.x, are there huge gotchas I should be looking for? I've noticed mentions of the newer alternative to ntlm_auth, which I'll look into. Other than that, will a 2.2.x config work out of the gate, or am I looking at a fresh rebuild? Thanks, Steve Lovaas Colorado State University ________________________________________ From: Freeradius-Users <freeradius-users-bounces+steven.lovaas=colostate.edu@lists.freeradius.org> on behalf of Arran Cudbard-Bell <a.cudbardb@freeradius.org> Sent: Thursday, April 21, 2016 9:21 AM To: FreeRadius users mailing list Subject: Re: Correlating Access-Requests and Replys
On Apr 21, 2016, at 11:11 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 21, 2016, at 9:02 AM, Christian Strauf <strauf@rz.tu-clausthal.de> wrote:
we're trying to use an ELK stack (Elasticsearch, Logstash & Kibana) to monitor the performance of our FreeRADIUS 3.0.11 servers which rely on a number of external servers (database, directory etc.). We'd basically like to figure out the elapsed time between first Access-Request and the final Access-Accept (or Access-Reject for that matter).
The server doesn't really track that in 3.0, or tracks it only at second resolution.
In 3.1, it tracks all requests / responses in millisecond or better resolution.
A prerequisite for this is that we can actually correlate Access-Requests and replies by the RADIUS server. I searched a little and found a post by Alan DeKok from 2012 on a very similar matter. The problem is that there's nothing much you can use to correlate an Access-Request reliably to the answers by the RADIUS server. Alan suggested adding a reply item to the reply:
I'm not sure why you need to correlate them. They're already correlated in the server. All you need to do is print out the time difference between request and response.
He's after completion time. I.e. from the first Access-Request to the Access-Accept/Access-Reject. It's not something we currently track (as far as i'm aware?), it's not something radsniff can do either. Easy to do in v3.1.x as we have request->state->id, which gets populated after the first call to rlm_eap and is stable throughout the progression of the authentication attempt. I was already thinking of adding this, it's useful for debugging issues with EAP. -Arran