Cached attributes

[Jonathan Gazeley]

On 25/02/16 13:42, Alan DeKok wrote:
> On Feb 25, 2016, at 8:28 AM, Jonathan Gazeley <Jonathan.Gazeley at 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.html

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