Re: TLS Cache
Rodrigo Prieto <[email protected]>
| Newsgroups | gmane.comp.freeradius.user |
|---|---|
| Message-ID | <CAH1OOJ7mfyruJ+_HPGty5+BX=Mc8YVYnFdhRFthxhNo3p2vDWA@mail.gmail.com> |
Thanks Alan. El dom., 20 de julio de 2025 11:00, Alan DeKok <[email protected]> escribió: > On Jul 20, 2025, at 2:40 PM, Rodrigo Prieto <[email protected]> > wrote: > > > > 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. > > There shouldn't be many differences between TLS and TTLS-PAP for caching. > > > rlm_redis (redis): executing the query: "GET > 0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f" > > (0) rlm_redis (redis): Can't write result, insufficient space or > unsupported result > > Hmm... what's likely happening here is that the session data is larger > than 8K. And there are many buffers in v3 which are hard-coded to being 8K > in length. > > I've updated v3.2.x to have a clearer message, but that won't address > the issue. > > This issue is fixed in v4, but we'll take a look at seeing what we can > do for v3. > > Alan DeKok. > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html