Hello, This is a 'me too' message I'm afraid. From the list archives I saw: ======================================================
Date: Mon, 02 Apr 2007 20:20:47 +0200 From: Alan DeKok <aland at deployingradius.com> Subject: Re: HUP in freeradius-1.1.5 + CVS results in process death. To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org> Message-ID: <4611497F.3000500 at deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Arran Cudbard-Bell wrote:
I know theres a bug report for this already, but when I HUP the process freeradius doesn't die in the same place.
If it's an issue due to incorrectly free'd memory, the crashes will be random.
There may be a fix in 1.1.6, but I'm not sure.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Looks more like a bug in rlm_tls . Dies every time on HUP, deffinatly not random... ====================================================== In our case, using freeradius 1.1.6, if I HUP the radiusd process it crashes/stops. Running 'radiusd -X', the tail part shows: ========================================================= security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms Mon May 14 13:38:54 2007 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Mon May 14 13:38:54 2007 : Error: radiusd.conf[230] Auth-Type PAP already configured - skipping Mon May 14 13:38:54 2007 : Error: radiusd.conf[234] Auth-Type MS-CHAP already configured - skipping Mon May 14 13:38:54 2007 : Info: rlm_eap_tls: Loading the certificate file as a chain Mon May 14 13:38:54 2007 : Error: rlm_eap: SSL error error:0906D06C:PEM routines:PEM_read_bio:no start line Mon May 14 13:38:54 2007 : Error: rlm_eap_tls: Error reading certificate file Mon May 14 13:38:54 2007 : Error: rlm_eap: Failed to initialize type tls Mon May 14 13:38:54 2007 : Error: radiusd.conf[1]: eap: Module instantiation failed. Mon May 14 13:38:54 2007 : Error: radiusd.conf[238] Unknown module "eap". Mon May 14 13:38:54 2007 : Error: radiusd.conf[229] Failed to parse authenticate section. ========================================================= This was running radiusd as the root user, running it as our usual non-root user caused the same output. Starting up radiusd normally shows no such error messages, so I'm not sure why it should now complain about the Auth-Type's or the certificate. Using the original radiusd.conf produces the same error messages, with a couple of extras (for the Auth-Types's system and CHAP). Any ideas? Thanks, John. -- --------------------------------------------------------------- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: John.Horne@plymouth.ac.uk Fax: +44 (0)1752 233839
In our case, using freeradius 1.1.6, if I HUP the radiusd process it crashes/stops. Running 'radiusd -X', the tail part shows:
Mon May 14 13:38:54 2007 : Error: rlm_eap_tls: Error reading certificate file
on HUP the radiusd process probably tries to switch to a non-root user. That might the source of your message. I think, however, this isn't the true reason for the reliable segfaults I'm observing on or right after HUP. BTW, I'm using EAP-TLS.
On Mon, 2007-05-14 at 15:22 +0200, inverse wrote:
In our case, using freeradius 1.1.6, if I HUP the radiusd process it crashes/stops. Running 'radiusd -X', the tail part shows:
Mon May 14 13:38:54 2007 : Error: rlm_eap_tls: Error reading certificate file
on HUP the radiusd process probably tries to switch to a non-root user. That might the source of your message.
No, I deliberately configured the server to run as root to check that. The same errors occurred. Secondly, if that was the case then the server shouldn't really start at all, but it does. The problem only occurs (as far as I am aware) after a HUP. John. -- --------------------------------------------------------------- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: John.Horne@plymouth.ac.uk Fax: +44 (0)1752 233839
Does anybody know if FreeRadius supports the MAC Authentication? If so, how? Thanks in advance, Kevin --------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
There was been a patch to mpd. It sets Caller-Id parametr. where Caller-Id is MAC address of caller station but this is NULL if caller is in other LAN
Does anybody know if FreeRadius supports the MAC Authentication? If so, how?
Thanks in advance, Kevin
--------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
Kevin J> Does anybody know if FreeRadius supports the MAC Authentication? Kevin J> If so, how? Freeradius supports ANY kind of authentication, just be sure you can get the required information from the client. Run "radiusd -sfX" and if your NAS sends the MAC address in the request, you can use that as a check-item. Have a look at share/doc/freeradius/aaa.txt and http://wiki.freeradius.org/index.php/FAQ#What.27s_with_the_commas_in_the_rad... for some guidelines. Cheers, Claudiu Filip
Kevin J schrieb:
Does anybody know if FreeRadius supports the MAC Authentication? If so, how?
Thanks in advance, Kevin
--------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html See:
http://lists.freebsd.org/pipermail/freebsd-isp/2003-September/001033.html Somtimes the Format of the MAC address the NAS sends varies. Check the correct MAC address format in the RADIUS logfiles. Michael.
John Horne wrote: ...
In our case, using freeradius 1.1.6, if I HUP the radiusd process it crashes/stops. Running 'radiusd -X', the tail part shows: ... Mon May 14 13:38:54 2007 : Error: radiusd.conf[230] Auth-Type PAP already configured - skipping Mon May 14 13:38:54 2007 : Error: radiusd.conf[234] Auth-Type MS-CHAP already configured - skipping
Those errors can be suppressed. It's probably worth doing.
Mon May 14 13:38:54 2007 : Info: rlm_eap_tls: Loading the certificate file as a chain Mon May 14 13:38:54 2007 : Error: rlm_eap: SSL error error:0906D06C:PEM routines:PEM_read_bio:no start line
Ah.... I think what's happening is that OpenSSL is caching the file from the last time it was read. So the server starts, and reads 1 certificate from the file. OpenSSL leaves the file open, or remembers where it left off. When FreeRADIUS asks OpenSSL to read the file again, OpenSSL continues from where it left off, rather than starting from the beginning of the file. That's not nice. And it's not documented as doing that. But I suspect it would work. A simple test would be to do the following: 1) put two copies of the certificate into the file, one after the other. 2) start the server and verify it works 3) HUP the server, and verify that it correctly loads the certificate 4) HUP the server again, and see that it complains. If you do that, and it works like I outlined, then I would argue that it's a bug in OpenSSL. FreeRADIUS calls SSL_new() to initialize OpenSSL, and SSL_free() to clean up after itself. But I'd bet that OpenSSL does *not* return to it's initial state after calling SSL_free(). Instead, it keeps some things cached... Knowing the explanation is nice, but I'm not sure how this lets us fix the problem. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon, 2007-05-14 at 22:56 +0200, Alan DeKok wrote:
John Horne wrote: ...
Mon May 14 13:38:54 2007 : Info: rlm_eap_tls: Loading the certificate file as a chain Mon May 14 13:38:54 2007 : Error: rlm_eap: SSL error error:0906D06C:PEM routines:PEM_read_bio:no start line
Ah.... I think what's happening is that OpenSSL is caching the file from the last time it was read. So the server starts, and reads 1 certificate from the file. OpenSSL leaves the file open, or remembers where it left off. When FreeRADIUS asks OpenSSL to read the file again, OpenSSL continues from where it left off, rather than starting from the beginning of the file.
Well I like the explanation, but unfortunately it doesn't work. Radiusd still dies at the first HUP. However, one thing I have noticed is that if I start Freeradius up from /etc/init.d (this is a CentOS server so I used 'service radiusd start'), then I can HUP the daemon once and it stays running. HUP it a second time and it fails (this is with one certificate in the file). If I start Freeradius as '/usr/sbin/radiusd -X', and HUP it, then it fails straight away. In both cases the failure messages are the same as those originally reported. John. -- --------------------------------------------------------------- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: John.Horne@plymouth.ac.uk Fax: +44 (0)1752 233839
John Horne wrote:
Well I like the explanation, but unfortunately it doesn't work. Radiusd still dies at the first HUP.
Dang.
However, one thing I have noticed is that if I start Freeradius up from /etc/init.d (this is a CentOS server so I used 'service radiusd start'), then I can HUP the daemon once and it stays running. HUP it a second time and it fails (this is with one certificate in the file). If I start Freeradius as '/usr/sbin/radiusd -X', and HUP it, then it fails straight away. In both cases the failure messages are the same as those originally reported.
Weird. Maybe adding a call to ERR_clear_error() in rlm_eap_tls.c, function init_tls_ctx(), after the call to SSL_CTX_new() ? Maybe there's a previous pending error that isn't being cleared. The "read certificate file" routine may see the old error, and think it's a new one? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue, 2007-05-15 at 16:51 +0200, Alan Dekok wrote:
Maybe adding a call to ERR_clear_error() in rlm_eap_tls.c, function init_tls_ctx(), after the call to SSL_CTX_new() ?
Okay, getting very weird! I made the change and started Freeradius (from /etc/init.d). I could repeatedly HUP the daemon, and it would stay running according to 'ps'. However, the log file only showed one line for the first HUP and nothing at all after that. The line it showed was: Tue May 15 16:48:01 2007 : Info: Reloading configuration files. If I made a change to the 'users' file, HUP'd the daemon and then tried to run radtest, the daemon died. Nothing new in the log file. If I ran strace on the daemon it showed: ====================================================== open("/etc/raddb/users", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0600, st_size=7146, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f88000 read(6, "#\n# RADIUS users authentication "..., 4096) = 4096 read(6, " Yes\n\nm3cooper Service-Ty"..., 4096) = 3050 read(6, "", 4096) = 0 read(6, "", 4096) = 0 close(6) = 0 munmap(0xb7f88000, 4096) = 0 open("/etc/raddb/acct_users", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0640, st_size=422, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f88000 read(6, "#\n#\t$Id: acct_users,v 1.4 2003/0"..., 4096) = 422 read(6, "", 4096) = 0 close(6) = 0 munmap(0xb7f88000, 4096) = 0 open("/etc/raddb/preproxy_users", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0640, st_size=1039, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f88000 read(6, "#\n# Configuration file for the "..., 4096) = 1039 read(6, "", 4096) = 0 close(6) = 0 munmap(0xb7f88000, 4096) = 0 time(NULL) = 1179244215 write(1, "Tue May 15 16:50:15 2007 : Info:"..., 60) = 60 select(6, [3 4 5], NULL, NULL, NULL) = 1 (in [3]) time(NULL) = 1179244231 recvfrom(3, "\1}\0:5\253\236\200S\237\35\371\330\302;\314\316\275 \36"..., 4096, 0, {sa_family=AF_INET, sin_port=htons(33773), sin_addr=inet_addr("127.0.0.1")}, [16]) = 58 time(NULL) = 1179244231 futex(0x73186c, FUTEX_WAKE, 1) = 1 rt_sigaction(SIGTERM, {SIG_IGN}, {0x714a00, [], 0}, 8) = 0 kill(-11002, SIGTERM) = 0 --- SIGTERM (Terminated) @ 0 (0) --- munmap(0x332000, 13584) = 0 munmap(0x55b000, 8936) = 0 munmap(0x549000, 4588) = 0 munmap(0x32f000, 11176) = 0 munmap(0x382000, 10888) = 0 munmap(0x32c000, 11480) = 0 munmap(0x1e2000, 21296) = 0 munmap(0x68c000, 24120) = 0 munmap(0x5e2000, 16096) = 0 munmap(0x922000, 4540) = 0 munmap(0x933000, 9212) = 0 unlink(NULL) = -1 EFAULT (Bad address) time(NULL) = 1179244232 write(1, "Tue May 15 16:50:32 2007 : Error"..., 71) = 71 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(11002, 11002, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- Process 11002 detached ====================================================== As can be seen it is reading through the .conf files. I don't know whether it is strace that caused the initial SIGTERM or not. If I start radiusd using '/usr/sbin/radiusd -X', then I can see each HUP causes the config files to be read. Radiusd shows at each HUP: ======================================================= Tue May 15 17:02:46 2007 : Info: Reloading configuration files. Tue May 15 17:02:46 2007 : Info: Using deprecated naslist file. Support for this will go away soon. Tue May 15 17:02:46 2007 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Tue May 15 17:02:46 2007 : Error: radiusd.conf[228] Auth-Type PAP already configured - skipping Tue May 15 17:02:46 2007 : Error: radiusd.conf[232] Auth-Type MS-CHAP already configured - skipping Tue May 15 17:02:46 2007 : Info: rlm_eap_tls: Loading the certificate file as a chain Tue May 15 17:02:46 2007 : Info: radiusd.conf Auth-Type eap already configured - skipping Tue May 15 17:02:46 2007 : Info: Ready to process requests. ======================================================= However, trying to then use radtest causes a segfault. No core file, although I have set 'allow_core_dumps'. Running an strace of the 'radiusd -X' process shows: ======================================================= open("/etc/raddb/preproxy_users", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0640, st_size=1039, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fb9000 read(6, "#\n# Configuration file for the "..., 4096) = 1039 read(6, "", 4096) = 0 close(6) = 0 munmap(0xb7fb9000, 4096) = 0 time(NULL) = 1179245444 write(1, "Tue May 15 17:10:44 2007 : Info:"..., 60) = 60 select(6, [3 4 5], NULL, NULL, NULL) = 1 (in [3]) time(NULL) = 1179245461 recvfrom(3, "\1K\0:\252Q\210\212\302\363?k\354\223z\347\20\376s\265"..., 4096, 0, {sa_family=AF_INET, sin_port=htons(33774), sin_addr=inet_addr("127.0.0.1")}, [16]) = 58 time(NULL) = 1179245461 --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 18850 detached ======================================================= John. -- --------------------------------------------------------------- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: John.Horne@plymouth.ac.uk Fax: +44 (0)1752 233839
John Horne wrote:
I made the change and started Freeradius (from /etc/init.d). I could repeatedly HUP the daemon, and it answ would stay running according to 'ps'. However, the log file only showed one line for the first HUP and nothing at all after that. The line it showed was:
Tue May 15 16:48:01 2007 : Info: Reloading configuration files.
If I made a change to the 'users' file, HUP'd the daemon and then tried to run radtest, the daemon died. Nothing new in the log file. If I ran strace on the daemon it showed:
That's encouraging. We already know that HUP is fairly broken. So strange behavior on HUP is... expected.
If I start radiusd using '/usr/sbin/radiusd -X', then I can see each HUP causes the config files to be read. Radiusd shows at each HUP:
i.e. it works. So it's an OpenSSL bug. Calling SSL_library_init() does NOT clear any errors on OpenSSL's error stack. That's bad.
However, trying to then use radtest causes a segfault. No core file, although I have set 'allow_core_dumps'. Running an strace of the 'radiusd -X' process shows:
That's bad. I'll run it under valgrind to see if it gives any more information. But it looks like the "clear error" call fixes part of the problem. The next step is to get HUP handling to work without crashing the server. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (8)
-
Alan DeKok -
Alan Dekok
-
Claudiu Filip -
inverse -
John Horne -
KES -
Kevin J -
Michael Schwartzkopff