Access RADIUS Attributes via ctrl interface?

[Michael Baird]

Thank you Jouni & Alan, at this stage just the Access-Accept.

At the moment I have added a configuration option (runtime) to specify 
which fields (from Access-Accept) should be stored. The code will be 
compile time.


Couple of implementation questions.
Would the struct 'sta_info' (ap/sta_info.h) be the correct place for 
storing this data?

And returning via ctrl interface with "ieee802_1x_get_mib_sta" 
(ap/ieee802_1x.c), or a different command?


Thanks,
Michael.

On 26/09/17 06:53, Alan DeKok wrote:
> On Sep 25, 2017, at 1:45 PM, Jouni Malinen <j at w1.fi> wrote:
>> I guess it would be reasonable to add option to save such information
>> for the duration of an association. That said, this can use quite a bit
>> of memory, so it probably make sense to make this configurable behaviour.
>    My $0.02 here would be just to cache the raw attributes from the Access-Accept.
>
> * skip the RADIUS header (20 bytes)
> * skip the various MPPE keys (~40 bytes each)
> * skip EAP-Message (4 bytes for Success)
> * skip Message-Authenticator (18 bytes)
>
>    The rest of the data will be small, typically ~100 bytes or so.  If the RADIUS server is sending lots of filter rules (i.e. 4K), well, tell the administrator to stop doing that.
>
>    If you care, max out the cache at 256 bytes, rounded down to the nearest attribute.  Discard everything after that.  That should cover 99.999% of the sane cases.
>
>> Are you thinking of mainly (only?) information from Access-Accept or
>> would there be need to store attributes from Access-Challenge as well?
>    Access-Challenge packets contain only authentication information, Proxy-State, and State.  PLEASE don't cache them.
>
>    I've seen people do all kinds of crazy things with Access-Challenge.   The less they're allowed to do that, the better.
>
>    Alan DeKok.
>
>