RE: Version 1.1.1 stops responding
Mine seg faulted as well.. (This time I didn't overwrite the log) rad2:/home/mking# /usr/sbin/freeradius -X -A >crash.log Segmentation fault rad2:/home/mking# I don't believe running /usr/sbin/freeradius -X -A is capturing anything useful. Is there something else I can do? Here's the last few lines of the freeradius -X -A rlm_detail: /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.0.1.32/auth-detail-20060324 modcall[authorize]: module "auth_log" returns ok for request 1002 modcall[authorize]: module "chap" returns noop for request 1002 modcall[authorize]: module "mschap" returns noop for request 1002 rlm_realm: No '@' in User-Name = "BSC\ddelutis", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 1002 rlm_eap: EAP packet type response id 28 length 80 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 1002 users: Matched entry DEFAULT at line 152 users: Matched entry DEFAULT at line 171 modcall[authorize]: module "files" returns ok for request 1002 modcall: leaving group authorize (returns updated) for request 1002 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1002 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11
Mine seg faulted as well.. Here's the last few lines of the freeradius -X -A
modcall: entering group authenticate for request 1002 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11
Interesting. This morning I encountered again that radiusd was claiming to be still listening on its ports, but didn't process anything any more. As other logs showed, someone logged into an Access Point via TTLS at 8:22 and at 8:25 the Nagios Monitoring system marked the RADIUS Server as critical. Scan interval for Nagios is every three minutes. So it could very well be that FreeRADIUS stopped processing packets when it tried to do TTLS. Sounds similar to your case, just that it didn't segfault. Note that we usually use TTLS it several times a day, and FreeRADIUS shows this behaviour only sporadically. I now reverted to 1.1.0 in the hope that it's better there. The way it is now is... disturbing. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter <stefan.winter@restena.lu> wrote:
Interesting. This morning I encountered again that radiusd was claiming to be still listening on its ports, but didn't process anything any more. As other logs showed, someone logged into an Access Point via TTLS at 8:22 and at 8:25 the Nagios Monitoring system marked the RADIUS Server as critical. Scan interval for Nagios is every three minutes. So it could very well be that FreeRADIUS stopped processing packets when it tried to do TTLS. Sounds similar to your case, just that it didn't segfault. Note that we usually use TTLS it several times a day, and FreeRADIUS shows this behaviour only sporadically.
That's not nice.
I now reverted to 1.1.0 in the hope that it's better there. The way it is now is... disturbing.
I agree. I don't see why it's the case, either. Maybe the re-arrangement of SSL code from rlm_eap_tls to libeap broke it, but I don't see why. Until we can get more information about what's happening (strace/ktrace, or gdb backtrace), there isn't much anyone can do to fix it. Alan DeKok.
participants (3)
-
Alan DeKok -
King, Michael -
Stefan Winter