Example of how to use caching (Cached-Session-Policy)?

[John Douglass]

I am apparently using the Caching improperly in regards to configuration 
in eap.conf. The first authentication works great (EAP-PEAP-MSChapv2) 
and DB lookups. The second time (with caching enabled) it appears to 
only be adding the User-Name attribute to the reply. I see the comments 
in the file "eap.conf" but they don't go very far into explaining how to 
get certain attributes saved INTO the cache or pulled out of it.

Does anyone have an example of how to use this "Cached-Session-Policy" 
which is applied to the cached session?

eap.conf cache section reads:

    The "Cached-Session-Policy" is the name of a policy which should be
    applied to the cached session.  This policy can be used to assign
    VLANs, IP addresses, etc.  It serves as a useful way to re-apply the
    policy from the original Access-Accept to the subsequent
    Access-Accept for the cached session.

What exactly am I supposed to store into the attribute 
"Cached-Session-Policy"? Is this referring to a policy within the file 
"policy.conf" that will run and extract attributes according to the 
function there or is it something else?

The notes also say:

    #  You probably also want "use_tunneled_reply = yes" when using fast
    session resumption.

And I have turned that on everywhere I could find, but it doesn't appear 
to be even saving the 1st values of Tunnel-Private-Group-Id.

Debug output:

First time that responds correctly given a VLAN.

[snipped]

[peap] Using saved attributes from the original Access-Accept
     Tunnel-Private-Group-Id:0 = "316"
     Tunnel-Type:0 = VLAN
     Tunnel-Medium-Type:0 = IEEE-802
     User-Name = "jd187"
[peap] Saving response in the cache
[eap] Freeing handler
++[eap] returns ok
   WARNING: Empty post-auth section.  Using default return values.
# Executing section post-auth from file 
/services/freeradius/etc/raddb//sites-enabled/dvlan-1x-working
} # server dvlan-1x-test1
Sending Access-Accept of id 157 to 128.61.2.253 port 1645
     Tunnel-Private-Group-Id:0 = "316"
     Tunnel-Type:0 = VLAN
     Tunnel-Medium-Type:0 = IEEE-802
     User-Name = "jd187"
     MS-MPPE-Recv-Key = 
0xbdc694a560b3fc4e37385fe08bb9876e11d215add69317c704fa374f462bcb0a
     MS-MPPE-Send-Key = 
0xa039b0c10a7ef3511a68cdd837f13747c7a4adcb86dc5d73a8506f0105a9ced4
     EAP-Message = 0x03080004
     Message-Authenticator = 0x00000000000000000000000000000000
Finished request 7.
Going to the next request

After attempting a second auth which appears to bypass the logic to 
assign a VLAN but doesn't appear to be adding it to the response from 
the cache at all.

[snipped]

[peap] processing EAP-TLS
[peap] eaptls_verify returned 7
[peap] Done initial handshake
[peap] eaptls_process returned 7
[peap] EAPTLS_OK
[peap] Session established.  Decoding tunneled attributes.
[peap] Peap state send tlv success
[peap] Received EAP-TLV response.
[peap] Success
[peap] Adding cached attributes to the reply:
     User-Name = "jd187"
[eap] Freeing handler
++[eap] returns ok
   WARNING: Empty post-auth section.  Using default return values.
# Executing section post-auth from file 
/services/freeradius/etc/raddb//sites-enabled/dvlan-1x-working
} # server dvlan-1x-test1
Sending Access-Accept of id 161 to 128.61.2.253 port 1645
     User-Name = "jd187"
     MS-MPPE-Recv-Key = 
0x0d398b0ed22899753eac37c8b308afb8a600a4be2b35d4260470148c6f4774cc
     MS-MPPE-Send-Key = 
0x570045c77b56ef4d327189610f20f358038cea5bda215ded4ca32eefd2a72cf2
     EAP-Message = 0x03040004
     Message-Authenticator = 0x00000000000000000000000000000000
Finished request 11.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20110420/444b8d30/attachment.html>