<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
Does anyone have an example of how to use this
"Cached-Session-Policy" which is applied to the cached session?<br>
<br>
eap.conf cache section reads:<br>
<blockquote>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.<br>
</blockquote>
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?<br>
<br>
The notes also say:<br>
<blockquote># You probably also want "use_tunneled_reply = yes"
when using fast session resumption.<br>
</blockquote>
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.<br>
<br>
Debug output:<br>
<br>
First time that responds correctly given a VLAN.<br>
<br>
[snipped]<br>
<br>
[peap] Using saved attributes from the original Access-Accept<br>
Tunnel-Private-Group-Id:0 = "316"<br>
Tunnel-Type:0 = VLAN<br>
Tunnel-Medium-Type:0 = IEEE-802<br>
User-Name = "jd187"<br>
[peap] Saving response in the cache<br>
[eap] Freeing handler<br>
++[eap] returns ok<br>
WARNING: Empty post-auth section. Using default return values.<br>
# Executing section post-auth from file
/services/freeradius/etc/raddb//sites-enabled/dvlan-1x-working<br>
} # server dvlan-1x-test1<br>
Sending Access-Accept of id 157 to 128.61.2.253 port 1645<br>
Tunnel-Private-Group-Id:0 = "316"<br>
Tunnel-Type:0 = VLAN<br>
Tunnel-Medium-Type:0 = IEEE-802<br>
User-Name = "jd187"<br>
MS-MPPE-Recv-Key =
0xbdc694a560b3fc4e37385fe08bb9876e11d215add69317c704fa374f462bcb0a<br>
MS-MPPE-Send-Key =
0xa039b0c10a7ef3511a68cdd837f13747c7a4adcb86dc5d73a8506f0105a9ced4<br>
EAP-Message = 0x03080004<br>
Message-Authenticator = 0x00000000000000000000000000000000<br>
Finished request 7.<br>
Going to the next request<br>
<br>
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.<br>
<br>
[snipped]<br>
<br>
[peap] processing EAP-TLS<br>
[peap] eaptls_verify returned 7 <br>
[peap] Done initial handshake<br>
[peap] eaptls_process returned 7 <br>
[peap] EAPTLS_OK<br>
[peap] Session established. Decoding tunneled attributes.<br>
[peap] Peap state send tlv success<br>
[peap] Received EAP-TLV response.<br>
[peap] Success<br>
[peap] Adding cached attributes to the reply:<br>
User-Name = "jd187"<br>
[eap] Freeing handler<br>
++[eap] returns ok<br>
WARNING: Empty post-auth section. Using default return values.<br>
# Executing section post-auth from file
/services/freeradius/etc/raddb//sites-enabled/dvlan-1x-working<br>
} # server dvlan-1x-test1<br>
Sending Access-Accept of id 161 to 128.61.2.253 port 1645<br>
User-Name = "jd187"<br>
MS-MPPE-Recv-Key =
0x0d398b0ed22899753eac37c8b308afb8a600a4be2b35d4260470148c6f4774cc<br>
MS-MPPE-Send-Key =
0x570045c77b56ef4d327189610f20f358038cea5bda215ded4ca32eefd2a72cf2<br>
EAP-Message = 0x03040004<br>
Message-Authenticator = 0x00000000000000000000000000000000<br>
Finished request 11.<br>
<br>
<br>
<br>
</body>
</html>