Re: about eap_handler
Both. I have committed a fix to CVS head that: I tried to make a patch for FR-1.1.7 like that fix. but, When it continue to receive EAP-Identity only(Dos Attack), 1) growing up memory usage of radiusd. 2) over max_sessions, growing up memory usage stopped. it is ok. 3) but, starting expiring old handler and add new handler, growing up memory usage of radiusd, again. to expiring eap handler, only call eap_handler_free() ? is there other memory leak still ? do you have any idea ? another question, do you think about that... to ignoring EAP-Identity when over max_sessions, what kind of state is should return at eap_authenticate()? PW_MODULE_FAIL or NOOP or REJECT ? # I'm sorry, do you understand my english? --- [EMAIL PROTECTED] wrote: Alan DeKok [EMAIL PROTECTED] wrote: Both. I have committed a fix to CVS head that: - limits the number of sessions (2k is the default) - expires sessions in eaplist_add() thank you. I will try to make a patch for FR-1.1.7. -- GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points! http://pr.mail.yahoo.co.jp/ganbare-nippon/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: about eap_handler
Thank you for your reply. Alan DeKok [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: but it look like that: When radiusd received EAP-Identify request, eaplist_add(inst, handler) called in eap_authenticate() in rlm_eap.c, and the handler is allocated by eap_handler_alloc() in eap_handler() in eap.c. Hmm... OK. So long as one non-identity packet comes through, this shouldn't be a problem. Yes, It is the problem that received malicious EAP Identity DoS attack. But OK, I'll look into fixing that in the next release. if possible, we want to fix that in FR 1.1.7. Which way better do you think ? - in eaplist_add(), expire the eap_handler same as eaplist_find(). or.. - if it continue to receive EAP Identity over limit number, no more add to list and ignore. (if it receive non-identity packet, reset counter). or other way ... -- GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points! http://pr.mail.yahoo.co.jp/ganbare-nippon/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: about eap_handler
Alan DeKok [EMAIL PROTECTED] wrote: Both. I have committed a fix to CVS head that: - limits the number of sessions (2k is the default) - expires sessions in eaplist_add() thank you. I will try to make a patch for FR-1.1.7. -- GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points! http://pr.mail.yahoo.co.jp/ganbare-nippon/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
about eap_handler
Hi, I'm sorry that I am not good at English because I'm Japanese... I have a question about eap_handler. I understand that... if radiusd recieved EAP-Identify packet, eap_handler is allocated and added to eaplist. if radiusd will be not received next EAP packet(except EAP-Identiry) forever, When is the eap_handler deleted from the eaplist and freed ? will radiusd use too large memory by 'Dos attack using EAP-Identiry' ? -- GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points! http://pr.mail.yahoo.co.jp/ganbare-nippon/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: about eap_handler
Thank you for your reply.
if radiusd will be not received
next EAP packet(except EAP-Identiry) forever,
When is the eap_handler deleted from the eaplist and freed ?
See the source code. eaplist_find() will remove expired sessions
from
the list.
I found calling eaplist_find() in eap.c,
if (eap_packet-data[0] != PW_EAP_IDENTITY) {
handler = eaplist_find(inst, request, eap_packet);
}
If radiusd continue receiving EAP-Identiry packet only
(it is malicious attack, not many trying to login.),
is eaplist_find() called ?
--
GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points!
http://pr.mail.yahoo.co.jp/ganbare-nippon/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: about eap_handler
If radiusd continue receiving EAP-Identiry packet only (it is malicious attack, not many trying to login.), is eaplist_find() called ? No. But this doesn't matter, because EAP-Identity requests aren't put into the list. Again, this is in the source code. I'm sorry ... but it look like that: When radiusd received EAP-Identify request, eaplist_add(inst, handler) called in eap_authenticate() in rlm_eap.c, and the handler is allocated by eap_handler_alloc() in eap_handler() in eap.c. -- GANBARE! NIPPON! Chance to win 50,000 Yahoo! Points! http://pr.mail.yahoo.co.jp/ganbare-nippon/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
1 byte leak ?
Hi,
I'm *sorry* that I am not good at English
because I'm Japanese.
I found memory leak(?) of 1 byte when PEAP authentication, by valgrind.
I tried fllowing patch for rlm_eap.
it look like work well.
is it corret way?
diff -urN ../freeradius-1.1.7/src/modules/rlm_eap/eap.c
./src/modules/rlm_eap/eap.c
--- ../freeradius-1.1.7/src/modules/rlm_eap/eap.c 2007-04-08
07:18:34.0 +0900
+++ ./src/modules/rlm_eap/eap.c 2007-10-10 02:44:20.0 +0900
@@ -421,6 +421,11 @@
*/
if (reply-type.data reply-type.length 0) {
memcpy(hdr-data[1], reply-type.data,
reply-type.length);
+
+ // 2007/10/09 workaround for memory leak.
+ DEBUG2( rlm_eap: in %s() in %s Freeing
reply-type.data 0x%x, __func__, __FILE__, (unsigned
int)reply-type.data);
+ reply-type.bNeedFreeData = 0;
+
free(reply-type.data);
reply-type.data = reply-packet + EAP_HEADER_LEN +
1/*EAPtype*/;
}
diff -urN ../freeradius-1.1.7/src/modules/rlm_eap/libeap/eap_tls.c
./src/modules/rlm_eap/libeap/eap_tls.c
--- ../freeradius-1.1.7/src/modules/rlm_eap/libeap/eap_tls.c2007-04-08
06:27:19.0 +0900
+++ ./src/modules/rlm_eap/libeap/eap_tls.c 2007-10-09
22:39:14.0 +0900
@@ -808,6 +808,10 @@
return 0;
}
+ // 2007/10/09 workaround for memory leak.
+ DEBUG2( rlm_eap: in %s() Malloc(%d) for
eap_ds-request-type.data 0x%x, __func__, (reply-length - TLS_HEADER_LEN
+ 1), (unsigned int)eap_ds-request-type.data);
+ eap_ds-request-type.bNeedFreeData = 1;
+
/* EAPTLS Header length is excluded while computing EAP typelen */
eap_ds-request-type.length = reply-length - TLS_HEADER_LEN;
diff -urN ../freeradius-1.1.7/src/modules/rlm_eap/libeap/eap_types.h
./src/modules/rlm_eap/libeap/eap_types.h
--- ../freeradius-1.1.7/src/modules/rlm_eap/libeap/eap_types.h 2006-05-19
23:19:15.0 +0900
+++ ./src/modules/rlm_eap/libeap/eap_types.h2007-10-09
20:51:14.0 +0900
@@ -88,6 +88,9 @@
unsigned char type;
unsigned intlength;
unsigned char *data;
+
+ // 2007/10/09 workaround for memory leak.
+ unsigned intbNeedFreeData;
} eaptype_t;
/*
diff -urN ../freeradius-1.1.7/src/modules/rlm_eap/libeap/eapcommon.c
./src/modules/rlm_eap/libeap/eapcommon.c
--- ../freeradius-1.1.7/src/modules/rlm_eap/libeap/eapcommon.c 2007-03-05
23:34:55.0 +0900
+++ ./src/modules/rlm_eap/libeap/eapcommon.c2007-10-10
02:43:30.0 +0900
@@ -216,6 +216,11 @@
*/
if (reply-type.data reply-type.length 0) {
memcpy(hdr-data[1], reply-type.data,
reply-type.length);
+
+ // 2007/10/09 workaround for memory leak.
+ DEBUG2( rlm_eap: in %s() in %s Freeing
reply-type.data 0x%x, __func__, __FILE__, (unsigned
int)reply-type.data);
+ reply-type.bNeedFreeData = 0;
+
free(reply-type.data);
reply-type.data = reply-packet + EAP_HEADER_LEN +
1/*EAPtype*/;
}
@@ -386,6 +391,11 @@
ep.type.type = eap_type;
ep.type.length = vp-length;
ep.type.data = malloc(vp-length);
+
+ // 2007/10/09 workaround for memory leak.
+ DEBUG2( rlm_eap: in %s() Malloc(%d) for ep.type.data
0x%x, __func__, vp-length, (unsigned int)ep.type.data);
+ ep.type.bNeedFreeData = 1;
+
memcpy(ep.type.data,vp-strvalue, vp-length);
eap_basic_compose(req, ep);
}
diff -urN ../freeradius-1.1.7/src/modules/rlm_eap/mem.c
./src/modules/rlm_eap/mem.c
--- ../freeradius-1.1.7/src/modules/rlm_eap/mem.c 2007-02-10
00:42:03.0 +0900
+++ ./src/modules/rlm_eap/mem.c 2007-10-09 22:40:28.0 +0900
@@ -54,6 +54,14 @@
* so we do not free it but we NULL it
free(eap_packet-type.data);
*/
+
+ // 2007/10/09 workaround for memory leak.
+ if(eap_packet-type.bNeedFreeData) {
+ DEBUG2( rlm_eap: in %s() Freeing
eap-packet-type.data 0x%x, __func__, (unsigned
int)eap_packet-type.data);
+ eap_packet-type.bNeedFreeData = 0;
+ free(eap_packet-type.data);
+ }
+
eap_packet-type.data = NULL;
}
--
New Design Yahoo! JAPAN 2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
need patch to inst-session_tail clear ?
Hi, I'm *sorry* that I am not good at English because I'm Japanese I think that it is need following patch for eaplist_find() in rlm_eap/mem.c, FreeRADIUS 1.1.7. if no patch, when session_head == NULL and session_tail != NULL, add handler to TAIL in next eaplist_add(). How do you think about it? diff -urN ../freeradius-1.1.7/src/modules/rlm_eap/mem.c ./src/modules/rlm_eap/mem.c --- ../freeradius-1.1.7/src/modules/rlm_eap/mem.c 2007-02-10 00:42:03.0 +0900 +++ ./src/modules/rlm_eap/mem.c 2007-12-07 12:32:23.0 +0900 @@ -301,6 +301,9 @@ rbtree_delete(inst-session_tree, node); inst-session_head = handler-next; + //--- 2007/12/07 added --- + if(!inst-session_head) inst-session_tail = NULL; + // if (handler-next) handler-next-prev = NULL; eap_handler_free(handler); } -- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radiusd stop responding. deadlock?
Thank you for your reply, Mr.DeKok. Use 1.1.6. It has a NUMBER of bugs fixed over 1.1.0. ok, I will consider it. but 1.1.6 crash when it recieve SIGHUP ... Hmmm... I think that stopping responding in our site is similar following reports. 2007-February/060174.html 2006-March/051900.html Are these problem resolved ? Is not Port OpenSSL locking fixes from CVS head (in ChangeLog for 1.1.5) related ? --- Alan DeKok [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: We using freeradius 1.1.0 for PEAP authentication, and it is working well almost. Use 1.1.6. It has a NUMBER of bugs fixed over 1.1.0. ... (gdb) attach 10127 Attaching to program: /usr/dot1x/sbin/radiusd, process 10127 Symbols already loaded for /lib/libcrypt.so.1 (snip)... 0x401998cc in pthread_mutex_trylock () from /lib/libpthread.so.0 (gdb) whrere #0 0x401998cc in pthread_mutex_trylock () from /lib/libpthread.so.0 If the code is blocking in the libc malloc() implementation, there isn't much that FreeRADIUS can do to fix that. Try upgrading to 1.1.6, and see if that fixes it. I don't know... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
radiusd stop responding. deadlock?
Hi, I'm *sorry* that I am not good at English because I'm Japanese. We using freeradius 1.1.0 for PEAP authentication, and it is working well almost. but sometime, radiusd stops responding.CPU usage is 100%. (need to radiusd stop/start). following is result of ps. #ps -efml | grep radius 1 S root 10134 10127 0 69 0- 7395 148a46 Jun19 ? 00:00:00 /usr/dot1x/sbin/radiusd -d /e tc/raddb -l syslog -g local0 -x 1 S root 17737 10134 0 69 0- 7395 10800b Jun19 ? 00:00:01 /usr/dot1x/sbin/radiusd -d /e tc/raddb -l syslog -g local0 -x 1 S root 17835 10134 0 68 0- 7395 10800b Jun19 ? 00:00:00 /usr/dot1x/sbin/radiusd -d /e tc/raddb -l syslog -g local0 -x 0 R root 10127 1 47 80 0- 7395 - Jun19 ? 19:24:13 /usr/dot1x/sbin/radiusd -d /e tc/raddb -l syslog -g local0 -x 1 S root 17769 10134 0 69 0- 7395 10800b Jun19 ? 00:00:01 /usr/dot1x/sbin/radiusd -d /e tc/raddb -l syslog -g local0 -x 1 R root 17800 10134 49 76 0- 7395 - Jun19 ? 19:19:02 /usr/dot1x/sbin/radiusd -d /e tc/raddb -l syslog -g local0 -x 1 S root 17713 10134 0 69 0- 7395 10800b Jun19 ? 00:00:01 /usr/dot1x/sbin/radiusd -d /e tc/raddb -l syslog -g local0 -x pid:10127(main) eats 47% CPU. pid:17800 eats 49% CPU. following is result of gdb about these thread. # gdb GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-slackware-linux. (gdb) attach 10127 Attaching to process 10127 Reading symbols from /usr/dot1x/sbin/radiusd...(no debugging symbols found)... done. (snip)... 0x4019a072 in pthread_once () from /lib/libpthread.so.0 (gdb) where #0 0x4019a072 in pthread_once () from /lib/libpthread.so.0 #1 0x4027df03 in malloc () from /lib/libc.so.6 #2 0x401eae87 in rad_recv () from /usr/dot1x/lib/libradius-1.1.0.so #3 0x0804d78b in main () #4 0x4021cd06 in __libc_start_main () from /lib/libc.so.6 (gdb) detach Detaching from program: /usr/dot1x/sbin/radiusd, process 10127 (gdb) (gdb) (gdb) attach 10127 Attaching to program: /usr/dot1x/sbin/radiusd, process 10127 Symbols already loaded for /lib/libcrypt.so.1 (snip)... 0x401998cc in pthread_mutex_trylock () from /lib/libpthread.so.0 (gdb) whrere #0 0x401998cc in pthread_mutex_trylock () from /lib/libpthread.so.0 #1 0x4027c65f in _IO_file_xsputn () from /lib/libc.so.6 #2 0x4027df03 in malloc () from /lib/libc.so.6 #3 0x401eae87 in rad_recv () from /usr/dot1x/lib/libradius-1.1.0.so #4 0x0804d78b in main () #5 0x4021cd06 in __libc_start_main () from /lib/libc.so.6 (gdb) detach Detaching from program: /usr/dot1x/sbin/radiusd, process 10127 (gdb) (gdb) attach 17800 Attaching to program: /usr/dot1x/sbin/radiusd, process 17800 Symbols already loaded for /lib/libcrypt.so.1 (snip)... 0x4027f4b0 in mallopt () from /lib/libc.so.6 (gdb) (gdb) where #0 0x4027f4b0 in mallopt () from /lib/libc.so.6 #1 0x4027ed83 in mallopt () from /lib/libc.so.6 #2 0x4027df1a in malloc () from /lib/libc.so.6 #3 0x4038a2e9 in ber_memalloc_x () from /usr/dot1x/lib/liblber-2.2.so.7 #4 0x4038a478 in ber_memrealloc_x () from /usr/dot1x/lib/liblber-2.2.so.7 #5 0x40388790 in ber_realloc () from /usr/dot1x/lib/liblber-2.2.so.7 #6 0x403886b4 in ber_write () from /usr/dot1x/lib/liblber-2.2.so.7 #7 0x40387179 in ber_put_tag () from /usr/dot1x/lib/liblber-2.2.so.7 #8 0x40387404 in ber_put_int_or_enum () from /usr/dot1x/lib/liblber-2.2.so.7 #9 0x40388416 in ber_printf () from /usr/dot1x/lib/liblber-2.2.so.7 #10 0x403612f2 in ldap_build_search_req () from /usr/dot1x/lib/libldap-2.2.so.7 #11 0x403611da in ldap_search () from /usr/dot1x/lib/libldap-2.2.so.7 #12 0x40361432 in ldap_search_st () from /usr/dot1x/lib/libldap-2.2.so.7 #13 0x4033f803 in _init () from /usr/dot1x/lib/rlm_ldap-1.1.0.so #14 0x403400d6 in _init () from /usr/dot1x/lib/rlm_ldap-1.1.0.so #15 0x08050c19 in vp_listdebug () #16 0x08050fde in paircmp () #17 0x403f820f in _init () from /usr/dot1x/lib/rlm_files-1.1.0.so #18 0x08057c99 in module_post_auth () #19 0x080582df in modcall () #20 0x08057d0f in module_post_auth () #21 0x08057e06 in module_post_auth () #22 0x08058254 in modcall () #23 0x08057d0f in module_post_auth () #24 0x08057e06 in module_post_auth () #25 0x08058254 in modcall () #26 0x08056fff in find_module_instance () #27 0x080578f0 in module_authorize () #28 0x08053aa3 in rad_authenticate () #29 0x0804dcf8 in rad_respond () #30 0x0805b5a0 in radius_xlat () #31 0x40198ca3 in pthread_detach () from /lib/libpthread.so.0 (gdb) detach Detaching from program: /usr/dot1x/sbin/radiusd, process 17800 (gdb)
