Correlating Access-Requests and Replys

Arran Cudbard-Bell a.cudbardb at freeradius.org
Fri Apr 22 02:40:07 CEST 2016


> On 21 Apr 2016, at 13:11, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
> 
> 
>> On Apr 21, 2016, at 12:16 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
>> 
>> On 21/04/16 16:39, Arran Cudbard-Bell wrote:
>> 
>>> I'll add something that behaves like that.
>> 
>> It would be super-useful if the thing you add is present before "authorize" is called; State only appears after eap.authenticate, which can be too late for some kinds of logging.
> 
> Yeah, the state I was referring to wasn't the state attribute, it was the a fr_state_entry_t.  But the ID of that struct mutates every round too, because a new instance of that struct is allocated each time.
> 
> We can change fr_state_to_request to populate a field in the REQUEST * with a session number if it fails to find a matching state entry or state attribute.
> 
> If it does fine a state entry, we copy over the session number from that state entry.
> 
> fr_state_to_request runs before authorize, so that'd meet your requirement :)
> 
>> I never understood why State mutates on each roundtrip ;o)
> 
> Hmm, I think the idea might have been to add support for diverse proxy paths eventually, in which case you can't rely on just the request ID.

OK, request counter switched to a proper C11 atomic uin64_t.

Added seq_start to request and fr_state_entry_t.

Exposed with %s (request number is %n, so going for consistency with the one letter expansions).

%s gets you the request number that initiated this sequence of requests.  Avoids another atomic counter, which whilst they aren't the most expensive things, still aren't free.

... and oh joy, the compiler in travis is so old it doesn't ship with stdatomic.h, I guess i'll have to go fix that.

I had a pass at trying to group requests in the same conversation together, it's not very good though, so will likely need to change.

We do need some way of marking requests in the same conversation together.  Alan and I discussed just printing the start number once, but for me a major advantage in displaying something that joins the requests together, is that you can grep for a sequence of log messages in debug output, so you need the number somewhere in each line.

If you need something unique then:

	%{md5:%t%s}

Should do that.

Building session IDs is something separate for what I wrote this code for.  I need a way of extracting complete EAP conversations out of debug logs, any other uses you find for it are happy side effects :)

--

Though if you do want to create unique session IDs... Might also be an idea to record the time when the server started processing requests (when the event loop started) with high resolution.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

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


More information about the Freeradius-Users mailing list