Hi, But I had an impression that in-memory and persistent cache behave exactly the same way except persistent cache can survive daemon restarts. So what you are saying is that EAP-TLS session resumption works only when persistent disk caching is enabled? Regards, Jyri. On 18 Jun 2015, at 14:20, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 18, 2015, at 2:22 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
Compiled 3.0.x (3.0.9) from git, the result is still the same, Win7 supplicant EAP-TLS caching still triggers resumed session check-eap-tls code failure because %{TLS-*} variables are not propagated from cache.
Inital session stores data in cache:
Unfortunately, no. It's not.
Thu Jun 18 08:14:58 2015 : Debug: (6) eap_tls: Serialising session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a, and storing in cache Thu Jun 18 08:14:58 2015 : Debug: (7) eap_tls: Saving session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a vps 0x283f220 in the cache
If it *actually* stored the data, you would also see a message like this:
Wrote session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a to 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a.asn1 (65544bytes)"
I've pushed a fix to the debug messages which makes it clearer when the session is actually cached, and when it isn't.
So far as I can tell, you're not setting "persist_dir". That's why it's not doing any caching.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html