Re: Voip database
On Tue, Jan 4, 2011 at 2:40 PM, miha- miha_zou...@hotmail.com wrote: Currently, there is a password matching issue because the User-Password encoding is different during the Authentication from the Authorization. During the Authentication step, the Centile's radius client send a User-Password encrypted with the secret. But during the Authorization step, we don't expect the Radius server to check again this password (which is sent anyway, I don't know if this is a bug or if it is required by Eyebill...). So they deliberately do NOT encrypt password with the secret? That's just silly. They need to fix it. The Authorization request contains the attribute Acct-Status-Type with the value 17 that means authorize only. Shouldn't it be RADIUS Attribute 6, Service-Type? http://www.ietf.org/assignments/radius-types/radius-types.xml It also contains the attribute Message-Authenticator with the digest value. So Freeradius should use those two attributes to accept or reject the request instead of the User-Name and User-Password. If only pap is involved (which, from your debug log seems to be the case), you might be able to play with unlang and set Auth-Type := Accept for certain conditions (e.g. check whether Message-Authenticator exists, and whether it matches a certain value). http://wiki.freeradius.org/index.php/FAQ#How_do_I_permit_access_to_any_user_regardless_of_password.3F http://freeradius.org/radiusd/man/unlang.html -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Voip database
miha- wrote: Hello, I got answere what should I do that the freeradius will work with centile. Can you help me out where can I customized this settings? ... Currently, there is a password matching issue because the User-Password encoding is different during the Authentication from the Authorization. The vendor's behavior is idiotic. Throw their software in the garbage, and buy something that works. Go ask them how to make FreeRADIUS work with their product that violates the RADIUS specifications. It's not our problem. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Problem
Hi, i use virtual server inner-tunnel in EAP config in PEAP section on EAP.conf yes...but you dont have that file in place! look! No such virtual server inner-tunnel ^ look in your sites-enabled directory. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
segfault with rlm_perl
Hi, I am running freeradius (2.1.8) with rlm_perl (5.10.1, USE_ITHREADS) on a Debian-Lenny system. The problem is radius fails with segfault – periodically and intermittently. I have no way to reliably reproduce the problem – it happens only in production, and it is impossible to reliably predict when or backtrace why. It seems that I am running into some kind of memory allocation error. Coredump type #3 (see below) is the most popular one; coredumps with backtrace going into perl seem to be rather random (it fails in different parts of libperl.so) - again, see below. I understand that freeradius has a newer version available - but I am hesitant to upgrade a production server without a very good reason. And I could not find such reason for an upgrade after reading the CHANGELOG for 2.1.10. But maybe I am wrong? Any ideas? Thank you! PS: bt for coredump #1: #0 0xb47d1ab6 in mysql_st_execute (sth=0xaf13a1a8, imp_sth=0xadf537a8) at dbdimp.c:3209 #1 0xb47da215 in XS_DBD__mysql__st_execute (my_perl=0xb831a08, cv=0xb1e16858) at mysql.xsi:588 #2 0xb70740ab in XS_DBI_dispatch () from /opt/server/lib/perl5/i686-linux-thread-multi/auto/DBI/DBI.so #3 0xb76a841e in Perl_pp_entersub () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #4 0xb76a6841 in Perl_runops_standard () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #5 0xb7641500 in Perl_call_sv () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #6 0xb7642284 in Perl_call_pv () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #7 0xb72026ad in rlmperl_call () from /opt/server/radius/lib/rlm_perl.so #8 0x08063524 in modcall () #9 0x0805ffe7 in indexed_modcall () #10 0x080602fc in module_accounting () #11 0x0804e9d1 in rad_accounting () #12 0x0806df65 in radius_handle_request () #13 0x080661d0 in request_handler_thread () #14 0xb759c4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #15 0xb734384e in clone () from /lib/i686/cmov/libc.so.6 bt for coredump #2: #0 0xb7690c80 in Perl_pad_undef () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #1 0xb764db67 in Perl_cv_undef () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #2 0xb76dcf5a in Perl_sv_clear () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #3 0xb76dd288 in Perl_sv_free2 () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #4 0xb76dd391 in Perl_sv_free () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #5 0xb76dcd57 in Perl_sv_clear () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #6 0xb76dd288 in Perl_sv_free2 () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #7 0xb70af022 in XS_Sys__Syslog_closelog_xs () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/auto/Sys/Syslog/Syslog.so #8 0xb76c941e in Perl_pp_entersub () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #9 0xb76c7841 in Perl_runops_standard () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #10 0xb7662500 in Perl_call_sv () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #11 0xb7663284 in Perl_call_pv () from /opt/server/lib/perl5/5.10.1/i686-linux-thread-multi/CORE/libperl.so #12 0xb72236ad in rlmperl_call () from /opt/server/radius/lib/rlm_perl.so #13 0x08063524 in modcall () #14 0x0805ffe7 in indexed_modcall () #15 0x0806037c in module_authenticate () #16 0x0804f908 in rad_authenticate () #17 0x0806df65 in radius_handle_request () #18 0x080661d0 in request_handler_thread () #19 0xb75bd4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #20 0xb736484e in clone () from /lib/i686/cmov/libc.so.6 bt for coredump #3: #0 0xb77a2424 in __kernel_vsyscall () #1 0xb72d6640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb72d8018 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb731348d in ?? () from /lib/i686/cmov/libc.so.6 #4 0x0005 in ?? () #5 0xb583f614 in ?? () #6 0x0400 in ?? () #7 0xb73e97c8 in ?? () from /lib/i686/cmov/libc.so.6 #8 0x0017 in ?? () #9 0xbfd8b66b in ?? () #10 0x0020 in ?? () #11 0xb73e97e1 in ?? () from /lib/i686/cmov/libc.so.6 #12 0x0002 in ?? () #13 0xb73e985c in ?? () from /lib/i686/cmov/libc.so.6 #14 0x0023 in ?? () #15 0xb73e97e5 in ?? () from /lib/i686/cmov/libc.so.6 #16 0x0004 in ?? () #17 0xb583fb43 in ?? () #18 0x0008 in ?? () #19 0xb73e97eb in ?? () from /lib/i686/cmov/libc.so.6 #20 0x0005 in ?? () #21 0xb72eb388 in vfprintf () from /lib/i686/cmov/libc.so.6 #22 0xb7319764 in ?? () from /lib/i686/cmov/libc.so.6 #23 0x0002 in ?? () #24 0xb73e97c8 in ?? () from /lib/i686/cmov/libc.so.6 #25 0xbfd8b66b in ?? () #26 0xb73e985c in ?? () from /lib/i686/cmov/libc.so.6 #27 0xb583fb43 in ?? () #28
RE: thread pools in 2.1.10
I tested using the listen configuration, but still had the same result. But if I comment out the thread pool section and everything works fine. Any other ideas? Thanks, Keven -Original Message- From: freeradius-users-bounces+keven.smith-worthylake=genband@lists.freeradius.org [mailto:freeradius-users-bounces+keven.smith-worthylake=genband@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Tuesday, December 07, 2010 4:14 PM To: FreeRadius users mailing list Subject: Re: thread pools in 2.1.10 Keven Smith-Worthylake wrote: When we start radiusd with a thread pool configured, none of the requests from the pam-radius-auth proxy client are serviced/processed. The client never gets a reply from the server. From the server logs, the request is never seen. Because it's not listening on any ports. You appear to have copied your configuration from 1.1.7 nearly verbatim to 2.1.10. This is probably not a good idea. I noticed that when the server is started without the thread pool, the following logs are displayed (but they are not displayed when the thread pool is configured): You've also ignored the warning message before the text you quoted. Add a listen section, as given in the default config for 2.1.10. We don't really test 2.1.10 with copies of the 1.1.7 configuration. It's *intended* to mostly work. But if it doesn't work, well... people can always read the warnings, and/or use the 2.1.10 configuration. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: thread pools in 2.1.10
Keven Smith-Worthylake wrote: I tested using the listen configuration, but still had the same result. I did stuff and it didn't work But if I comment out the thread pool section and everything works fine. Any other ideas? Start with the default 2.1.x configuation, and gradually add in the pieces from your legacy system. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dialup_admin php notice errors
I am using Slackware Linux 13.1 64 bit with Apache 2.2.15 (with mod_ssl 2.2.15) OpenSSL 0.9.8n PHP 5.2.13 and freeradius 2.1.10. I am trying to configure dialup_admin for web administration. I went through the dialup_admin/doc/HOWTO and to the best of my knowledge I did everything right. But when I go to the main page I get the following PHP notice errors above the menu items: [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: import_request_variables() [a href='function.import-request-variables'function.import-request-variables/a]: No prefix specified - possible security hazard in /usr/local/sbin/dialup_admin/conf/config.php3 on line 8, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant general_use_session - assumed 'general_use_session' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 66, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Undefined variable: login in /usr/local/sbin/dialup_admin/conf/config.php3 on line 73, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Undefined variable: login in /usr/local/sbin/dialup_admin/conf/config.php3 on line 76, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant general_username_mappings_file - assumed 'general_username_mappings_file' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 86, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant general_username_mappings_file - assumed 'general_username_mappings_file' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 87, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant name - assumed 'name' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 100, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant name - assumed 'name' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 100, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant name - assumed 'name' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 100, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant name - assumed 'name' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 100, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant name - assumed 'name' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 100, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant name - assumed 'name' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 100, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant general_use_session - assumed 'general_use_session' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 106, referer: http://192.168.1.2/dialup/ [Tue Jan 04 14:38:39 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant general_use_session - assumed 'general_use_session' in /usr/local/sbin/dialup_admin/html/buttons/default/buttons.html.php3 on line 91, referer: http://192.168.1.2/dialup/ and if I go down to the menu and click on the accounting link I get the following PHP notice errors in the main content part of the web page [Tue Jan 04 14:40:22 2011] [error] [client 192.168.1.10] PHP Notice: import_request_variables() [a href='function.import-request-variables'function.import-request-variables/a]: No prefix specified - possible security hazard in /usr/local/sbin/dialup_admin/conf/config.php3 on line 8, referer: http://192.168.1.2/dialup/buttons.php3 [Tue Jan 04 14:40:22 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant general_use_session - assumed 'general_use_session' in /usr/local/sbin/dialup_admin/conf/config.php3 on line 66, referer: http://192.168.1.2/dialup/buttons.php3 [Tue Jan 04 14:40:22 2011] [error] [client 192.168.1.10] PHP Notice: Undefined variable: login in /usr/local/sbin/dialup_admin/conf/config.php3 on line 73, referer: http://192.168.1.2/dialup/buttons.php3 [Tue Jan 04 14:40:22 2011] [error] [client 192.168.1.10] PHP Notice: Undefined variable: login in /usr/local/sbin/dialup_admin/conf/config.php3 on line 76, referer: http://192.168.1.2/dialup/buttons.php3 [Tue Jan 04 14:40:22 2011] [error] [client 192.168.1.10] PHP Notice: Use of undefined constant
Re: segfault with rlm_perl
On 2011/01/04 09:59 PM, Anatoly Ivanov wrote: Hi, I am running freeradius (2.1.8) with rlm_perl (5.10.1, USE_ITHREADS) on a Debian-Lenny system. The problem is radius fails with segfault – periodically and intermittently. I have no way to reliably reproduce the problem – it happens only in production, and it is impossible to reliably predict when or backtrace why. It seems that I am running into some kind of memory allocation error. Coredump type #3 (see below) is the most popular one; coredumps with backtrace going into perl seem to be rather random (it fails in different parts of libperl.so) - again, see below. I understand that freeradius has a newer version available - but I am hesitant to upgrade a production server without a very good reason. And I could not find such reason for an upgrade after reading the CHANGELOG for 2.1.10. But maybe I am wrong? Any ideas? A complete gut feel after reading this says you have a hardware problem - faulty ram. Has this happened from the beginning or suddenly now? You can try memtesting (http://www.memtest.org/) the server, or a trick that I've found works sometimes (if you can't take the server out of production) to show a ram problem, is to compile a kernel. I've seen compilation fail at different stages with faulty RAM. I realiuse the advice might sound ridiculous, but it has worked for me before. -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
