On 25/02/16 13:42, Alan DeKok wrote:
On Feb 25, 2016, at 8:28 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
I'm trying to figure out how to cache other stuff with the TLS attributes that can be pulled back later on.
The TLS caching in v2 is (a) just a few hard-coded attributes, or (b), files on disk. The explanations in the EAP module work.
For v3.0, the same largely applies. We've re-worked the on-disk TLS cache a bit, but it *should* work identically. We've also added a cache module, which can cache just about anything.
In 3.1, we've gotten rid of the on-disk TLS cache, and expanded the cache module to cache to just about anywhere... including disk. So the functionality is at least equivalent, if a little different.
So... what's going wrong?
In inner post-auth we are doing this to populate session-state from the current set of attributes: update outer.session-state { User-Name := &User-Name Inner-User-Name := &User-Name } Is this sufficient to ensure Inner-User-Name ends up in the TLS cache? This previous posting from Arran seems to suggest it is: http://lists.freeradius.org/pipermail/freeradius-users/2016-January/081598.h... In outer post-auth we are doing this to copy the session-state back before acting upon the information: update { &reply: += &session-state: } Here's today debug log: http://pastebin.com/ZD1nmAvC I'm looking at line 4576 (a resumed session) where the outer post-auth is supposed to copy attributes to reply from session-state and fails to do so. The session-state list should be being populated in inner post-auth but the server seems to skip this for resumed sessions and the list is empty. Contrast to line 4014 which is a non-resumed session and the debug clearly shows that session-state contains useful things which are then copied to the outer. Thanks, Jonathan