Correlating Access-Requests and Replys

[Lovaas,Steven]

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 at lists.freeradius.org> on behalf of Arran Cudbard-Bell <a.cudbardb at 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 at deployingradius.com> wrote:
>
> On Apr 21, 2016, at 9:02 AM, Christian Strauf <strauf at 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