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@xxxxx> 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.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
