(Fwd) Re: Seg Fault - radius 3.0 Debug
Hello,
I finally solved my issue. It was a problem of linking mysql libs.
I'm sorry . Apologies to all
but.. Maybe variables have changed but since 3.0 version the variable
%{Huntgroup-Name}
is no more recognized.
tested on version 2.1.11 - Works perfectly
Any ideas ?
Thanks
--- Forwarded message follows ---
Date sent: Thu, 17 Mar 2011 21:20:20 +
From: Alan Buxey a.l.m.bu...@lboro.ac.uk
To: nicolas.bre...@belcenter.biz
nicolas.bre...@belcenter.biz,
FreeRadius users mailing list freeradius-users@lists.freeradius.org
Subject:Re: Seg Fault - radius 3.0 Debug
Hi,
Here is my debug file with gbd on the seg fault
[Thread debugging using libthread_db enabled]
[New Thread 0x7600b700 (LWP 23433)]
[Thread 0x7600b700 (LWP 23433) exited]
Program received signal SIGSEGV, Segmentation fault.
0x76032890 in mysql_field_count () from
/usr/lib64/mysql/libmysqlclient_r.so.16
Missing separate debuginfos, use: debuginfo-install
glibc-2.13-1.x86_64
suggest you follow the information given to get more debugging info
out
alan
--- End of forwarded message ---
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: (Fwd) Re: Seg Fault - radius 3.0 Debug
Breuer Nicolas wrote:
but.. Maybe variables have changed but since 3.0 version the variable
%{Huntgroup-Name}
is no more recognized.
It should work. The git master branch hasn't changed any of that
functionality.
And (as always) what does debug mode say?
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
(Fwd) (Fwd) Re: Seg Fault - radius 3.0 Debug
The debug mode said anything - No errors.
My variable is in the SQLIPPOOL.conf file and called with %{Huntgroup-Name}
No values were returned.
With 2.1.11 - Same directory, dic files, etc , i have a value.
--- Forwarded message follows ---
Breuer Nicolas wrote:
but.. Maybe variables have changed but since 3.0 version the variable
%{Huntgroup-Name}
is no more recognized.
It should work. The git master branch hasn't changed any of that
functionality.
And (as always) what does debug mode say?
Alan DeKok.
--- Forwarded message follows ---
From: Breuer Nicolas nicolas.bre...@belcenter.biz
To: freeradius-users@lists.freeradius.org
Subject:(Fwd) Re: Seg Fault - radius 3.0 Debug
Date sent: Fri, 18 Mar 2011 12:45:23 +0100
Hello,
I finally solved my issue. It was a problem of linking mysql libs.
I'm sorry . Apologies to all
but.. Maybe variables have changed but since 3.0 version the variable
%{Huntgroup-Name}
is no more recognized.
tested on version 2.1.11 - Works perfectly
Any ideas ?
Thanks
--- Forwarded message follows ---
Date sent: Thu, 17 Mar 2011 21:20:20 +
From: Alan Buxey a.l.m.bu...@lboro.ac.uk
To: nicolas.bre...@belcenter.biz nicolas.bre...@belcenter.biz,
FreeRadius users mailing list freeradius-users@lists.freeradius.org
Subject: Re: Seg Fault - radius 3.0 Debug
Hi,
Here is my debug file with gbd on the seg fault
[Thread debugging using libthread_db enabled]
[New Thread 0x7600b700 (LWP 23433)]
[Thread 0x7600b700 (LWP 23433) exited]
Program received signal SIGSEGV, Segmentation fault.
0x76032890 in mysql_field_count () from
/usr/lib64/mysql/libmysqlclient_r.so.16
Missing separate debuginfos, use: debuginfo-install
glibc-2.13-1.x86_64
suggest you follow the information given to get more debugging info
out
alan
--- End of forwarded message ---
--- End of forwarded message ---
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: (Fwd) (Fwd) Re: Seg Fault - radius 3.0 Debug
Breuer Nicolas wrote: The debug mode said anything - No errors. Then I guess there are no problems. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re : Seg Fault - radius 3.0 Debug
More messages
--- Forwarded message follows ---
From: root r...@mail-mx-out.belcenter.com
Date sent: Thu, 17 Mar 2011 18:43:14 +0100
To: nicolas.bre...@belcenter.be
Program received signal SIGSEGV, Segmentation fault.
0x76032890 in mysql_field_count () from
/usr/lib64/mysql/libmysqlclient_r.so.16
Missing separate debuginfos, use: debuginfo-install glibc-2.13-1.x86_64
keyutils-libs-1.2-
6.fc12.x86_64 krb5-libs-1.8.2-7.fc14.x86_64 libcom_err-1.41.12-6.fc14.x86_64
libgcc-4.5.1-
4.fc14.x86_64 libselinux-2.0.96-6.fc14.1.x86_64 mysql-libs-5.1.55-1.fc14.x86_64
nss-
softokn-freebl-3.12.9-2.fc14.x86_64 openssl-1.0.0d-1.fc14.x86_64
zlib-1.2.5-2.fc14.x86_64
* 1 Thread 0x77bba720 (LWP 23430) 0x76032890 in mysql_field_count
() from
/usr/lib64/mysql/libmysqlclient_r.so.16
Thread 1 (Thread 0x77bba720 (LWP 23430)):
#0 0x76032890 in mysql_field_count () from
/usr/lib64/mysql/libmysqlclient_r.so.16
No symbol table info available.
#1 0x76391dee in sql_num_fields (sqlsocket=value optimized out,
config=value
optimized out) at sql_mysql.c:239
num = 0
mysql_sock = 0x8986b0
#2 0x7639233d in sql_select_query (sqlsocket=0x898640, config=0x847480,
querystr=value optimized out) at sql_mysql.c:275
ret = 0
#3 0x76598c67 in rlm_sql_select_query (sqlsocket=0x898640,
inst=0x847410,
query=0x7fffaf40 SELECT ip_address FROM radippool WHERE pool_name =
'BC*'
AND expiry_time NOW() ORDER BY rand(), pool_name, expiry_time LIMIT 1 FOR
UPDATE) at sql.c:566
ret = value optimized out
#4 0x74ff1c3b in sqlippool_query1 (out=0x7fffd180 \001,
fmt=value optimized
out, sqlsocket=0x898640, data=0x8c59f0,
request=0x8d5b20, param_len=0, param=0x0, outlen=-2) at rlm_sqlippool.c:359
expansion = SELECT ip_address FROM radippool WHERE pool_name =
'%{reply:Pool-Suffix}*%{Huntgroup-Name}' AND expiry_time NOW() ORDER BY
rand(),
pool_name, expiry_time LIMIT 1 FOR
UPDATE\000\000.\341\377\377\377\177\000\000\000\000\000\000\377\177, '\000'
repeats
34 times, , '\000' repeats 15 times...
query = SELECT ip_address FROM radippool WHERE pool_name = 'BC*' AND
expiry_time NOW() ORDER BY rand(), pool_name, expiry_time LIMIT 1 FOR
UPDATE\000\377\177\000\000\220\322\377\377\377\177\000\000(\256C, '\000'
repeats
13 times, [xA\000\000\000\000\000[LIVE-SYSTEM-01] \texpand: COMMIT -...
rlen = value optimized out
retval = 0
#5 0x74ff1f6c in sqlippool_postauth (instance=0x8c59f0,
request=0x8d5b20) at
rlm_sqlippool.c:596
data = 0x8c59f0
allocation =
\001\000\000\000\000\000\000\000\237\314\336\367\377\177\000\000
[\215\000\000\000\000\000\350\003, '\000' repeats 14 times,
O\317\336\367\377\177\000\000\000\004\000\000\000\000\000\000H[\215\000\000\000\000
\000 [\215\000\000\000\000\000\001, '\000' repeats 15 times\305,
#B\000\000\000\000\000
\000\000\000\060\000\000\000\340\322\377\377\377\177\000\000\000\322\377\377\377\177
\000\000\026\371:\367\377\177\000\000\060\000\000\000\060\000\000\000\020\323\377\37
7\377\177\000\000
\322\377\377\377\177\000\000\000\000\000\000\000\000\000\000]pC\000\000\000\000\000\
260X\214\000\000\000\000\000\200\033y\000\000\000\000\000H[\215\000\000\000\000\000\
002\000\000\000\000\000\000\000\300\204C\000\000\000\000\000\310t\335\367\377\177\00
0\000\000\000\000\000\377\177\000\000\000\000\000\000\000\000\000\000
[\215\000\000\000\000\000\340\060y\000\000\000\000\000Saf\000\000
allocation_len = value optimized out
ip_allocation = value optimized out
vp = value optimized out
sqlsocket = 0x898640
ipaddr = {af = 6709588, ipaddr = {ip4addr = {s_addr = 0}, ip6addr =
{__in6_u = {
__u6_addr8 = \000\000\000\000\265=a\234\061\000\000\000@Y\215,
__u6_addr16 = {0, 0, 15797, 40033, 49, 0, 22848, 141},
__u6_addr32 = {0, 2623618485, 49, 9263424, scope = 0}
logstr =
@E{\367\377\177\000\000/\346:\367\377\177\000\000\000\000\000\000\000\000\000\000\0
22\004\000\000\000\000\000\000Pv\215\000\000\000\000\000\025\000\000\000\000\000\00
0\000\005, '\000' repeats 15 times, \020\321\377\377\377\177\000\000p\001,
'\000'
repeats 30 times,
\025\000\000\000\065\000\000\000[\000\000\000n\000\000\000w\000\000\000|\000\000\000
\321\377\377\377\177\000\000\017\321\377\377\377\177\000\000\377\377\377\377\000\000
\000\000\062\316\335\367\377\177\000\000\000\000\000\000\000\000\000\000\342\v\336\3
67\377\177\000\000\360\070
\000\000\000\000\000\300qÜ1\000\000\000@\001\000\000\000\000\000\000\001\000\000\0
00\000\000\000\000\270\274w\000\000\000\000\000@\322\377\377\377\177\000\000PCy\0
00\000\000\000\000\375\237\247\234\061\000\000\000\350\003\000\000\000\000\000\000\2
70\274w\000\000
sqlusername =
BCa10733@BELCENTER\000\367\377\177\000\000\230\066@\000\000\000\000\000ؐ\244
Re: Re : Seg Fault - radius 3.0 Debug
Breuer Nicolas wrote: Thread 1 (Thread 0x77bba720 (LWP 23430)): #0 0x76032890 in mysql_field_count () from /usr/lib64/mysql/libmysqlclient_r.so.16 No symbol table info available. #1 0x76391dee in sql_num_fields (sqlsocket=value optimized out, config=value optimized out) at sql_mysql.c:239 num = 0 mysql_sock = 0x8986b0 Unfortunately, that doesn't help too much. The core dump is in the MySQL client library, which we don't know anything about. This would be a hard issue to track down, unfortunately. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Seg Fault - radius 3.0 Debug
Hi, Here is my debug file with gbd on the seg fault [Thread debugging using libthread_db enabled] [New Thread 0x7600b700 (LWP 23433)] [Thread 0x7600b700 (LWP 23433) exited] Program received signal SIGSEGV, Segmentation fault. 0x76032890 in mysql_field_count () from /usr/lib64/mysql/libmysqlclient_r.so.16 Missing separate debuginfos, use: debuginfo-install glibc-2.13-1.x86_64 suggest you follow the information given to get more debugging info out alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Seg Fault - 3.0 - More Info needed
Breuer Nicolas wrote: Hello Alan, Could you precise wich infos you need to go further ? Yes. I was precise. Read the file doc/bugs. This is documented. Follow the instructions there. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Seg Fault in 2.0.3
Garber, Neal wrote: I have a FR 2.0.3 server running under FreeBSD 6.3 which intermittently exits with a segmentation fault. Upgrade. I tried searching the list for known seg fault issues with 2.0.3 and only found one which sounded like it only happens when running under gdb. Do you think upgrading to 2.1.3 (it’s the latest port for FR under FreeBSD) could potentially resolve this issue? (I’m not looking for a guarantee, just an opinion based upon whether there were known seg faults in 2.0.3 that were fixed in later releases.) Yes. Should I run FR under gdb to get more information about the seg fault? You could, but unless you're going to debug the source code yourself, I wouldn't suggest it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Seg Fault in 2.0.3
Upgrade. That's what I was hoping you would say. Thanks Alan. Should I run FR under gdb to get more information about the seg fault? You could, but unless you're going to debug the source code yourself, I wouldn't suggest it. I would, but there's no need if upgrading to 2.1.3 will correct the problem. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Seg Fault - Not much info..
I'm running Freeradius 2.1.3 on my Ubuntu 8.04 machine. Basically, my
setup is a VPN system linked to freeradius via a specialized plugin.
Before I updated my freeradius (from the old 1.x), everything was
working fine. Now that I have updated to 2.1.3, I can't seem to get it
working again.
Taking the VPN and plugin out of the mix, I run my freeradius in -X
mode, then send a 'radtest' authentication packet. The freeradius server
receives the request:
rad_recv: Access-Request packet from host 127.0.0.1 port 46625,
id=69, length=93
User-Name = test
User-Password = test
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
Then, straight away I am faced with:
+- entering group authorize {...}
Segmentation fault
This is all the info that I am receiving from the freeradius server -
and not being very knowledgeable on freeradius - I am pretty stumped as
to what my problem is.
I have had a glance around the 'authorize' section, and it contains:
authorize {
preprocess
# auth_log
chap
mschap
# digest
# IPASS
suffix
# ntdomain
# eap {
# ok = return
# }
# unix
# files
sql
# etc_smbpasswd
# ldap
# daily
# checkval
# expiration
# logintime
pap
#Auth-Type Status-Server {
#
#}
}
which is exactly as it was on my old version.
Any ideas?
Read doc/bugs on how to get more information.
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: seg fault
Since we have no idea what the problem is, the answer is likely no. totally fair =) If malloc() is core dumping, then something else is going wrong. i.e. some other part of the server is over-writing memory. when you say the server i assume you mean freeradius not another app.?? I would try 2.0. Large amounts of code have been re-written or updated. It may not be perfect, but there are good odds that this problem won't re-appear. that's what i'll do then. thanks for the help, Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: seg fault
no - i'd read that as some other part of your 64bit x86 box is trashing the memory. hmm, the box itself is totally stable, nothing else has been an issue... hyperthreading on? no they are true dualcore Xeon's w/ no hyperthreading. Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: seg fault
Hi, If malloc() is core dumping, then something else is going wrong. i.e. some other part of the server is over-writing memory. when you say the server i assume you mean freeradius not another app.?? no - i'd read that as some other part of your 64bit x86 box is trashing the memory. hyperthreading on? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: seg fault
Joe Vieira wrote: Hi, i've got freeradius 1.1.6 running on rhel5. when i goto do an ldap auth. i get this ... Segmentation fault See doc/bugs Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: seg fault
attached is my gdb log, looks like something happens with the ldap_set_option() function. thanks for having a lot Joe -Original Message- From: [EMAIL PROTECTED] on behalf of Alan Dekok Sent: Wed 6/13/2007 3:33 AM To: FreeRadius users mailing list Subject: Re: seg fault Joe Vieira wrote: Hi, i've got freeradius 1.1.6 running on rhel5. when i goto do an ldap auth. i get this ... Segmentation fault See doc/bugs Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html gdb.radiusd.log Description: gdb.radiusd.log - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: seg fault
Found the issue, i added -DLDAP_DEPRECATED to the CFLAGS. Joe Joe Vieira wrote: Hi, i've got freeradius 1.1.6 running on rhel5. when i goto do an ldap auth. i get this ... Segmentation fault See doc/bugs Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - 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: Seg fault in rlm_ldap on Redhat Enterprise Linux 3 - solved
For those remotely interested in this issue, the problem was actually due to an issue in OpenLDAP, as I mentioned some time ago (see below). Redhat now has a released fix for this. The bug description is shown at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111492, and the fix at http://rhn.redhat.com/errata/RHBA-2004-224.html. Regards Tarun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tarun Bhushan Sent: Tuesday, 17 August 2004 6:08 PM To: [EMAIL PROTECTED] Subject: RE: Seg fault in rlm_ldap on Redhat Enterprise Linux 3 - solved, sort of I found that the problem is within the OpenLDAP library libldap (line 845 in tls.c method-ext_free(alt);) and is the same as OpenLDAP problem 1924 (http://www.openldap.org/its/index.cgi/Software%20Bugs?id=1924;selectid=1924). This was reported and fixed back in 2002, but Redhat did not apply it to the OpenLDAP released with RHEL3 nearly a year and a half later! Anyway, by adapting the patch, I was able to fix this issue - just in case others have encountered it. In case you are interested, also see Redhat Bugzilla bugs 128364 and 111492. Patch for your reference: --- openldap-2.0.27/libraries/libldap/tls.c 2004-08-18 22:09:10.0 +1000 +++ openldap-2.0.27/libraries/libldap/tls.c 2004-08-18 22:11:09.0 +1000 @@ -816,7 +816,6 @@ int n, len1, len2; char *domain; GENERAL_NAME *gn; - X509V3_EXT_METHOD *method; len1 = strlen(name); n = sk_GENERAL_NAME_num(alt); @@ -841,8 +840,7 @@ break; } } - method = X509V3_EXT_get(ex); - method-ext_free(alt); + GENERAL_NAMES_free(alt); if (i n) /* Found a match */ ret = LDAP_SUCCESS; } Regards Tarun NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Seg fault in rlm_ldap on Redhat Enterprise Linux 3 - solved, sort of
I found that the problem is within the OpenLDAP library libldap (line 845 in tls.c method-ext_free(alt);) and is the same as OpenLDAP problem 1924 (http://www.openldap.org/its/index.cgi/Software%20Bugs?id=1924;selectid=1924). This was reported and fixed back in 2002, but Redhat did not apply it to the OpenLDAP released with RHEL3 nearly a year and a half later! Anyway, by adapting the patch, I was able to fix this issue - just in case others have encountered it. In case you are interested, also see Redhat Bugzilla bugs 128364 and 111492. Patch for your reference: --- openldap-2.0.27/libraries/libldap/tls.c 2004-08-18 22:09:10.0 +1000 +++ openldap-2.0.27/libraries/libldap/tls.c 2004-08-18 22:11:09.0 +1000 @@ -816,7 +816,6 @@ int n, len1, len2; char *domain; GENERAL_NAME *gn; - X509V3_EXT_METHOD *method; len1 = strlen(name); n = sk_GENERAL_NAME_num(alt); @@ -841,8 +840,7 @@ break; } } - method = X509V3_EXT_get(ex); - method-ext_free(alt); + GENERAL_NAMES_free(alt); if (i n) /* Found a match */ ret = LDAP_SUCCESS; } Regards Tarun -Original Message- From: Tarun Bhushan Sent: Tuesday, 17 August 2004 12:42 PM To: [EMAIL PROTECTED] Subject: Seg fault in rlm_ldap on Redhat Enterprise Linux 3 On Redhat Enterprise Linux 3, when I try to use LDAP (Port = 636 and hence with TLS), FreeRadius seg faults within rlm_ldap. I have been following the various seg faults for this module discussed recently (including on Fedora Core 2, etc), but this appears to be a different problem to Bug #73. Without TLS, it works fine, but as soon as the port is changed to 636 (or even another high port with tls_mode=yes), the seg fault happens. snip NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Seg fault on Ascend-Data-Filter
Chris Chapman [EMAIL PROTECTED] wrote: When returning an Ascend-Data-Filter of ip in forward tcp est as the first data filter radiusd core dumps. When returning another data filter first such as ip in drop tcp dstport = 135 all data filters except the tcp est are returned with no errors. Fixed, thanks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Seg fault on Ascend-Data-Filter
Alan DeKok wrote: Chris Chapman [EMAIL PROTECTED] wrote: When returning an Ascend-Data-Filter of ip in forward tcp est as the first data filter radiusd core dumps. When returning another data filter first such as ip in drop tcp dstport = 135 all data filters except the tcp est are returned with no errors. doc/bugs Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html bash-2.03# uname -a SunOS radius-1 5.8 Generic_108528-24 sun4u sparc SUNW,UltraSPARC-IIi-Engine bash-2.03# /usr/local/sbin/radiusd -v radiusd: FreeRADIUS Version 1.0.0-pre0, for host , built on Feb 17 2004 at 14:32:38 Copyright (C) 2000-2003 The FreeRADIUS server project. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. For more information about these matters, see the file named COPYRIGHT. (gdb) bt #0 0xff0b31f0 in strlen () from /usr/lib/libc.so.1 #1 0xff1062b8 in _doprnt () from /usr/lib/libc.so.1 #2 0xff10842c in vsnprintf () from /usr/lib/libc.so.1 #3 0xff3589bc in librad_log ( fmt=0xff360878 Unknown extra string \%s\ in IP data filter) at log.c:52 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Seg fault on Ascend-Data-Filter
Chris Chapman [EMAIL PROTECTED] wrote: When returning an Ascend-Data-Filter of ip in forward tcp est as the first data filter radiusd core dumps. When returning another data filter first such as ip in drop tcp dstport = 135 all data filters except the tcp est are returned with no errors. doc/bugs Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
