Dear Mantainer,

Our RADIUS service primarily provides authentication for a Wi-Fi network that uses the EAP-TTLS-PAP method.
Used modules include, among others, eap, ldap, linelog, pap, and sql_log.
Over 13K different users are authenticated daily.
In Debian 11, freeradius service had stable memory consumption.
After performing a dist-upgrade to Debian 12, freeradius consumes memory without limit.
Freeradius process increases memory usage daily.
When RAM is scarce, freeradius starts using swap until it approaches 100% of virtual memory.
We have increased RAM and swap several times recently.
Now, the time frame for memory exhaustion has extended from days to weeks.
We cannot debug on production server.
We have a preproduction freeradius enviroment with same configuration.
We have started freeradius and launched a EAP-TTLS-PAP request using eapol_test utility.
We have obtained a report with Valgrind following instructions in /usr/share/doc/freeradius/bugs.gz (*).
We attach the report "valgrind.txt".

(*)
# uname -a
Linux vm075151 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux
# valgrind --tool=memcheck --leak-check=full --log-file=/tmp/valgrind.txt freeradius -Xm

Thank you.

Regards,

Hi,

 >

You are the first to report it, but that does not make it wrong.

Could you test with the 3.2.6 upstream version in bookworm-backports as
well? This is the current upstream version, if it happens there as well
we might have a change of upstream taking care of it.

Bernhard

Hi,

We've tested with freeradius 3.2.6 in preproduction enviroment.
We've installed these packages from bookworm-backports target release (*).
In debug mode (freeradius -X) we could see several warnings like this (**).
Authentication EAP-TTLS-PAP seems to work fine.
We could make an effort and test in production next week.
The memory issue manifests after several weeks; we need a guarantee of proper functionality during this time.
The warning seems serious. Could you give us any advice about this?

Thanks

(*)

         ii  freeradius 3.2.6+dfsg-2~bpo12+1           amd64        high-performance and highly configurable RADIUS server
         ii  freeradius-common 3.2.6+dfsg-2~bpo12+1           all          FreeRADIUS common files
         ii  freeradius-config 3.2.6+dfsg-2~bpo12+1           amd64        FreeRADIUS default config files
         ii  freeradius-ldap 3.2.6+dfsg-2~bpo12+1           amd64        LDAP module for FreeRADIUS server
         ii  freeradius-utils 3.2.6+dfsg-2~bpo12+1           amd64        FreeRADIUS client utilities
         ii  libfreeradius3 3.2.6+dfsg-2~bpo12+1           amd64        FreeRADIUS shared library

(**)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! libldap is using GnuTLS, while FreeRADIUS is using OpenSSL
!! There may be random issues with TLS connections due to this conflict.
!! The server may also crash.
!! See https://wiki.freeradius.org/modules/Rlm_ldap for more information.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


El 6/1/25 a las 15:58, Bernhard Schmidt escribió:

Am 08.01.25 um 13:04 schrieb ATIC Sistemas Rede:

Hi,

I never noticed it myself (not using rlm_ldap), but it seems like an old
issue (maybe the warning is new). You can find bugs from 2020 against
openldap asking for building against openssl specifically due to
FreeRADIUS warnings.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976991
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000821

However, I'm not aware of any bug report due to this, and
https://wiki.freeradius.org/modules/Rlm_ldap#errors-with-ldap-over-tls-connections
is about building LDAP with Mozilla NSS, not with GnuTLS.

I guess switching openldap to openssl is too late before Trixie,
especially since it may as well affect other openldap reverse
dependencies that use GnuTLS.

I guess you will have to try it.

Bernhard

Hi,

As it happens, the switch to openssl has recently been uploaded to
experimental (thanks mjt!), with the goal of getting it into trixie.
Missed closing this bug with the upload to experimental, but setting the
fixed version now.

thanks,
Ryan

Hi,

On January 14th, we installed freeradius 3.2.6 in production enviroment.
During this three weeks, service freeradius operated normally with no isuues. Memory usage was stable around 100MB.
Before applying backport, within three weeks, memory usage could reach 1500MB.
We'll install the backport on all freeradius servers and will waiting to debian trixie full-upgrade.

Thanks.


El 8/1/25 a las 22:45, Bernhard Schmidt escribió:

On 03/02/25 09:14 AM, ATIC Sistemas Rede wrote:

Hi,

Thanks a lot. I still can't see that in our environment, but I'm happy
to learn that this bug appears to be fixed upstream.

If anyone can come up with a specific testcase / commit to be backported
I will happily take a look, otherwise please stay with the backport
until Trixie has been released.

Bernhard