Thanks Alan for replying. I did the test using: eapol_test -r 1 -a 127.0.0.1 -c ap.conf -s testing123 and it appears that the session is reused. It works correctly with persistdir. (18) eap_tls: Peer requested cached session: 8a6b359de164537d987b6c6bb03d83fdaff91bda8ebbbd63f6a004b69aedc768 I'm trying to use Redis and the keys are being written to the server, but I'm getting the following error when using *EAP-TLS*. If I use *TTLS-PAP*, the session is cached properly. (8) eap_tls: WARNING: (TLS) EAP Total received record fragments (216 bytes), does not equal expected data length (0 bytes) (8) eap_tls: (TLS) EAP Done initial handshake (8) eap_tls: (TLS) TLS - Handshake state - before SSL initialization (8) eap_tls: (TLS) TLS - Handshake state - Server before SSL initialization (8) eap_tls: (TLS) TLS - Handshake state - Server before SSL initialization (8) eap_tls: (TLS) TLS - recv TLS 1.3 Handshake, ClientHello (8) eap_tls: Peer requested cached session: 5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f (0) cache load { (0) update { rlm_redis (redis): Reserved connection (1) rlm_redis (redis): executing the query: "GET 0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f" (0) rlm_redis (redis): Can't write result, insufficient space or unsupported result rlm_redis (redis): Released connection (1) (0) EXPAND %{redis:GET %{request:TLS-Session-ID}} (0) --> (0) &Tmp-String-0 := (0) } # update = noop (0) if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/) { (0) if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/) -> FALSE (0) update { (0) EXPAND %{Tmp-String-0} (0) --> (0) &session-state:TLS-Session-Data := 0x (0) } # update = noop (0) } # cache load = noop (8) eap_tls: WARNING: (TLS) TLS - Failed loading persisted session: error:068000E0:asn1 encoding routines::too small 127.0.0.1:6379[1]> keys * 1) "0x0911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a369085" 2) "0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f" 127.0.0.1:6379[1]> keys * 1) "0x0911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a369085" 2) "0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f" 127.0.0.1:6379[1]> get 0x0911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a369085 "0x30820497020101020203030402c03004200911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a3690850430e44e32fb6e4b7c7e3bcc9fbc578ca41ca97110114c24d077fdc94deb97f10eb03a033d999e0da0b3d80dd0fe0d1a412ba1060204687cdec1a2050203015180a3820402308203fe308202e6a003020102020102300d06092a864886f70d01010b0500308185310b3009060355040613024652310f300d06035504080c065261646975733112301006035504070c09536f6d65776865726531153013060355040a0c0c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e6f72673118301606035504030c0f667265652e6c6f6c692e6c6f63616c301e170d3235303532373037303732315a170d3235303732363037303732315a306c310b3009060355040613024652310f300d06035504080c0652616469757331153013060355040a0c0c4578616d706c6520496e632e310f300d06035504030c066c6f6c69746f3124302206092a864886f70d0109011615757365726473647364406578616d706c652e6f726730820122300d06092a864886f70d01010105000382010f003082010a0282010100d33575358e628bacdc3f4a81b3950808552d918ab197a30328ca140928d61ceb0a4c73ca9948816c42110f572660c422bbb9a7bca8c07666a30b9bf3a885b71225d5923a4a7cf67d16aff4adf512a937651650c50dffe24165deefcfda900317370525085d490d36217e1749cc4dfd8877efd946f7cea82fb7d089b60461d38986d6e718a345c78c427bc4448097df7b040cf56e325c151e121a27fafd31aa277b96f9e2a55cc2aa56d5ada0a2122e25760a8bac1e2fea7b87538fd68454fe48bc71cd17a7fdb5cf581069b55a53b3ff8b0bc7fe1186f1d7d4e7f95bda29cb60bf61586c06412da8a3cab742c8fc8389486ba8417fafb48ee46398e2be3119690203010001a3819030818d30130603551d25040c300a06082b0601050507030230360603551d1f042f302d302ba029a0278625687474703a2f2f7777772e6578616d706c652e636f6d2f6578616d706c655f63612e63726c301d0603551d0e04160414fdd342c84af10c65a5a3b68e2a73b0fab20dcfcd301f0603551d2304183016801486bc404a6eb2660281a57519df93b8ad12757560300d06092a864886f70d01010b05000382010100a7aa375b9089fccfda8c5d7400bb617d7fcc04239f7ae7df3e0fd8c9a8f880536208ef12512d631cb7600beefde5c2521318eb76cca8b23e47cd4f21bcbdd745e6fda94a62285a3f79ebdefcbba7194fdfc562cd50ad5f7ef9a501ba6c0b2b28de4661165879e576b9e765283c37bc679fa91d33377b87202fb61ad527b7eff38f015fd38dc8d683ccc2c793abb443af69b60f280ec2012b515b0dbb78ac7b9eb9cdd6203e5a246f6ec79835bab59528ba48858ee80d3250ddf1d52d181e10897073e021211e1cbc8e2cc8f4c3b17b23f43a8801ced77e6ed9552f3da07e184150835464fe07aeb0f39357d362419b9bd6eadbe2b05c4dda267fd18bfee1df5ca4170415465220656170203078353539306563323262646330ad03020101b303020117" 127.0.0.1:6379[1]> get 0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f "0x30820497020101020203030402c03004205b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f04301e2fc32854abd41277e5335eac92c221d0d2dc0400a377521212554de2e8c05384d7291d70403290a7e9b4e0376f60dda1060204687cdec1a2050203015180a3820402308203fe308202e6a003020102020102300d06092a864886f70d01010b0500308185310b3009060355040613024652310f300d06035504080c065261646975733112301006035504070c09536f6d65776865726531153013060355040a0c0c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e6f72673118301606035504030c0f667265652e6c6f6c692e6c6f63616c301e170d3235303532373037303732315a170d3235303732363037303732315a306c310b3009060355040613024652310f300d06035504080c0652616469757331153013060355040a0c0c4578616d706c6520496e632e310f300d06035504030c066c6f6c69746f3124302206092a864886f70d0109011615757365726473647364406578616d706c652e6f726730820122300d06092a864886f70d01010105000382010f003082010a0282010100d33575358e628bacdc3f4a81b3950808552d918ab197a30328ca140928d61ceb0a4c73ca9948816c42110f572660c422bbb9a7bca8c07666a30b9bf3a885b71225d5923a4a7cf67d16aff4adf512a937651650c50dffe24165deefcfda900317370525085d490d36217e1749cc4dfd8877efd946f7cea82fb7d089b60461d38986d6e718a345c78c427bc4448097df7b040cf56e325c151e121a27fafd31aa277b96f9e2a55cc2aa56d5ada0a2122e25760a8bac1e2fea7b87538fd68454fe48bc71cd17a7fdb5cf581069b55a53b3ff8b0bc7fe1186f1d7d4e7f95bda29cb60bf61586c06412da8a3cab742c8fc8389486ba8417fafb48ee46398e2be3119690203010001a3819030818d30130603551d25040c300a06082b0601050507030230360603551d1f042f302d302ba029a0278625687474703a2f2f7777772e6578616d706c652e636f6d2f6578616d706c655f63612e63726c301d0603551d0e04160414fdd342c84af10c65a5a3b68e2a73b0fab20dcfcd301f0603551d2304183016801486bc404a6eb2660281a57519df93b8ad12757560300d06092a864886f70d01010b05000382010100a7aa375b9089fccfda8c5d7400bb617d7fcc04239f7ae7df3e0fd8c9a8f880536208ef12512d631cb7600beefde5c2521318eb76cca8b23e47cd4f21bcbdd745e6fda94a62285a3f79ebdefcbba7194fdfc562cd50ad5f7ef9a501ba6c0b2b28de4661165879e576b9e765283c37bc679fa91d33377b87202fb61ad527b7eff38f015fd38dc8d683ccc2c793abb443af69b60f280ec2012b515b0dbb78ac7b9eb9cdd6203e5a246f6ec79835bab59528ba48858ee80d3250ddf1d52d181e10897073e021211e1cbc8e2cc8f4c3b17b23f43a8801ced77e6ed9552f3da07e184150835464fe07aeb0f39357d362419b9bd6eadbe2b05c4dda267fd18bfee1df5ca4170415465220656170203078353539306563323262646330ad03020101b303020117" (9) eap_ttls: (TLS) EAP Done initial handshake (9) eap_ttls: (TLS) TTLS - Handshake state - before SSL initialization (9) eap_ttls: (TLS) TTLS - Handshake state - Server before SSL initialization (9) eap_ttls: (TLS) TTLS - Handshake state - Server before SSL initialization (9) eap_ttls: (TLS) TTLS - recv TLS 1.3 Handshake, ClientHello (9) eap_ttls: Peer requested cached session: ad0985c9cf07b899bb929529c09ca161d27bd690af1be4acb1c29a5fa0545ea0 (0) cache load { (0) update { rlm_redis (redis): Reserved connection (1) rlm_redis (redis): executing the query: "GET 0xad0985c9cf07b899bb929529c09ca161d27bd690af1be4acb1c29a5fa0545ea0" rlm_redis (redis): Released connection (1) (0) EXPAND %{redis:GET %{request:TLS-Session-ID}} (0) --> 0x308191020101... (truncated) (0) &Tmp-String-0 := 0x308191020101... (0) } # update = noop (0) if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/) { (0) if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/) -> FALSE (0) update { (0) EXPAND %{Tmp-String-0} (0) --> 0x308191020101... (0) &session-state:TLS-Session-Data := 0x308191020101... (0) } # update = noop (0) } # cache load = noop (9) eap_ttls: Successfully restored session ad0985c9cf07b899bb929529c09ca161d27bd690af1be4acb1c29a5fa0545ea0 I didn't post the full debug because it's very long — but if you need it, I can share it. Thanks. El dom, 20 jul 2025 a las 9:01, Alan DeKok via Freeradius-Users (< freeradius-users@lists.freeradius.org>) escribió:
On Jul 19, 2025, at 1:05 PM, Rodrigo Prieto <rodrigoprieto2019@gmail.com> wrote:
Hello, I'm currently working on configuring the TLS cache and noticed
that,
upon reconnection, the client rewrites both files (.asn1 and .vps) in the configured directory.
That's fine, If the files aren't changed, then the TLS resumption data could be used multiple times.
i.e. it could also share it with other systems, and then multiple systems could get online.
As a result, the files change every tme.
From what I understand, it should reuse the information stored in those files to avoid reestablishing the TLS connection from scratch.
Changing the files doesn't mean that it re-establishes the TLS connection from scratch.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html