I recently (yesterday) upgraded from UCS 5.0.9 to 5.2.0 and since then freeradius seems to have some problem.
When freeradius is started via systemd (or the WebUI) and I try to authenticate a wireless device, I get the following error in the radius.log:
*Sun Feb 23 17:24:53 2025 : ERROR: (33) mschap: ERROR: Program returned code (1) and output ''*
*Sun Feb 23 17:24:53 2025 : Auth: (33) Login incorrect (mschap: Program returned code (1) and output ''): [username/<via Auth-Type = eap>] (from client AP_name port 0 via TLS tunnel)*
*Sun Feb 23 17:24:53 2025 : Auth: (34) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [username/<via Auth-Type = eap>] (from client AP_name port 1 cli 80-86-D9-4B-F8-16)*
(username and AP_name are vars for the obfuscated original values)
When I stop freeradius (via systemd) and start it manually by freeradius -f,
everything works like a charm and all my clients are authenticated.
When freeradius is started (doesn’t matter which way), I get the following output: ber_get_next failed, errno=11.
When starting with systemd, the output of systemctl status freeradius.service looks like:
â—Ź freeradius.service - FreeRADIUS multi-protocol policy server
Loaded: loaded (/lib/systemd/system/freeradius.service; enabled; preset: enabled)
Active: active (running) since Sun 2025-02-23 17:33:50 CET; 5min ago
Docs: man:radiusd(8)
man:radiusd.conf(5)
http://wiki.freeradius.org/
http://networkradius.com/doc/
Process: 630277 ExecStartPre=/usr/sbin/freeradius $FREERADIUS_OPTIONS -Cx -lstdout (code=exited, status=0/SUCCESS)
Main PID: 630278 (freeradius)
Status: "Processing requests"
Tasks: 6 (limit: 9432)
Memory: 89.2M (limit: 2.0G)
CPU: 1.217s
CGroup: /system.slice/freeradius.service
└─630278 /usr/sbin/freeradius -f
Feb 23 17:33:50 hostname freeradius[630277]: Compiling Post-Auth-Type REJECT for attr Post-Auth-Type
Feb 23 17:33:50 hostname freeradius[630277]: Compiling Autz-Type Status-Server for attr Autz-Type
Feb 23 17:33:50 hostname freeradius[630277]: radiusd: #### Skipping IP addresses and Ports ####
Feb 23 17:33:50 hostname freeradius[630277]: Configuration appears to be OK
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname freeradius[630278]: ber_get_next failed, errno=11.
Feb 23 17:33:50 hostname systemd[1]: Started freeradius.service - FreeRADIUS multi-protocol policy server.
As a workaround (in order to keep my users connected) I start freeradius manually by issuing: freeradius -f &
This way everything seems to work.
The problem appeared after the upgrade to 5.2.0. All packages are up2date.
Maybe someone got similar problems and has a hint for me.
Thanks in advance.
Hallo!
Wir haben das selbe Problem, es scheint an einem Schutzmechnismus von der systemd Unit-File zu liegen. Ich bin jetzt leider nicht dazugekommen, herauszubekommen, welcher oder warum - aber hier unser Workaround:
systemctl edit freeradius
### Anything between here and the comment below will become the new contents of the file"
[Service]
NoNewPrivileges=false
PrivateTmp=false
ProtectControlGroups=false
ProtectKernelModules=false
ProtectKernelTunables=false
SystemCallArchitectures=
ReadOnlyDirectories=
ReadWriteDirectories=
AmbientCapabilities=
MemoryLimit=infinity
### Lines below this comment will be discarded
Das ganze sollte natĂĽrlich wieder entfernt werden, sobald das Problem richtig von Univention addressiert wurde - aber aktuell funktioniert es zumindest fĂĽr uns.
Thank you for your hint.
I’ve tested a bit with the different options and values and came to the conclusion, that already
AmbientCapabilities=CAP_DAC_OVERRIDE
solves the problem. So the rest of the options could be left with default settings.
So it could be a permission problem when starting freeradius via systemd.
During various service-restarts I noticed the following messages:
Unit uses MemoryLimit=; please use MemoryMax= instead. Support for MemoryLimit= will be removed soon.
The first one showed up even if freeradius was started manually. The seconed one is more of an information about an upcoming change.
So both of them shouldn’t have to do with the problem itself.
Könnte es vielleicht sein, dass dem User freerad nicht erlaubt ist anfragen zu stellen?
Sonst wĂĽrde ja die Nutzung im Debug-Modus ja auch nicht funktionieren!
Habe das selbe Problem nach dem Update auf die neueste Version.
LG
mittles systemctl edit freeradius funktioniert, scheint es sich um ein Berechtigungsproblem (Zugriff auf bestimmte Dateien) zu handeln.
Welche Dateien das genau sind könnte man evtl. mittels aktivem auditd versuchen zu ermitteln.
Da fĂĽr mich der beschriebene Workaround funktioniert, habe ich vorerst nicht weiter geforscht. Ich hoffe erstmal weiterhin auf einen Fix seitens UCS
I just experienced this problem after updating. For me in the /etc/freeradius/3.0/ directory some files, directories, symlinks had had their permissions updated to root:root instead of the freeradius user and group which explains why running freeradius -X works as root but not as the freeradius service/user.
I CD’d to that directory and just ran chown freerad:freerad on each file and directory that was set up with root as owner or group and then restarted freeradius and that solved my problem.
A change to the service is not normally necessary. I checked the file permissions. One file had incorrect permissions. After correcting this, radius worked normally again.
I don’t have this file /etc/freeradius/3.0/ldap-groups-attrs.conf and therefore I can’t confirm that this solves the problem too. But for sure it’s a permission problem (AmbientCapabilities=CAP_DAC_OVERRIDE should allow ignoring the permissions - for this reason it works if set, even if the permissions are not set correctly).
Could anyone show up, what the permissions for the files in the folder /etc/freeradius/3.0/ should be?
My folder looks like this:
:~# ls -l /etc/freeradius/3.0/
insgesamt 208
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:45 certs
-rw-r----- 1 freerad freerad 8010 23. Feb 16:52 clients.conf
-rw-r----- 1 freerad freerad 8323 19. Aug 2023 clients.conf.dpkg-dist
-rw-r--r-- 1 root root 1408 27. Feb 2019 clients.conf.example
-rw------- 1 freerad root 361 22. Feb 18:01 clients.univention.conf
-rw-r----- 1 freerad freerad 1420 19. Aug 2023 dictionary
-rw-r----- 1 freerad freerad 2661 27. Nov 2017 experimental.conf
lrwxrwxrwx 1 root root 28 19. Aug 2023 hints -> mods-config/preprocess/hints
lrwxrwxrwx 1 root root 33 19. Aug 2023 huntgroups -> mods-config/preprocess/huntgroups
drwxr-xr-x 2 freerad freerad 4096 25. Mai 05:55 mods-available
drwxr-xr-x 11 freerad freerad 4096 22. Feb 17:45 mods-config
drwxr-xr-x 2 freerad freerad 4096 8. Mär 11:23 mods-enabled
-rw-r----- 1 freerad freerad 52 27. Nov 2017 panic.gdb
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:51 policy.d
-rw-r----- 1 root freerad 488 22. Feb 17:51 proxy.conf
-rw-r----- 1 freerad freerad 29206 19. Aug 2023 proxy.conf.debian
-rw-r----- 1 root freerad 31470 22. Feb 18:01 radiusd.conf
-rw-r----- 1 freerad freerad 30773 19. Aug 2023 radiusd.conf.debian
-rw-r----- 1 freerad freerad 20754 19. Aug 2023 README.rst
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:51 sites-available
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:44 sites-enabled
-rw-r----- 1 freerad freerad 3470 27. Nov 2017 templates.conf
-rw-r----- 1 freerad freerad 8536 27. Nov 2017 trigger.conf
lrwxrwxrwx 1 root root 27 19. Aug 2023 users -> mods-config/files/authorize
We have received new information regarding the described error and its behavior.
Would it be possible for you to provide the output of the following command from the system where the error occurred on UCS 5.2?
ls -la /etc/freeradius.secret
Many thanks and best regards,
MiracErde
Univention Support
Thank you for the information. The permissions of this file are updated every 21 days (every time the server credentials are automatically rotated). You posted your listing of /etc/freeradius/3.0/ 24 days ago, so it may have already taken care of itself. Do you have the ability to repeat the test without the workaround (i.e. remove the capability)?
Please note: We are still unable to reproduce the bug on our test machines and are looking for any clues we can get.
systemctl restart freeradius.service
as soon as I try to connect to my WiFi from a device, I get the following output in the radius.log-file (/var/log/freeradius/radius.log)
Sat Jun 21 10:56:27 2025 : ERROR: (8) mschap: ERROR: Program returned code (1) and output ''
Sat Jun 21 10:56:27 2025 : Auth: (8) Login incorrect (mschap: Program returned code (1) and output ''): [*myusername*/<via Auth-Type = eap>] (from client *accesspointname* port 0 via TLS tunnel)
Sat Jun 21 10:56:27 2025 : Auth: (9) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [*myusername*/<via Auth-Type = eap>] (from client *accesspointname* port 1 cli 80-86-D9-77-7A-16)
Restoring the previous option in the systemd unit-file resolves the problem again.
Here an actual output of the folder-permissions:
:~# ls -la /etc/freeradius
insgesamt 32
drwxr-s--- 4 freerad freerad 4096 11. Feb 2020 .
drwxr-xr-x 147 root root 20480 16. Jun 01:08 ..
drwxr-xr-x 9 freerad freerad 4096 23. Feb 16:52 3.0
drwxr-sr-x 2 root freerad 4096 22. Feb 18:01 ssl
:~# ls -la /etc/freeradius/3.0/
insgesamt 216
drwxr-xr-x 9 freerad freerad 4096 23. Feb 16:52 .
drwxr-s--- 4 freerad freerad 4096 11. Feb 2020 ..
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:45 certs
-rw-r----- 1 freerad freerad 8010 23. Feb 16:52 clients.conf
-rw-r----- 1 freerad freerad 8323 19. Aug 2023 clients.conf.dpkg-dist
-rw-r--r-- 1 root root 1408 27. Feb 2019 clients.conf.example
-rw------- 1 freerad root 361 22. Feb 18:01 clients.univention.conf
-rw-r----- 1 freerad freerad 1420 19. Aug 2023 dictionary
-rw-r----- 1 freerad freerad 2661 27. Nov 2017 experimental.conf
lrwxrwxrwx 1 root root 28 19. Aug 2023 hints -> mods-config/preprocess/hints
lrwxrwxrwx 1 root root 33 19. Aug 2023 huntgroups -> mods-config/preprocess/huntgroups
drwxr-xr-x 2 freerad freerad 4096 21. Jun 05:55 mods-available
drwxr-xr-x 11 freerad freerad 4096 22. Feb 17:45 mods-config
drwxr-xr-x 2 freerad freerad 4096 8. Mär 11:23 mods-enabled
-rw-r----- 1 freerad freerad 52 27. Nov 2017 panic.gdb
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:51 policy.d
-rw-r----- 1 root freerad 488 22. Feb 17:51 proxy.conf
-rw-r----- 1 freerad freerad 29206 19. Aug 2023 proxy.conf.debian
-rw-r----- 1 root freerad 31470 22. Feb 18:01 radiusd.conf
-rw-r----- 1 freerad freerad 30773 19. Aug 2023 radiusd.conf.debian
-rw-r----- 1 freerad freerad 20754 19. Aug 2023 README.rst
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:51 sites-available
drwxr-xr-x 2 freerad freerad 4096 22. Feb 17:44 sites-enabled
-rw-r----- 1 freerad freerad 3470 27. Nov 2017 templates.conf
-rw-r----- 1 freerad freerad 8536 27. Nov 2017 trigger.conf
lrwxrwxrwx 1 root root 27 19. Aug 2023 users -> mods-config/files/authorize
Let me know if I can provide more infos.
Just a guess - til now it looks like to be a problem when upgrading to 5.2. None of the comments here spoke about a fresh install (didn’t try this for myself).
Same problem over here, since upgrade to UCS 5.2-2 from latest 5.0 (4 days ago).
The problem started today at 00:01 which may be a hint to a rotated file, maybe in conjuntion with caches.
The suggested workaround by editing the systemd unit file resolved the problem.
Current permissions:
# ls -lah /etc/freeradius.secret
-r--r----- 1 freerad freerad 20 19. Jun 13:22 /etc/freeradius.secret
# ls -lah /etc/freeradius/*
/etc/freeradius/3.0:
insgesamt 208K
drwxr-xr-x 9 freerad freerad 4,0K 20. Jun 21:49 .
drwxr-s--- 4 freerad freerad 4,0K 19. Jun 13:22 ..
-rw-r----- 1 freerad freerad 21K 19. Aug 2023 README.rst
drwxr-xr-x 2 freerad freerad 4,0K 19. Jun 13:22 certs
-rw-r----- 1 freerad freerad 8,2K 19. Aug 2023 clients.conf
-rw-r----- 1 freerad freerad 1,4K 8. Apr 2024 clients.conf.example
-rw------- 1 freerad root 950 20. Jun 21:49 clients.univention.conf
-rw-r----- 1 freerad freerad 1,4K 19. Aug 2023 dictionary
-rw-r----- 1 freerad freerad 2,6K 19. Aug 2023 experimental.conf
lrwxrwxrwx 1 freerad freerad 28 19. Aug 2023 hints -> mods-config/preprocess/hints
lrwxrwxrwx 1 freerad freerad 33 19. Aug 2023 huntgroups -> mods-config/preprocess/huntgroups
drwxr-xr-x 2 freerad freerad 4,0K 22. Jun 05:55 mods-available
drwxr-xr-x 10 freerad freerad 4,0K 19. Jun 13:22 mods-config
drwxr-xr-x 2 freerad freerad 4,0K 19. Jun 13:22 mods-enabled
-rw-r----- 1 freerad freerad 52 19. Aug 2023 panic.gdb
drwxr-xr-x 2 freerad freerad 4,0K 19. Jun 13:22 policy.d
-rw-r----- 1 root freerad 482 20. Jun 10:41 proxy.conf
-rw-r----- 1 freerad freerad 29K 19. Aug 2023 proxy.conf.debian
-rw-r----- 1 root freerad 31K 20. Jun 18:09 radiusd.conf
-rw-r----- 1 root freerad 31K 19. Jun 13:22 radiusd.conf.debian
drwxr-xr-x 2 freerad freerad 4,0K 20. Jun 10:42 sites-available
drwxr-xr-x 2 freerad freerad 4,0K 19. Jun 13:22 sites-enabled
-rw-r----- 1 freerad freerad 3,4K 19. Aug 2023 templates.conf
-rw-r----- 1 freerad freerad 8,4K 19. Aug 2023 trigger.conf
lrwxrwxrwx 1 freerad freerad 27 19. Aug 2023 users -> mods-config/files/authorize
/etc/freeradius/ssl:
insgesamt 24K
drwxr-sr-x 2 root freerad 4,0K 19. Jun 13:22 .
drwxr-s--- 4 freerad freerad 4,0K 19. Jun 13:22 ..
-r--r--r-- 1 root freerad 5,7K 19. Jun 13:22 cert.pem
-r--r--r-- 1 root freerad 245 19. Jun 13:22 dh
-r--r----- 1 root freerad 1,7K 19. Jun 13:22 private.key
Nothing helpful in /valog/freeradius/radius.log
Only this error is logged:
Sat Jun 21 00:01:25 2025 : Debug: (2026) modsingle[authorize]: returned from ntdomain (rlm_realm)
Sat Jun 21 00:01:25 2025 : Debug: (2026) [ntdomain] = noop
Sat Jun 21 00:01:25 2025 : Debug: (2026) policy user_name_is_mac {
Sat Jun 21 00:01:25 2025 : Debug: (2026) if (&User-Name && (&User-Name =~ /^([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})$/i)) {
Sat Jun 21 00:01:25 2025 : Debug: Clearing 7 old matches
Sat Jun 21 00:01:25 2025 : Debug: (2026) if (&User-Name && (&User-Name =~ /^([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})[^0-9a-f]?([0-9a-f]{2})$/i)) -> FALSE
Sat Jun 21 00:01:25 2025 : Debug: (2026) else {
Sat Jun 21 00:01:25 2025 : Debug: (2026) modsingle[authorize]: calling noop (rlm_always)
Sat Jun 21 00:01:25 2025 : Debug: (2026) modsingle[authorize]: returned from noop (rlm_always)
Sat Jun 21 00:01:25 2025 : Debug: (2026) [noop] = noop
Sat Jun 21 00:01:25 2025 : Debug: (2026) } # else = noop
Sat Jun 21 00:01:25 2025 : Debug: (2026) } # policy user_name_is_mac = noop
Sat Jun 21 00:01:25 2025 : Debug: (2026) if (control:Auth-Type == "CSID" && EAP-Message ) {
Sat Jun 21 00:01:25 2025 : ERROR: (2026) Failed retrieving values required to evaluate condition
Sat Jun 21 00:01:25 2025 : Debug: (2026) modsingle[authorize]: calling eap (rlm_eap)
Sat Jun 21 00:01:25 2025 : Debug: (2026) eap: Peer sent EAP Response (code 2) ID 110 length 24
Sat Jun 21 00:01:25 2025 : Debug: (2026) eap: EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize
Sat Jun 21 00:01:25 2025 : Debug: (2026) modsingle[authorize]: returned from eap (rlm_eap)
Sat Jun 21 00:01:25 2025 : Debug: (2026) [eap] = ok
Sat Jun 21 00:01:25 2025 : Debug: (2026) } # authorize = ok
Sat Jun 21 00:01:25 2025 : Debug: (2026) Found Auth-Type = eap
Sat Jun 21 00:01:25 2025 : Debug: (2026) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
Sat Jun 21 00:01:25 2025 : Debug: (2026) Auth-Type eap {
Sat Jun 21 00:01:25 2025 : Debug: (2026) modsingle[authenticate]: calling eap (rlm_eap)
Sat Jun 21 00:01:25 2025 : Debug: (2026) eap: Peer sent packet with method EAP Identity (1)
Sat Jun 21 00:01:25 2025 : Debug: (2026) eap: Calling submodule eap_peap to process data
Sat Jun 21 00:01:25 2025 : Debug: (2026) eap_peap: (TLS) Initiating new session
Sat Jun 21 00:01:25 2025 : Debug: (2026) eap_peap: [eaptls start] = request
If you have implemented the workaround from