Correlating Access-Requests and Replys

[Arran Cudbard-Bell]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160421/f854109f/attachment-0001.sig>