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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.