Re: segmentation fault in rlm_attr_rewrite and eaptls module
in ?? () #16 0x08140ab0 in ?? () #17 0xb7c73439 in sk_insert () from /usr/lib/libcrypto.so.0.9.8 #18 0x08158db8 in ?? () #19 0x0040 in ?? () #20 0xb7ce8c45 in dummy_nid () from /usr/lib/libcrypto.so.0.9.8 #21 0x0096 in ?? () #22 0x08140ab0 in ?? () ---Type return to continue, or q return to quit--- #23 0xb7ce8c45 in dummy_nid () from /usr/lib/libcrypto.so.0.9.8 #24 0x0332 in ?? () #25 0xb7cf36c0 in ?? () from /usr/lib/libcrypto.so.0.9.8 #26 0x000e in ?? () #27 0x0002 in ?? () #28 0x081684d9 in ?? () #29 0xb7c73579 in sk_push () from /usr/lib/libcrypto.so.0.9.8 #30 0xb7d38760 in ssl3_ciphers () from /usr/lib/libssl.so.0.9.8 #31 0x0007 in ?? () #32 0xb7c7328b in sk_new_null () from /usr/lib/libcrypto.so.0.9.8 #33 0xb7d2c090 in SSL_SESSION_get_id () from /usr/lib/libssl.so.0.9.8 #34 0xb7d37880 in ?? () from /usr/lib/libssl.so.0.9.8 #35 0xb7d282a3 in ssl_bytes_to_cipher_list () from /usr/lib/libssl.so.0.9.8 #36 0xb7d38760 in ssl3_ciphers () from /usr/lib/libssl.so.0.9.8 #37 0x0020 in ?? () #38 0x00e1 in ?? () #39 0x0064 in ?? () #40 0x08158f0c in ?? () #41 0x08140ab0 in ?? () #42 0xb7d37880 in ?? () from /usr/lib/libssl.so.0.9.8 #43 0x0036 in ?? () #44 0x081684ff in ?? () #45 0x0815b220 in ?? () ---Type return to continue, or q return to quit--- #46 0xb7d106a9 in ssl3_get_client_hello () from /usr/lib/libssl.so.0.9.8 #47 0x081684c9 in ?? () #48 0x0036 in ?? () #49 0xbffce244 in ?? () #50 0x4000 in ?? () #51 0xbffce248 in ?? () #52 0xbffce224 in ?? () #53 0xb7c79007 in EVP_DigestInit_ex () from /usr/lib/libcrypto.so.0.9.8 #54 0x in ?? () Please let me know what could be the reason for this issue, and if there are any fixes arround please let me know. Its very urgent. Hope to get a reply soon. Thanks in advance. -- Nikitha On 4/6/07, nikitha [EMAIL PROTECTED] wrote: Hi All, I am running freeradius-1.1.1 for quite a long time. Never seen this kind of issue when few requests are sent to the radiusd. The issue is when many requests are coming, then radiusd is crashing or going in an infinite loop and hogging for 99.9% of CPU. Please find the debug logs below. modcall[authorize]: module preprocess returns ok for request 1522 radius_xlat: 'anonymous' rlm_attr_rewrite: Added attribute Stripped-User-Name with value 'anonymous' modcall[authorize]: module copy_user_name returns ok for request 1522 radius_xlat: '^(.*[\/]+)' Program received signal SIGSEGV, Segmentation fault. 0xb7df9693 in mallopt () from /lib/libc.so.6 (gdb) where #0 0xb7df9693 in mallopt () from /lib/libc.so.6 #1 0xb7df877c in malloc () from /lib/libc.so.6 #2 0xb7e2a329 in re_comp () from /lib/libc.so.6 #3 0xb7e2a176 in re_comp () from /lib/libc.so.6 #4 0xb7e29c4f in regcomp () from /lib/libc.so.6 #5 0xb7b2e4d6 in do_attr_rewrite () from /usr/lib/rlm_attr_rewrite- 1.1.1.so #6 0xb7b2eb44 in attr_rewrite_authorize () from /usr/lib/rlm_attr_rewrite-1.1.1.so #7 0x08055f26 in module_post_auth () #8 0x0805660d in modcall () #9 0x08055f9a in module_post_auth () #10 0x0805609c in module_post_auth () #11 0x08056565 in modcall () #12 0x08055269 in find_module_instance () #13 0x08055b8a in module_authorize () #14 0x0804d7a1 in rad_authenticate () #15 0x08059d52 in rad_respond () #16 0x08059a22 in main () and when i restarted the server the crash happened in eaptls module. rad_recv: Access-Request packet from host 192.168.1.1:7988, id=114, length=319 User-Name = anonymous Called-Station-Id = 00-15-70-23-03-00:wpa_psk Calling-Station-Id = 00-00-00-22-00-07 NAS-Port = 8 NAS-Port-Type = Wireless-802.11 Framed-MTU = 1400 Service-Type = Framed-User NAS-IP-Address = 192.168.1.1 NAS-Identifier = Wireless Services NAS-Port-Id = wpa_psk Connect-Info = CONNECT 54Mbps 802.11g State = 0x72fe4ac90661f9590e32dcb0c7059d75 EAP-Message = 0x02020070198000661603010061015d030146161ab12118da21a43b116bb44c8bed120272f7b2796c3976e35bd114643a5c3600390038003500160013000a00330032002f0007006600050004006300620061001500120009006500640060001400110008000600030100 Message-Authenticator = 0x9521947e080287f8034d050f25bc08ea Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2652 modcall[authorize]: module preprocess returns ok for request 2652 radius_xlat: 'anonymous' rlm_attr_rewrite: Added attribute Stripped-User-Name with value 'anonymous' modcall[authorize]: module copy_user_name returns ok for request 2652 radius_xlat: '^(.*[\/]+)' rlm_attr_rewrite: No match found for attribute Stripped-User-Name with value 'anonymous' modcall[authorize]: module add_dollar_sign returns ok for request 2652 modcall[authorize]: module etc_passwd returns notfound for request 2652 modcall[authorize]: module etc_group returns notfound for request 2652 modcall[authorize]: module chap returns noop for request 2652 modcall[authorize]: module mschap returns
Re: segmentation fault in rlm_attr_rewrite and eaptls module
Hi Alan, Thanks for your information. As we need a fix immediately, can i upgrade to 1.1.5? Does it have fixes for these kind of issues? What is the exact date that you are planning to release 1.1.6? Thanks a lot, -- Nikitha On 4/6/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha wrote: Hi All, I am running freeradius-1.1.1 for quite a long time. Never seen this kind of issue when few requests are sent to the radiusd. The issue is when many requests are coming, then radiusd is crashing or going in an infinite loop and hogging for 99.9% of CPU. Upgrade to 1.1.6 when it comes out next week. It will have a number of fixes that should help. 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: segmentation fault in rlm_attr_rewrite and eaptls module
What about 1.1.5? Can i use this version until we get 1.1.6? Because i already started of porting 1.1.5, so please advise me whether i can go with 1.1.5 itself. Or should i follow as you mentioned in the below mail. Thanks a lot, -- Nikitha On 4/7/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha wrote: Thanks for your information. As we need a fix immediately, can i upgrade to 1.1.5? Does it have fixes for these kind of issues? If you need something now, try 1.1.4, or branch_1_1 in CVS. What is the exact date that you are planning to release 1.1.6? No idea. Next week some time. 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: segmentation fault in rlm_attr_rewrite and eaptls module
I am trying to download the branch_1_1 from CVS but i am getting error as: Unknown host Ping to 64.24.0.50 (cvs.freeradius.org) not reachable. Is the cvs.freeradius.org server is down? Thanks, Sumithra On 4/7/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha wrote: Thanks for your information. As we need a fix immediately, can i upgrade to 1.1.5? Does it have fixes for these kind of issues? If you need something now, try 1.1.4, or branch_1_1 in CVS. What is the exact date that you are planning to release 1.1.6? No idea. Next week some time. 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: segmentation fault in rlm_attr_rewrite and eaptls module
I could ping to freeradius.org but not to cvs.freeradius.org. Anyhow i will try it once again after some time. Thanks. On 4/9/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha wrote: I am trying to download the branch_1_1 from CVS but i am getting error as: Unknown host Ping to 64.24.0.50 http://64.24.0.50 (cvs.freeradius.org http://cvs.freeradius.org) not reachable. Is the cvs.freeradius.org http://cvs.freeradius.org server is down? I can see it as up. It may be the routing between your site and the server. If something goes wrong, whole sections of the net are temporarily unreachable. 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
Redundant Ldap Configuration + More groups
Hi All,
Authentication take more time when 2 ldap servers are configured and one is
not reachable. I have configured the redundant ldap module as specified in
the doc.
authorize {
;;
;;
redundant {
ldap-server-1
ldap-server-2
}
}
authenticate {
;;
;;
Auth-Type LDAP {
redundant {
ldap-server-1
ldap-server-2
}
}
The corresponding ldap-server module confiugration is,
ldap ldap-server-1 {
..
..
}
ldap ldap-server-2 {
..
..
}
1. In the users file, added some 20 DEFAULT entry for
ldap-server-1-Ldap-Group
for ex., DEFAULT ldap-server-1-Ldap-Group == g1
2. After that added 30 DEFAULT entry for ldap-server-2-Ldap-Group, each
DEFAULT entry is like,
DEFAULT ldap-server-2-Ldap-Group == g21
..
..
DEFAULT ldap-server-2-Ldap-Group == g50
The ldap-server-1 is down now. only ldap-server-2 is reachable.
When the request comes to the radius server, it goes one entry by entry in
users file, ie., It connects to ldap-server-1 with the Ldap-Group tries
from g1 till g20, and then connects to ldap-server-2 with Ldap-Group from
g21' till g50. If the user is part of Ldap-group g50 it takes more time
to return success, before itself the request times out, and received eap
start again from wireless client.
If the number of DEFAULT entry for ldap-server-1 is less than 10, then it
works fine. If the default entry increases, the server takes more time to
process.
I think redundant ldap server configuration is not correct or in some
otherway we can fix it. Is it possible to configure the radius server in
such a way that, try ldap-server-1 for the first policy, if its reachable
then check it against the next policy.
If its not reachable mark this server as dead or whatever and ignore
processing the next coming DEFAULT entries which matches with ldap-server-1
and try to process ldap-server-2 entries.
Please help me in solving this issue. Thanks for any help.
Regards,
Nikitha
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Redundant Ldap Configuration + More groups
Hi All,
Authentication takes more time when two ldap servers are configured ( for
redundancy ) and one is not reachable. I have configured the redundant ldap
module as specified in the doc.
authorize {
;;
;;
redundant {
ldap-server-1
ldap-server-2
}
}
authenticate {
;;
;;
Auth-Type ldap-server-1 {
ldap-server-1
}
Auth-Type ldap-server-2 {
ldap-server-2
}
Auth-Type LDAP {
redundant {
ldap-server-1
ldap-server-2
}
}
The corresponding ldap-server module confiugration is,
ldap ldap-server-1 {
..
..
}
ldap ldap-server-2 {
..
..
}
1. In the users file, added some 20 DEFAULT entry for
ldap-server-1-Ldap-Group
for ex., DEFAULT ldap-server-1-Ldap-Group == g1
2. After that added 30 DEFAULT entry for ldap-server-2-Ldap-Group, each
DEFAULT entry is like,
DEFAULT ldap-server-2-Ldap-Group == g21
..
..
DEFAULT ldap-server-2-Ldap-Group == g50
The ldap-server-1 is down now. only ldap-server-2 is reachable.
When the request comes to the radius server, it goes one entry by entry in
users file, ie., It connects to ldap-server-1 with the Ldap-Group tries
from g1 till g20, and then connects to ldap-server-2 with Ldap-Group from
g21' till g50. If the user is part of Ldap-group g50 it takes more time
to return success, before itself the request times out, and received eap
start again from wireless client.
If the number of DEFAULT entry for ldap-server-1 is less than 10, then it
works fine. If the default entry increases, the server takes more time to
process.
I think redundant ldap server configuration is not correct or in some
otherway we can fix it. Is it possible to configure the radius server in
such a way that, try ldap-server-1 for the first policy, if its reachable
then check it against the next policy.
If its not reachable mark this server as dead or whatever and ignore
processing the next coming DEFAULT entries which matches with ldap-server-1
and try to process ldap-server-2 entries.
Please help me in solving this issue. Thanks for any help.
Regards,
Nikitha
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Redundant Ldap Configuration + More groups
Hi Alan, Thanks for your information. Regards, Nikitha On 2/17/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha wrote: When the request comes to the radius server, it goes one entry by entry in users file, ie., It connects to ldap-server-1 with the Ldap-Group tries from g1 till g20, and then connects to ldap-server-2 with Ldap-Group from g21' till g50. If the user is part of Ldap-group g50 it takes more time to return success, before itself the request times out, and received eap start again from wireless client. Yes. The LDAP query results aren't cached. If the number of DEFAULT entry for ldap-server-1 is less than 10, then it works fine. If the default entry increases, the server takes more time to process. Yes, the solution is to not configure so many queries that the server slows down. I think redundant ldap server configuration is not correct or in some otherway we can fix it. Is it possible to configure the radius server in such a way that, try ldap-server-1 for the first policy, if its reachable then check it against the next policy. For LDAP-Group checking, no. If its not reachable mark this server as dead or whatever and ignore processing the next coming DEFAULT entries which matches with ldap-server-1 and try to process ldap-server-2 entries. That may be possible with source code patches. i.e. If an LDAP server is marked dead, don't try to contact it for a few seconds. That would help your configuration a lot. But your configuration is an artificial one that highlights a problem. 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
How to enable only EAP-TTLS type and not EAP-TLS?
Hi, I want to enable only TTLS authentication and if the client is requesting any other types EAP-TLS or PEAP the authentication should be denied. I am running freeradius-1.1.6, and if try to disable EAP-TLS module the server itself is not starting up. Please let me know if there are any ways to achieve this. Thanks a lot.. Nikitha. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to enable only EAP-TTLS type and not EAP-TLS?
Alan, I tried with the configuration you had given below, but it does not work out. Still radius server is accepting TLS method. Thanks, Nikitha On 1/9/08, Alan DeKok [EMAIL PROTECTED] wrote: nikitha george wrote: Hi, I want to enable only TTLS authentication and if the client is requesting any other types EAP-TLS or PEAP the authentication should be denied. I am running freeradius-1.1.6, and if try to disable EAP-TLS module the server itself is not starting up. Please let me know if there are any ways to achieve this. Put this at the top of the users file: DEFAULT EAP-Type != EAP-TTLS, Auth-Type := Reject 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
Freeradius + portuguese characters in Active Directory
Hi, I am creating a user account in AD with portuguese character and have the freeradius configured properly. But i am not able to get the successfull authentication. For example, i added a user account catónio and displayname as catónio But the radius server log shows, sending a user name as cat\5c303\5c263nio . Do we need to do anything different to support languages other than english or am i missing some other configuration? FYI: If i change the user account to plain exglish characters then it works, so there are no issues with configuration settings. Any idea why it happens and how to get it work with? Thanks, Nikitha - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius + portuguese characters in Active Directory
Alan, I tried with 2.0 release, still i am not able to get the user authenticated. I am seeing the freeradius which logs the user name as some different character instead of cató. Any other idea? Or did u guys ever tried with this kind of characters in user name? Thanks, Sumithra On 1/12/08, nikitha george [EMAIL PROTECTED] wrote: Okay. Currently I am running with 1.1.6, will upgrade to 2.0 and try it. Thanks for your information. Regards, Nikitha On 1/11/08, Alan DeKok [EMAIL PROTECTED] wrote: nikitha george wrote: I am creating a user account in AD with portuguese character and have the freeradius configured properly. 1.1.x does not support UTF-8 that well. Version 2.0.0 should be much better. Please try that. 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: Freeradius + portuguese characters in Active Directory
Please find the debug log below..
rlm_eap_ttls: Session established. Proceeding to decode tunneled
attributes.
+- entering group authorize
++[preprocess] returns ok
expand: %{User-Name} - Catónio
rlm_attr_rewrite: Added attribute Stripped-User-Name with value 'Catónio'
++[copy_user_name] returns ok
expand: ^(.*[\/]+) - ^(.*[\/]+)
rlm_attr_rewrite: No match found for attribute Stripped-User-Name with value
'Catónio'
++[add_dollar_sign] returns ok
++[chap] returns noop
++[mschap] returns noop
++[mschap] returns noop
rlm_realm: No '/' in User-Name = Catónio, looking up realm NULL
rlm_realm: No such realm NULL
++[suffix_oblic] returns noop
rlm_realm: No '\' in User-Name = Catónio, looking up realm NULL
rlm_realm: No such realm NULL
++[suffix_oblic_fs] returns noop
rlm_realm: No '/' in User-Name = Catónio, looking up realm NULL
rlm_realm: No such realm NULL
++[prefix_oblic] returns noop
rlm_realm: No '\' in User-Name = Catónio, looking up realm NULL
rlm_realm: No such realm NULL
++[prefix_oblic_fs] returns noop
rlm_realm: No '@' [EMAIL PROTECTED] in User-Name = Catónio, looking up
realm
NULL
rlm_realm: No such realm NULL
++[suffix_at] returns noop
rlm_realm: No '@' [EMAIL PROTECTED] in User-Name = Catónio, looking up
realm
NULL
rlm_realm: No such realm NULL
++[prefix_at] returns noop
rlm_realm: No '%' in User-Name = Catónio, looking up realm NULL
rlm_realm: No such realm NULL
++[suffix_percent] returns noop
rlm_realm: No '%' in User-Name = Catónio, looking up realm NULL
rlm_realm: No such realm NULL
++[prefix_percent] returns noop
rlm_ldap: Entering ldap_groupcmp()
expand: cn cn=mycn,dc=mydc,dc=com - cn= cn=mycn,dc=mydc,dc=com
expand: (uid=%{User-Name}) - (uid=Catónio)
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in cn=mycn,dc=mydc,dc=com, with filter
(uid=Catónio)
rlm_ldap: object not found or got ambiguous search result
rlm_ldap::ldap_groupcmp: search failed
On 1/14/08, Alan DeKok [EMAIL PROTECTED] wrote:
nikitha george wrote:
Alan,
I tried with 2.0 release, still i am not able to get the user
authenticated. I am seeing the freeradius which logs the user name as
some different character instead of cató.
Any other idea? Or did u guys ever tried with this kind of characters in
user name?
I don't try it that often, but I haven tried it in the past.
Perhaps you could say *where* this is happening. i.e. include a debug
log, as suggested in the FAQ, README, INSTALL, etc. There may be places
in the server which haven't been updated to handle UTF-8.
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
Performance with Freeradius-1.1.4
Hi All, I am using freeradius-1.1.4 with PEAP-MSCHAPV2. Each session starting from Access-Request till Access-Accept it takes more than 250ms to complete. Is it the normal performance of freeradius-1.1.4 or anything suspicious in this regard? When i try to send many Request simultaneously then there is no response from the server for the latest requests as the server is busy processing first request. Only the first request gets response after 250ms. When i tried with some other RADIUS Server i could connect each mobile unit in some 150ms. Please let me know if anybody faced this problem with performance. Thanks, Nikitha - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Performance with Freeradius-1.1.4
Hi Alan, I regret for the late reply. Yes. I am running the server in single threaded mode. Will it be an overhead for taking more time? I verified the same by running in different high speed machine. It looks pretty okay. It took arround 150ms. So i am okay with this performance. But one more issue i am facing is when i try to connect 3 clients per second for 30 minutes with freeradius-1.1.6 only 200 or 250 clients are getting connected ( means 67 to 83 seconds the authentication happened) after that the clients are not getting connected, not seeing any Access-Accept going to the NAS. If I connect 2 clients per second then all the clients ( 2 per second for 30 minutes ) are getting connected. Please let me know what could be the reason for this? The log file is very huge.. if you could not figure out the issue with the above statistic it will send the log to the group. Thank you so much for all your help. Regards, Nikitha On 4/27/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha george wrote: I am using freeradius-1.1.4 with PEAP-MSCHAPV2. Each session starting from Access-Request till Access-Accept it takes more than 250ms to complete. Is it the normal performance of freeradius-1.1.4 or anything suspicious in this regard? It depends on your CPU speed, etc. But it's not out of line. Almost all of that time is spent in OpenSSL, doing cryptography. When i try to send many Request simultaneously then there is no response from the server for the latest requests as the server is busy processing first request. Only the first request gets response after 250ms. Are you sure you're not running the server in single threaded mode? 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: Performance with Freeradius-1.1.4
No. I am using local database. On 4/27/07, inverse [EMAIL PROTECTED] wrote: I am using freeradius-1.1.4 with PEAP-MSCHAPV2. Each session starting from Access-Request till Access-Accept it takes more than 250ms to complete. Is are you doing it against an LDAP server? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Very critical: Memory leak in freeradius-1.1.6
Hi, I am seeing a very serious memory leak issue with freeradius-1.1.6. The memory usage of freeradius gone from 3386Byte to 64MB when i was trying to connect 16 clients with roaming interval of 1 second. More Access-Requests are coming and we keep saving those requests until cleanup_delay. After my initial investigation in the souce code, we keep cleaning the requests only if the select() fails, which means no more request to handle. But in my case the clients are keep sending the request i think the cached request_list is not cleared properly or misses out some requests or something happens i guess. I may be wrong too, so please let me know what could be the root cause. Awaiting for any earliest reply. Thanks, Nikitha - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Performance with Freeradius-1.1.4
Hi Alan, I have not enabled full debugging with -X option. But syslog was enabled, all the logs were redirected to a remote syslog server. You want me to test with all the debugging including syslog turned off? Thanks, Nikitha On 5/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, If I connect 2 clients per second then all the clients ( 2 per second for 30 minutes ) are getting connected. Please let me know what could be the reason for this? The log file is very huge.. if you could not figure out the issue with the above statistic it will send the log to the group. is this with full debugging turned on? if so, try it with full debug off. the server will spend quite some time spewing that text out in debug mode alan - 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: Very critical: Memory leak in freeradius-1.1.6
So why is it happening in my case then? I can see all the requests gets cleaned up ( log message was put) but still so much memory is consumed by radiusd. You want me post the huge log file..? I badly need this fix now.. Configuration wise i am using the default configuration except users and clients entry added newly. Hoping to get some positive reply. Thanks, Nikitha On 5/18/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha george wrote: I am seeing a very serious memory leak issue with freeradius-1.1.6. The memory usage of freeradius gone from 3386Byte to 64MB when i was trying to connect 16 clients with roaming interval of 1 second. More Access-Requests are coming and we keep saving those requests until cleanup_delay. Yes... that's how the server is supposed to work. After my initial investigation in the souce code, we keep cleaning the requests only if the select() fails, No. It cleans the requests after it's examined all of the sockets for data. which means no more request to handle. But in my case the clients are keep sending the request i think the cached request_list is not cleared properly or misses out some requests or something happens i guess. I may be wrong too, so please let me know what could be the root cause. No. People are running the server with sustain loads of 100's of packets per second. There is no memory leak like you say. 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: Very critical: Memory leak in freeradius-1.1.6
Do you have any idea what kind of malloc/free implementation on our system will work out in this scenario? Thanks, Nikitha On 5/19/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha george wrote: So why is it happening in my case then? I can see all the requests gets cleaned up ( log message was put) but still so much memory is consumed by radiusd. When the server caches the requests, it uses memory to do that. When it frees the requests, the memory does *not* get returned to the system. This is usually due to the malloc/free implementation on your system, and cannot be controlled by the server. You want me post the huge log file..? I badly need this fix now.. Configuration wise i am using the default configuration except users and clients entry added newly. If your server really is that busy, then it needs that much memory to ensure it maintains quality service. If you make it use less memory, requests will be lost, and your network will suffer. 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: Very critical: Memory leak in freeradius-1.1.6
Hi Martin, Thanks for your reply. The memory usage of radiusd in our system went from 6687KB to 160MB which is 50.1% of memory of our system and radiusd got re-started. I had run the Valgrind to see the resource leak. Definitely lost memory was 380 Bytes but still reachable are more. I think this is the one which is leaking memory. I dont have access to the log files today, i will post it by tomorrow for your reference. Thanks, Nikitha On 5/19/07, Martin Gadbois [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 nikitha george wrote: So why is it happening in my case then? I can see all the requests gets cleaned up ( log message was put) but still so much memory is consumed by radiusd. Memory usage under Linux is a tricky thing. It depends if you're looking at RSS (RES in top), which is the actual RAM used by the process, or virtual memory (VIRT in top) which actually may map directly to disk and/or to RAM, and/or be shared with another process! A typical usage of a process the RES will rise, and then hit a plateau. Check the memory usage after a day, it should be the same the following week. If the RES raise linearly for days until the system trashes, you may have detected a memory leak. But to make sure a leak happens, usually tools like Valgrind helps better than looking at what the kernel reports, as there is a lot more hidden than what shows. - -- == +-+ Martin Gadbois | Please answer by yes or no.| Sr. SW Designer| Uncooperative user waste precious CPU time | Colubris Networks Inc. | -- The Andromeda Strain, M. Crichton, 1969 | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGThWW9Y3/iTTCEDkRAnOMAJ47LwlA9o48V/49KnahEtaaNWf+4QCfXTL1 HAza0Po1crhG3tHzf6OQIcY= =q2Gp -END PGP SIGNATURE- - 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: Very critical: Memory leak in freeradius-1.1.6
On 5/20/07, Alan DeKok [EMAIL PROTECTED] wrote: If valgrind doesn't say that the memory is lost, then the memory is very likely still being used. i.e. It's likely needed for something. something..? Why do radiusd need to hold the memory even after cleaning up the request? Even after stopping the request, the memory never gets freed. Why is this strange result of huge memory usage by radiusd? On 5/20/07, Alan DeKok [EMAIL PROTECTED] wrote: nikitha george wrote: The memory usage of radiusd in our system went from 6687KB to 160MB which is 50.1% of memory of our system and radiusd got re-started. 160Mb does sound like a lot. I had run the Valgrind to see the resource leak. Definitely lost memory was 380 Bytes but still reachable are more. I think this is the one which is leaking memory. I dont have access to the log files today, i will post it by tomorrow for your reference. The 380 bytes definitely lost is from libltdl. It contributed almost nothing to the 160M total memory used by the server. If valgrind doesn't say that the memory is lost, then the memory is very likely still being used. i.e. It's likely needed for something. 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: Very critical: Memory leak in freeradius-1.1.6
On 5/23/07, nikitha george [EMAIL PROTECTED] wrote: Please find the valgrind output below. It shows so much memory is still reachable. I guess we are not cleaning up the all the expired cached session at regular interval. ==21844== 7,456 bytes in 29 blocks are still reachable in loss record 33 of 44 ==21844==at 0x48054FB: realloc (vg_replace_malloc.c:306) ==21844==by 0x351D54: (within /lib/libcrypto.so.0.9.8b) ==21844==by 0x352486: CRYPTO_realloc (in /lib/libcrypto.so.0.9.8b) ==21844==by 0x3A4776: lh_insert (in /lib/libcrypto.so.0.9.8b) ==21844==by 0x355527: OBJ_NAME_add (in /lib/libcrypto.so.0.9.8b) ==21844==by 0x3AC41C: EVP_add_digest (in /lib/libcrypto.so.0.9.8b) ==21844==by 0x486EF91: SSL_library_init (in /lib/libssl.so.0.9.8b) ==21844==by 0x4BAAE03: eaptls_attach (rlm_eap_tls.c:287) ==21844==by 0x4B95230: eaptype_load (eap.c:122) ==21844==by 0x4B93D1B: eap_instantiate (rlm_eap.c:145) ==21844==by 0xCCBE: find_module_instance (modules.c:358) ==21844==by 0xDCBD: do_compile_modsingle (modcall.c:1005) ==21844== ==21844== ==21844== 10,692 bytes in 33 blocks are still reachable in loss record 34 of 44 ==21844==at 0x4805400: malloc (vg_replace_malloc.c:149) ==21844==by 0x4830106: pairmake (valuepair.c:1049) ==21844==by 0x4830A58: pairread (valuepair.c:1244) ==21844==by 0x4830C15: userparse (valuepair.c:1296) ==21844==by 0x9BAB: pairlist_read (files.c:200) ==21844==by 0x4BBB5FF: preprocess_instantiate (rlm_preprocess.c:493) ==21844==by 0xCCBE: find_module_instance (modules.c:358) ==21844==by 0xDCBD: do_compile_modsingle (modcall.c:1005) ==21844==by 0xD34C: setup_modules (modules.c:580) ==21844==by 0x10A35: main (radiusd.c:965) ==21844== ==21844== ==21844== 13,325 bytes in 21 blocks are still reachable in loss record 35 of 44 ==21844==at 0x480473F: calloc (vg_replace_malloc.c:279) ==21844==by 0x4FE8F57A: _dl_new_object (in /lib/ld-2.5.so) ==21844==by 0x4FE8B0E0: _dl_map_object_from_fd (in /lib/ld-2.5.so) ==21844==by 0x4FE8D403: _dl_map_object (in /lib/ld-2.5.so) ==21844==by 0x4FE96668: dl_open_worker (in /lib/ld-2.5.so) ==21844==by 0x4FE92C05: _dl_catch_error (in /lib/ld-2.5.so) ==21844==by 0x4FE96191: _dl_open (in /lib/ld-2.5.so) ==21844==by 0x419BCD0C: dlopen_doit (in /lib/libdl-2.5.so) ==21844==by 0x4FE92C05: _dl_catch_error (in /lib/ld-2.5.so) ==21844==by 0x419BD38B: _dlerror_run (in /lib/libdl-2.5.so) ==21844==by 0x419BCC43: dlopen@@GLIBC_2.1 (in /lib/libdl-2.5.so) ==21844==by 0x48392A9: sys_dl_open (ltdl.c:958) ==21844== ==21844== ==21844== 15,808 bytes in 670 blocks are still reachable in loss record 36 of 44 ==21844==at 0x4805400: malloc (vg_replace_malloc.c:149) ==21844==by 0x418C001F: strdup (in /lib/libc-2.5.so) ==21844==by 0x79D7: cf_section_read (conffile.c:207) ==21844==by 0x8094: conf_read (conffile.c:917) ==21844==by 0xB55D: read_radius_conf_file (mainconfig.c:1264) ==21844==by 0xB6A5: read_mainconfig (mainconfig.c:1309) ==21844==by 0x109F2: main (radiusd.c:941) ==21844== ==21844== ==21844== 26,768 bytes in 336 blocks are still reachable in loss record 37 of 44 ==21844==at 0x4805400: malloc (vg_replace_malloc.c:149) ==21844==by 0x4B944E1: eap_compose (eap.c:395) ==21844==by 0x4B93AC8: eap_authenticate (rlm_eap.c:341) ==21844==by 0xE3C7: modcall (modcall.c:236) ==21844==by 0xEA6B: call_one (modcall.c:269) ==21844==by 0xE5B9: modcall (modcall.c:324) ==21844==by 0xC63D: indexed_modcall (modules.c:469) ==21844==by 0x5213: rad_check_password (auth.c:380) ==21844==by 0x579A: rad_authenticate (auth.c:675) ==21844==by 0xFC66: rad_respond (radiusd.c:1675) ==21844==by 0x116B1: main (radiusd.c:1440) ==21844== ==21844== ==21844== 49,152 bytes in 4 blocks are still reachable in loss record 38 of 44 ==21844==at 0x4805400: malloc (vg_replace_malloc.c:149) ==21844==by 0x4825B3F: lrad_hash_table_insert (hash.c:375) ==21844==by 0x4822AAF: dict_addattr (dict.c:478) ==21844==by 0x482316B: my_dict_init (dict.c:744) ==21844==by 0x4822F71: my_dict_init (dict.c:1050) ==21844==by 0x4822F71: my_dict_init (dict.c:1050) ==21844==by 0x4823DC5: dict_init (dict.c:1258) ==21844==by 0xB5AF: read_radius_conf_file (mainconfig.c:1276) ==21844==by 0xB6A5: read_mainconfig (mainconfig.c:1309) ==21844==by 0x109F2: main (radiusd.c:941) ==21844== ==21844== ==21844== 64,892 bytes in 1,704 blocks are still reachable in loss record 39 of 44 ==21844==at 0x4805400: malloc (vg_replace_malloc.c:149) ==21844==by 0x153DC: rad_malloc (util.c:308) ==21844==by 0x79AE: cf_section_read (conffile.c:203) ==21844==by 0x8094: conf_read (conffile.c:917) ==21844==by 0xB55D: read_radius_conf_file (mainconfig.c:1264) ==21844==by 0xB6A5: read_mainconfig (mainconfig.c:1309) ==21844==by 0x109F2: main (radiusd.c:941) ==21844== ==21844== ==21844== 136,877 bytes in 5,331 blocks are still
