Re: Freeradius crash during EAP-TTLS authentication

[Thomas Fagart]

Hello,

After three month having stable situation, the ISP home servers has 
started again to loose packet and to have slow response time, then our 
freeradius proxies has began to crash again.


We've reproduced the crash with the Git version.

Here's the output that I got with gdb


Going to the next request
rad_recv: Accounting-Request packet from host X.X.X.X port 1812, id=124, 
length=520
Received conflicting packet from client bas-man72-02 port 1812 - ID: 124 
due to unfinished request 715241.  Giving up on old request.

ASSERT FAILED event.c[2773]: request->ev != NULL

Program received signal SIGABRT, Aborted.
[Switching to Thread 8012021c0 (LWP 100143)]
0x000800fb978c in kill () from /lib/libc.so.7
(gdb)


(gdb) thread apply all bt full

Thread 2 (Thread 8012021c0 (LWP 100143)):
#0  0x000800fb978c in kill () from /lib/libc.so.7
No symbol table info available.
#1  0x000800fb858b in abort () from /lib/libc.so.7
No symbol table info available.
#2  0x00420cd4 in rad_assert_fail (file=Variable "file" is not 
available.

) at util.c:366
No locals.
#3  0x00429d9a in received_request (listener=0x801fdcac0, 
packet=0x8051c1900, prequest=0x7fffe4d0, client=0x801fdaa80) at 
event.c:2773

when = {tv_sec = 1340876260, tv_usec = 138114}
packet_p = Variable "packet_p" is not available.

Is there enough information for this bug ?
Do you want me to get some more information ?

I can provide smokeping graphs that shows packet loss and slow response 
time (3 seconds)


Many thanks

Thomas


Le 29/03/2012 23:04, Thomas Fagart a écrit :

Many thanks, I will test it when available.


Thomas

Le 28/03/2012 17:15, Alan DeKok a écrit :

Thomas Fagart wrote:

Here's the debug output this happens specialy when we add a virtual
server as a fallback server.
   OK... it looks like the proxy_reply doesn't exist.  I'll push a 
patch.


   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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash during EAP-TTLS authentication

[Alan DeKok]

Thomas Fagart wrote:
> Did you have the opportunity to push this patch ?

  Yes.  See github.com

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash during EAP-TTLS authentication

[Thomas Fagart]

Hello,

Did you have the opportunity to push this patch ?

The crash does not occur very soon (around once a month).

Many thanks

Regards

Thomas

On 28.03.2012 17:15, Alan DeKok wrote:

Thomas Fagart wrote:

Here's the debug output this happens specialy when we add a virtual
server as a fallback server.


  OK... it looks like the proxy_reply doesn't exist.  I'll push a 
patch.


  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 crash with two radclient

[fulvio fabiani]

Hi all,
we did several test using UnixODBC instead of OCI driver, results are good
and issue seems to be fixed.

Thanks all
Fulvio


2012/3/22 Alan DeKok 

> fulvio fabiani wrote:
> > Hi all,
> > sorry for the misunderstanding.
> >
> > We execute same test (with two radClient) on Freeradius 2.1.12 following
> > the instruction in "doc/bugs" documentation, result is the same.
> > Find attached the output.
>
>   It's crashing in the Oracle libraries.
>
>  You're probably not using the correct Oracle libraries for your machine.
>
>  This isn't a FreeRADIUS problem.
>
>  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 crash during EAP-TTLS authentication

[Thomas Fagart]

Many thanks, I will test it when available.


Thomas

Le 28/03/2012 17:15, Alan DeKok a écrit :

Thomas Fagart wrote:

Here's the debug output this happens specialy when we add a virtual
server as a fallback server.

   OK... it looks like the proxy_reply doesn't exist.  I'll push a patch.

   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 crash during EAP-TTLS authentication

[Alan DeKok]

Thomas Fagart wrote:
> Here's the debug output this happens specialy when we add a virtual
> server as a fallback server.

  OK... it looks like the proxy_reply doesn't exist.  I'll push a patch.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash during EAP-TTLS authentication

[Thomas Fagart]

Hello,

Here's the debug output this happens specialy when we add a virtual 
server as a fallback server.




Finished request 75.
Going to the next request
Waking up in 0.1 seconds.
rad_recv: Access-Request packet from host X.Y.Z.W port 34405, id=225, 
length=389
# Executing section post-proxy from file 
/usr/local/etc/raddb/sites-enabled/proxy_alu_huawei

+- entering group post-proxy {...}
[eap_alu_huawei] Doing post-proxy callback
[eap_alu_huawei] Passing reply from proxy back into the tunnel.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8011021c0 (LWP 100073)]
0x0008036e05dd in eapttls_postproxy (handler=0x802964800, 
data=0x804017000) at ttls.c:816
816 if (fake && (handler->request->proxy_reply->code == 
PW_AUTHENTICATION_ACK)) {

(gdb) where
#0  0x0008036e05dd in eapttls_postproxy (handler=0x802964800, 
data=0x804017000) at ttls.c:816
#1  0x0008031c66e7 in eap_post_proxy (inst=0x802940200, 
request=0x801137200) at rlm_eap.c:607
#2  0x0041b4eb in modcall (component=6, c=Variable "c" is not 
available.

) at modcall.c:297
#3  0x0041869e in indexed_modcall (comp=4284416, idx=0, 
request=0x801137200) at modules.c:737
#4  0x004234f2 in process_proxy_reply (request=0x801137200) at 
event.c:1734
#5  0x0042361b in request_pre_handler (request=0x801137200) at 
event.c:1859
#6  0x0042670b in radius_handle_request (request=0x801137200, 
fun=0x426ac0 ) at event.c:3773
#7  0x0041ed34 in thread_pool_addrequest (request=0x801137200, 
fun=0x426ac0 ) at threads.c:886
#8  0x00428e80 in received_request (listener=0x802963a80, 
packet=0x80297e800, prequest=0x7fffe470, client=0x801170cc0) at 
event.c:917
#9  0x00414a33 in auth_socket_recv (listener=0x802963a80, 
pfun=0x7fffe478, prequest=0x7fffe470) at listen.c:857
#10 0x0042397e in event_socket_handler (xel=Variable "xel" is 
not available.

) at event.c:3423
#11 0x00080069aa42 in fr_event_loop (el=0x802971000) at event.c:415
#12 0x0041bf7a in main (argc=Variable "argc" is not available.
) at radiusd.c:408
(gdb) info threads
* 2 Thread 8011021c0 (LWP 100073)  0x0008036e05dd in 
eapttls_postproxy (handler=0x802964800, data=0x804017000) at ttls.c:816

(gdb) thread apply all bt full

Thread 2 (Thread 8011021c0 (LWP 100073)):
#0  0x0008036e05dd in eapttls_postproxy (handler=0x802964800, 
data=0x804017000) at ttls.c:816

rcode = Variable "rcode" is not available.


Hope that help

Regards

Thomas


Le 06/03/2012 10:29, Alan DeKok a écrit :

Thomas Fagart wrote:

Last week we've migrate Motorola authentication on freeradius. (no more
radiator :-) ).

   Nice.


But then we've experienced freeradius crash.

   Not so nice.


The crash usually happen when home servers (ISP radius) does not
respond, then the radius load goes up to 50/60 requests per second and
after 40/50 minutes the radius crash.

   That kind of situation is hard to test.


It seems this is more related to SSL issue ?

   Maybe.  It's hard to know.


Could you confirm this idea is correct ?

I can compile the radius in gdb to get more information if this is usefull.

   Yes.  See doc/bugs for complete instructions.

   Also, try compiking with debugging flags, and using valgrind.

   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 crash with two radclient

[Alan DeKok]

fulvio fabiani wrote:
> Hi all,
> sorry for the misunderstanding.
> 
> We execute same test (with two radClient) on Freeradius 2.1.12 following
> the instruction in "doc/bugs" documentation, result is the same.
> Find attached the output.

  It's crashing in the Oracle libraries.

  You're probably not using the correct Oracle libraries for your machine.

  This isn't a FreeRADIUS problem.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[fulvio fabiani]

Hi all,
please find attached also the output produced executing same test with
2.1.X GIT version,

Best regards
Fulvio


2012/3/22 fulvio fabiani 

> Hi all,
> sorry for the misunderstanding.
>
> We execute same test (with two radClient) on Freeradius 2.1.12 following
> the instruction in "doc/bugs" documentation, result is the same.
> Find attached the output.
>
>
> We are now executing same test on freeradius v2.1.x GIT, I will update
> with the results,
>
>
> Best Regards
> Fulvio
>
>
>
> 2012/3/22 Alan DeKok 
>
>> fulvio fabiani wrote:
>> > Yes I know,
>> > we did not yet test the latest 2.1.x GIT release and test with 2.1.12 or
>> > 2.1.11 give same results.
>> >
>> > Is it mandatory?
>>
>>   It's mandatory to follow instructions on this list.
>>
>>  You were asked to do certain things which would let us help you.
>> You've ignored those instructions, and done something *else*.  That is
>> useless, and wasting our time.
>>
>>  If you're not going to follow instructions, you will be unsubscribed
>> from this list.  It's the only way we've found to convince people that
>> they DO NEED to follow instructions.
>>
>>  Alan DeKok.
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
>
Starting program: /product/freeradius-server-2.1.x/sbin/radiusd -fxx
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x2aaab000
[Thread debugging using libthread_db enabled]
[New Thread 0x40a00940 (LWP 12373)]
[New Thread 0x41401940 (LWP 12374)]
[New Thread 0x41e02940 (LWP 12375)]
[New Thread 0x42803940 (LWP 12376)]
[New Thread 0x43204940 (LWP 12377)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x42803940 (LWP 12376)]
0x2aaab0508fab in slaac_int () from 
/product/oracle/client//lib/libclntsh.so.11.1
  6 Thread 0x43204940 (LWP 12377)  0x003d3ee0d91b in read () from 
/lib64/libpthread.so.0
* 5 Thread 0x42803940 (LWP 12376)  0x2aaab0508fab in slaac_int () from 
/product/oracle/client//lib/libclntsh.so.11.1
  4 Thread 0x41e02940 (LWP 12375)  0x003d3ee0cd01 in sem_wait () from 
/lib64/libpthread.so.0
  3 Thread 0x41401940 (LWP 12374)  0x003d3ee0cd01 in sem_wait () from 
/lib64/libpthread.so.0
  2 Thread 0x40a00940 (LWP 12373)  0x003d3ee0cd01 in sem_wait () from 
/lib64/libpthread.so.0
  1 Thread 0x2aef45b0 (LWP 12370)  0x003d3e2cd372 in select () from 
/lib64/libc.so.6

Thread 6 (Thread 0x43204940 (LWP 12377)):
#0  0x003d3ee0d91b in read () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x2aaab1b6c584 in snttread () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#2  0x2aaab1b6b515 in nttfprd () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#3  0x2aaab1b5f8c8 in nsbasic_brc () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#4  0x2aaab1b62e2b in nsbrecv () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#5  0x2aaab1b51ef3 in nioqrc () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#6  0x2aaab1baac4d in ttcdrv () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#7  0x2aaab1b588f5 in nioqwa () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#8  0x2aaab1b450b5 in upirtrc () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#9  0x2aaab1b4b706 in kpurcsc () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#10 0x2aaab1b48a6f in kpuexec () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#11 0x2aaab1b45bf1 in OCIStmtExecute () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#12 0x2f92b39a in ora_st_execute () from 
/usr/lib/perl5/5.14.1/lib/site_perl/5.14.1/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
No symbol table info available.
#13 0x2f91c56b in XS_DBD__Oracle__st_execute () from 
/usr/lib/perl5/5.14.1/lib/site_perl/5.14.1/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
No symbol table info available.
#14 0x2f502c4c in XS_DBI_dispatch () from 
/usr/lib/perl5/5.14.1/lib/site_perl/5.14.1/x86_64-linux-thread-multi/auto/DBI/DBI.so
No symbol table info available.
#15 0x0038fc2adcb3 in Perl_pp_entersub () from 
/usr/lib/perl5/5.14.1/lib/5.14.1/x86_64-linux-thread-multi/CORE/libperl.so
No symbol table info available.
#16 0x0038fc2ac2fe in Perl_runops_standard () from 
/usr/lib/perl5/5.14.1/lib/5.14.1/x86_64-linux-thread-multi/CORE/libperl.so
No symbol table info available.
#17 0x0038fc24629b in Perl_call_sv () from 
/usr/lib/perl5/5.14.1/lib/5.14.1/x86_64-linux-thread-multi/CORE/libperl.so
No symbol table info available.
#18 0x2bb0ea3a in rlmperl_call (instance=0x7b1780, 
request=0x2aaab80014f0, f

Re: Freeradius crash with two radclient

[fulvio fabiani]

Hi all,
sorry for the misunderstanding.

We execute same test (with two radClient) on Freeradius 2.1.12 following
the instruction in "doc/bugs" documentation, result is the same.
Find attached the output.


We are now executing same test on freeradius v2.1.x GIT, I will update with
the results,


Best Regards
Fulvio


2012/3/22 Alan DeKok 

> fulvio fabiani wrote:
> > Yes I know,
> > we did not yet test the latest 2.1.x GIT release and test with 2.1.12 or
> > 2.1.11 give same results.
> >
> > Is it mandatory?
>
>   It's mandatory to follow instructions on this list.
>
>  You were asked to do certain things which would let us help you.
> You've ignored those instructions, and done something *else*.  That is
> useless, and wasting our time.
>
>  If you're not going to follow instructions, you will be unsubscribed
> from this list.  It's the only way we've found to convince people that
> they DO NEED to follow instructions.
>
>  Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
Starting program: /product/freeradius-server-2.1.12_oracle_full/sbin/radiusd 
-fxx
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x2aaab000
[Thread debugging using libthread_db enabled]
[New Thread 0x40a00940 (LWP 12148)]
[New Thread 0x41401940 (LWP 12149)]
[New Thread 0x41e02940 (LWP 12150)]
[New Thread 0x42803940 (LWP 12151)]
[New Thread 0x43204940 (LWP 12152)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40a00940 (LWP 12148)]
0x2aaab0500fab in slaac_int () from 
/product/oracle/client//lib/libclntsh.so.11.1
  6 Thread 0x43204940 (LWP 12152)  0x003d3ee0cd01 in sem_wait () from 
/lib64/libpthread.so.0
  5 Thread 0x42803940 (LWP 12151)  0x003d3ee0d4c4 in __lll_lock_wait () 
from /lib64/libpthread.so.0
  4 Thread 0x41e02940 (LWP 12150)  0x003d3ee0cd01 in sem_wait () from 
/lib64/libpthread.so.0
  3 Thread 0x41401940 (LWP 12149)  0x003d3ee0d91b in read () from 
/lib64/libpthread.so.0
* 2 Thread 0x40a00940 (LWP 12148)  0x2aaab0500fab in slaac_int () from 
/product/oracle/client//lib/libclntsh.so.11.1
  1 Thread 0x2aeec1a0 (LWP 12145)  0x003d3e2cd372 in select () from 
/lib64/libc.so.6

Thread 6 (Thread 0x43204940 (LWP 12152)):
#0  0x003d3ee0cd01 in sem_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x0041e4a4 in request_handler_thread (arg=) at 
threads.c:498
fun = 0x407de0 
self = 0xb4dc10
#2  0x003d3ee0673d in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3  0x003d3e2d40cd in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 5 (Thread 0x42803940 (LWP 12151)):
#0  0x003d3ee0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x003d3ee08e35 in _L_lock_1127 () from /lib64/libpthread.so.0
No symbol table info available.
#2  0x003d3ee08d33 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#3  0x003d3e6010ab in dlsym () from /lib64/libdl.so.2
No symbol table info available.
#4  0x2aaab051fe72 in sskgds_save_text_start_end () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#5  0x2aaab160c2a0 in unw_is_signal_frame () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#6  0x2aaab160f4c3 in unw_step () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#7  0x2aaab15ffe79 in skgdsgframe () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#8  0x2aaab13bd846 in kgds_skip_frames () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#9  0x2aaab13bdb9e in kgdsdsts_extra () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#10 0x2aaab13bfa1d in kgdsdsts () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#11 0x2aaab18a26e2 in kpedbg_dmp_stack () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#12 0x2aaab18a2868 in kpeDbgCrash () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#13 0x2aaab004941d in kpucHTInsert () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#14 0x2aaab1b3fb15 in kpuexec () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#15 0x2aaab1b3dbf1 in OCIStmtExecute () from 
/product/oracle/client//lib/libclntsh.so.11.1
No symbol table info available.
#16 0x2f92339a in ora_st_execute () from 
/usr/lib/perl5/5.14.1/lib/site_perl/5.14.1/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
No symbol table info available.
#17 0x2f91456b in XS_DBD__Oracle__st_execute () from 
/usr/lib/perl5/5.14.1/lib/site_perl/5.14.1/x86_64-linux-thread-multi/auto/DBD/Oracle/

Re: Freeradius crash with two radclient

[Alan DeKok]

fulvio fabiani wrote:
> Yes I know,
> we did not yet test the latest 2.1.x GIT release and test with 2.1.12 or
> 2.1.11 give same results.
> 
> Is it mandatory?

  It's mandatory to follow instructions on this list.

  You were asked to do certain things which would let us help you.
You've ignored those instructions, and done something *else*.  That is
useless, and wasting our time.

  If you're not going to follow instructions, you will be unsubscribed
from this list.  It's the only way we've found to convince people that
they DO NEED to follow instructions.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[Fajar A. Nugraha]

On Thu, Mar 22, 2012 at 3:04 AM, fulvio fabiani
 wrote:
> Follow the server tracing output (each crash the same output):

> 2012/3/21 Alan DeKok 

>>  See doc/bugs

So you decide to run strace instead of using gdb as written in
doc/bugs? And how did you think it can be useful?

In particular, look at section "3. DEBUGGING A LIVE SERVER". It should be easy.

-- 
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[Alan Buxey]

Hi,

>Yes I know,
>we did not yet test the latest 2.1.x GIT release and test with 2.1.12 or
>2.1.11 give same results.

well, you were asked to test the 2.1.x GIT release as it has some rather
important fixes in it.  

as for the 2.1.12 - yes. mandatory as thats the latest release code to compare
against unless you DO run the 2.1.x release...which i recommend is the first 
course
of action anyway - as the bug you have hit may have already been fixed.

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[fulvio fabiani]

Yes I know,
we did not yet test the latest 2.1.x GIT release and test with 2.1.12 or
2.1.11 give same results.

Is it mandatory?



2012/3/21 Alan Buxey 

> hi,
>
> in previous emails you were asked to run 2.1.12 or the latest 2.1.x GIT
> release
> - but this output is from 2.1.11
>
> 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: Freeradius crash with two radclient

[Alan Buxey]

hi,

in previous emails you were asked to run 2.1.12 or the latest 2.1.x GIT release
- but this output is from 2.1.11

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[fulvio fabiani]

Hi all,
we did some additional test by setting multithread debug on FreeRadius and
executing freeradius process tracing on server

Follow the server tracing output (each crash the same output):



*select(11, [4 6 7 8 9 10], NULL, NULL, {0, 302488}) = 1 (in [8], left {0,
302488})*

*recvfrom(8, "\4y\0\251", 4, MSG_PEEK, {sa_family=AF_INET,
sin_port=htons(38662), sin_addr=inet_addr("192.168.88.151")}, [16]) = 4*

*getsockname(8, {sa_family=AF_INET, sin_port=htons(2648),
sin_addr=inet_addr("192.168.88.132")}, [549755813904]) = 0*

*recvfrom(8, "\4y\0\251", 4, MSG_PEEK, {sa_family=AF_INET,
sin_port=htons(38662), sin_addr=inet_addr("192.168.88.151")}, [16]) = 4*

*recvfrom(8, "\4y\0\251@\247#\33364\371I2\346Zd\305F\215A\1\0340208451346"...,
169, 0, {sa_family=AF_INET, sin_port=htons(38662),
sin_addr=inet_addr("192.168.88.151")}, [16]) = 169*

*futex(0x641998, FUTEX_WAKE_PRIVATE, 1)  = 1*

*select(11, [4 6 7 8 9 10], NULL, NULL, {0, 301738} *


Freeradius output:
FreeRADIUS Version 2.1.11, for host x86_64-unknown-linux-gnu, built on Sep
22 2011 at 16:18:07
Copyright (C) 1999-2009 The FreeRADIUS server project and contributors.
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 v2.
Starting - reading configuration files ...
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/radiusd.conf
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/proxy.conf
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/clients.conf
including files in directory
/product/freeradius-server-2.1.11/etc/raddb/modules/
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/files
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/counter
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/dynamic_clients
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/echo
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/logintime
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/always
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/sradutmp
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/mac2vlan
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/linelog
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/ippool
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/soh
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/detail.example.com
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/ntlm_auth
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/expiration
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/etc_group
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/wimax
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/chap
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/detail
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/acct_unique
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/detail.sc.de
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/expr
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/digest
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/realm
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/krb5
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/perl
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/redis
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/policy
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/detail.log
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/opendirectory
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/radutmp
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/pam
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/smbpasswd
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/checkval
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/ldap
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/preprocess
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/modules/sql_log
including configuration file
/product/freeradius-server-2.1.11/etc/raddb/mo

Re: Freeradius crash with two radclient

[Alan DeKok]

fulvio fabiani wrote:
>  Hi Alan,
> We did same test with freeRadius version 2.1.12, unfortunately same
> result: as we start second radClient, Freeradius instance crash.
> Answering previous questions, no we don't use rlm_sql, we use perl
> module, that via oracle perl driver, executes query on the database.

  See doc/bugs

  It describes how to debug problems with the server.

  This is documented.

  You might also want to try the "v2.1.x" branch from git.  It has some
fixes to the Perl module which may help.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[Alan Buxey]

Hi,

>We did same test with freeRadius version 2.1.12, unfortunately same
>result: as we start second radClient, Freeradius instance crash.
>Answering previous questions, no we don't use rlm_sql, we use perl module,
>that via oracle perl driver, executes query on the database.

cool. and now what does the actual output of 'radiusd X' say...
the next part will be, of course, read doc/bugs file and follow those words...

I believe that F5 load balancers understand RADIUS protocol and will send one
session through to the same backend...does this happen with the F5 out of the 
way?

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[fulvio fabiani]

 Hi Alan,
We did same test with freeRadius version 2.1.12, unfortunately same result:
as we start second radClient, Freeradius instance crash.
Answering previous questions, no we don't use rlm_sql, we use perl module,
that via oracle perl driver, executes query on the database.

BR,
Fulvio




2012/3/19 Alan Buxey 

> Hi,
>
> >thanks for your answer.
> >Do the 2.1.12 fix this kind of problem?
>
> did you try with 2.1.12 ? its got a lot of fixes related to this behaviour.
> there is really no need to question/query the advice given. use the latest
> version - IF there is still a problem then its important as then it might
> be a new bug.
>
> 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: Freeradius crash with two radclient

[Alan Buxey]

Hi,

>thanks for your answer.
>Do the 2.1.12 fix this kind of problem?

did you try with 2.1.12 ? its got a lot of fixes related to this behaviour.
there is really no need to question/query the advice given. use the latest
version - IF there is still a problem then its important as then it might
be a new bug.

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[Fajar A. Nugraha]

On Tue, Mar 20, 2012 at 4:47 AM, fulvio fabiani
 wrote:
> Hi Phil,
> thanks for your answer.
> Do the 2.1.12 fix this kind of problem?

2.1.11 has some known bugs, fixed in 2.1.12 in newer. It might be one
of them. If you don't want to waste anyone's time, re-run your tests
on 2.1.12

>
> We did some additional analysis, we found that with this configuration:
>   - 1 freeradius
>   - 1 radclient
>
> everythings works,
>
> but with
>  - 1 freeradius
>  - 2 radlicent
>
> the freeradius instance crash as we start the second client.
> Our application execute queries on Oracle Database, we also try to disable
> DB access and, with this configuration, the system won't crash.

How do you connect to the db? Using rlm_sql?

If yes, and you can reproduce the crash immediately just by sending
several packets, try running "radiusd -fxx -l stdout" which should run
it multi threaded and print out debugging outputs.

Also try debugging with gdb.

-- 
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash with two radclient

[fulvio fabiani]

Hi Phil,
thanks for your answer.
Do the 2.1.12 fix this kind of problem?

We did some additional analysis, we found that with this configuration:
  - 1 freeradius
  - 1 radclient

everythings works,

but with
 - 1 freeradius
 - 2 radlicent

the freeradius instance crash as we start the second client.
Our application execute queries on Oracle Database, we also try to disable
DB access and, with this configuration, the system won't crash.

Best Regards
Fulvio


2012/3/16 Phil Mayers 

> On 16/03/12 16:57, fulvio fabiani wrote:
>
>> Hi all,
>>
>> i’ve a problem with concurrent accounting requests with free radius
>> 2.1.11.
>>
>
> Upgrade to 2.1.12 and try again.
> -
> 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 crash with two radclient

[Phil Mayers]

On 16/03/12 16:57, fulvio fabiani wrote:

Hi all,

i’ve a problem with concurrent accounting requests with free radius 2.1.11.


Upgrade to 2.1.12 and try again.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Freeradius crash during EAP-TTLS authentication

[Mulindwa]

Hi Thomas,

How did manage to configure Freeradius with Huawei NAS, its a big challenge to 
me, have still failed.

 
Eric M



 From: Thomas Fagart 
To: freeradius-users@lists.freeradius.org 
Sent: Tuesday, March 6, 2012 12:19 PM
Subject: Freeradius crash during EAP-TTLS authentication
 
Hello,

Since more than a year we're doing EAP-TTLS to authenticate Wimax Users on 
Alcatel and Huawei NASes.

Last week we've migrate Motorola authentication on freeradius. (no more 
radiator :-) ).

But then we've experienced freeradius crash.

Informations :
Software : Freeradius 2.1.12
OS : Freebsd8.0p4 64bits
Users :
Huawei = 500 users -> 0,5 requests per second
Alcatel = 1500 users -> 2 requests per second
Motorola = 8000 users -> 5 requests per second


The crash usually happen when home servers (ISP radius) does not respond, then 
the radius load goes up to 50/60 requests per second and after 40/50 minutes 
the radius crash.


Logs :
Tue Mar  6 00:40:17 2012 : Info: [eap_moto] Request found, released from the 
list
Tue Mar  6 00:40:17 2012 : Info: [eap_moto] EAP/ttls
Tue Mar  6 00:40:17 2012 : Info: [eap_moto] processing type ttls
Tue Mar  6 00:40:17 2012 : Info: [ttls] Authenticate
Tue Mar  6 00:40:17 2012 : Info: [ttls] processing EAP-TLS
Tue Mar  6 00:40:17 2012 : Info: [ttls] eaptls_verify returned 7
Tue Mar  6 00:40:17 2012 : Info: [ttls] Done initial handshake
Tue Mar  6 00:40:17 2012 : Info: [ttls]     (other): before/accept 
initialization
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: before/accept 
initialization
Tue Mar  6 00:40:17 2012 : Info: [ttls] <<< TLS 1.0 Handshake [length 0053], 
ClientHello
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: SSLv3 read client hello 
A
Tue Mar  6 00:40:17 2012 : Info: [ttls] >>> TLS 1.0 Handshake [length 002a], 
ServerHello
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: SSLv3 write server 
hello A
Tue Mar  6 00:40:17 2012 : Info: [ttls] >>> TLS 1.0 Handshake [length 0b56], 
Certificate
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: SSLv3 write certificate 
A
Tue Mar  6 00:40:17 2012 : Info: [ttls] >>> TLS 1.0 Handshake [length 018d], 
ServerKeyExchange
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: SSLv3 write key 
exchange A
Tue Mar  6 00:40:17 2012 : Info: [ttls] >>> TLS 1.0 Handshake [length 0004], 
ServerHelloDone
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: SSLv3 write server done 
A
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: SSLv3 flush data
Tue Mar  6 00:40:17 2012 : Info: [ttls]     TLS_accept: Need to read more data: 
SSLv3 read client certificate A
Tue Mar  6 00:40:17 2012 : Debug: In SSL Handshake Phase
Tue Mar  6 00:40:17 2012 : Debug: In SSL Accept mode  Tbash: [65774: 2 (255)] 
tcsetattr: Interrupted system call
Killed: 9

It seems this is more related to SSL issue ?

Could you confirm this idea is correct ?

I can compile the radius in gdb to get more information if this is usefull.

Thanks

Thomas





-
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 crash during EAP-TTLS authentication

[Alan DeKok]

Thomas Fagart wrote:
> Last week we've migrate Motorola authentication on freeradius. (no more
> radiator :-) ).

  Nice.

> But then we've experienced freeradius crash.

  Not so nice.

> The crash usually happen when home servers (ISP radius) does not
> respond, then the radius load goes up to 50/60 requests per second and
> after 40/50 minutes the radius crash.

  That kind of situation is hard to test.

> It seems this is more related to SSL issue ?

  Maybe.  It's hard to know.

> Could you confirm this idea is correct ?
> 
> I can compile the radius in gdb to get more information if this is usefull.

  Yes.  See doc/bugs for complete instructions.

  Also, try compiking with debugging flags, and using valgrind.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Alan Dekok]

Doug Hardie wrote:
> I think I may have found the cause of my crashes.  One of the proxy  
> servers or NASs is occasionally sending me an incorrectly formatted  
> authentication request.

   That should NOT cause the server to crash.  Ever.

   Alan DeKok.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Doug Hardie]

I think I may have found the cause of my crashes.  One of the proxy  
servers or NASs is occasionally sending me an incorrectly formatted  
authentication request.  I have not been able to capture the entire  
packet yet but I did manage to log part of the last one just as the  
crash occurred and the part that was successfully flushed out of the  
buffers before the seg fault is definitely corrupt.  Because my  
secondary server only handles requests when the primary is down, I  
can set it to capture all the packets.  However, I am going to have  
to wait till I can upgrade its OS.  Its also our news server and  
upgrading that is always a large pain.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Alan Dekok]

Doug Hardie wrote:
> Nope.  All memory that is used is local.  Nothing is retained.  Only  
> the authorize module is used.  Nothing is dynamically allocated in  
> the module.

  Are you sure there are no buffer overruns in your module?  Are you
sure you're calling the FreeRADIUS API correctly?

  My question is because we've had a full source code scan in 1.1.6, and
a number of bugs have fixed.  The result is I am very skeptical of there
being memory-related bugs in the server.

  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: FreeRadius crash

[Doug Hardie]

On May 25, 2007, at 01:24, Alan Dekok wrote:

> Doug Hardie wrote:
>> I am completely unable to replicate this situation on my test
>> system.  I can run thousands of requests via multiple radclients
>> without any problems.  I can drive the test system to overload and
>> other than responses slow down a bit, it just works properly.
>>
>> #0  0x2830a6e8 in ?? () from /usr/local/lib/rlm_lafn.so
>> #1  0x2830b9c0 in lafn_authorize (instance=0x0, request=0x0) at
>> rlm_lafn.c:543
>
>   Umm... if you're using modules you wrote yourself, my guess would be
> that the problem lies in those modules.  You probably have access a
> pointer after it's freed, which corrupts memory.
>
>   The standard server as shipped in 1.1.6 does *not* have this  
> problem.

Nope.  All memory that is used is local.  Nothing is retained.  Only  
the authorize module is used.  Nothing is dynamically allocated in  
the module.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Doug Hardie]

On May 25, 2007, at 01:24, Alan Dekok wrote:

> Doug Hardie wrote:
>> I am completely unable to replicate this situation on my test
>> system.  I can run thousands of requests via multiple radclients
>> without any problems.  I can drive the test system to overload and
>> other than responses slow down a bit, it just works properly.
>>
>> #0  0x2830a6e8 in ?? () from /usr/local/lib/rlm_lafn.so
>> #1  0x2830b9c0 in lafn_authorize (instance=0x0, request=0x0) at
>> rlm_lafn.c:543
>
>   Umm... if you're using modules you wrote yourself, my guess would be
> that the problem lies in those modules.  You probably have access a
> pointer after it's freed, which corrupts memory.
>
>   The standard server as shipped in 1.1.6 does *not* have this  
> problem.

Should have pointed out that this module ran for over a year with  
1.1.2 and FreeBSD 5.3 without any problems.  Never once had a core dump.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Alan Dekok]

Doug Hardie wrote:
> I am completely unable to replicate this situation on my test  
> system.  I can run thousands of requests via multiple radclients  
> without any problems.  I can drive the test system to overload and  
> other than responses slow down a bit, it just works properly.
> 
> #0  0x2830a6e8 in ?? () from /usr/local/lib/rlm_lafn.so
> #1  0x2830b9c0 in lafn_authorize (instance=0x0, request=0x0) at  
> rlm_lafn.c:543

  Umm... if you're using modules you wrote yourself, my guess would be
that the problem lies in those modules.  You probably have access a
pointer after it's freed, which corrupts memory.

  The standard server as shipped in 1.1.6 does *not* have this 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

Re: FreeRadius crash

[Doug Hardie]

On May 8, 2007, at 00:49, Alan DeKok wrote:

> Doug Hardie wrote:
>> FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.
>
>   Upgrade to 1.1.6.  It has a lot of fixes that may help.
>
>   It looks like it's crashing when starting a new child thread.  That
> may be a pthread issue in the underlying libraries.

The saga continues.  Digging around through the core dumps I noticed  
that often one of my modules was active in another thread and always  
at a fprintf statement.  I wondered if perhaps FreeBSD's fprintf  
statment was not always thread safe so I removed all of them.  Not  
the problem.  Now its dying on a simple assignment statement.   
However, thats obvious when you see the arguments to the authorize  
function:  Both zeros.  I didn't think that was supposed to happen.   
None of the included modules check for that condition.  Is this whats  
causing my problem or is it the result of the thread that is not able  
to get started properly?I suspect the latter since the prior  
stack is corrupt.  I am tempted to put a check for that right at the  
beginning of the authorize function and just return if it happens.   
Good idea?

I am completely unable to replicate this situation on my test  
system.  I can run thousands of requests via multiple radclients  
without any problems.  I can drive the test system to overload and  
other than responses slow down a bit, it just works properly.

#0  0x2830a6e8 in ?? () from /usr/local/lib/rlm_lafn.so
#1  0x2830b9c0 in lafn_authorize (instance=0x0, request=0x0) at  
rlm_lafn.c:543
Previous frame inner to this frame (corrupt stack?)

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Doug Hardie]

On May 19, 2007, at 17:27, Doug Hardie wrote:

>
> One thing I just noticed.  The following is in radiusd.conf:
>
> thread pool {
>  start_servers = 5
>  max_servers = 32
>  min_spare_servers = 3
>  max_spare_servers = 10
>  max_requests_per_server = 0
> }
>
> However, ps -H shows only 3 active threads.  I would have expected
> more.  But perhaps its idle right now.  I think 8 threads is the most
> I have ever seen.  The last crash was trying to start the 8th
> thread.  Perhaps upping min_spare_servers above 8 would help.

Nope.  Just tried the following:

thread pool {
 start_servers = 5
 max_servers = 32
 min_spare_servers = 10
 max_spare_servers = 20
 max_requests_per_server = 0
}

and the number of threads after several hours is still 3.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Doug Hardie]

On May 19, 2007, at 16:34, David Wood wrote:

> Hi Doug and everyone,
>
> In message <[EMAIL PROTECTED]>, Doug  
> Hardie
> <[EMAIL PROTECTED]> writes
>>
>> On May 8, 2007, at 00:49, Alan DeKok wrote:
>>
>>> Doug Hardie wrote:
 FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.
>>>
>>>   Upgrade to 1.1.6.  It has a lot of fixes that may help.
>>>
>>>   It looks like it's crashing when starting a new child thread.   
>>> That
>>> may be a pthread issue in the underlying libraries.
>>
>> Upgraded to the latest of everything.
>
> Including the OS? FreeBSD is up to 6.2-RELEASE(-p4) now. FWIW, I  
> didn't
> find going from 6.1 to 6.2 that painful - though there's always the  
> risk
> of something going wrong.
>
>> Same problem except that it
>> only took about an hour before the first crash.
>> Any ideas how to figure out what is going on?  Or at least to find
>> the request that is in process when the crash occurs?
>
> Can I ask - especially as I'm the maintainer of the FreeBSD FreeRADIUS
> port - are you using the port or not? I've put in a lot of effort to
> tidy up the port over the last few versions, and I believe it is now a
> good quality and easily maintainable port, despite it missing one  
> or two
> features I'd like to add when I get the time.
>
> Most notably, I've done away with unnecessary or irrelevant patches  
> (in
> fact, the only patch that remains is to do with FreeBSD 4.x and will
> probably be ripped out soon).
>
>
> As an aside, I hope to create a 2.0.0-pre1 port soon - though I've  
> been
> away and very busy, and there's still a ports freeze in place with the
> ongoing work to switch FreeBSD to XOrg 7.2. I don't know whether  
> testing
> with 2.0.0-pre1 is of interest to you, but I intend to try running
> 2.0.0-pre1 on my site as soon as possible for testing purposes.
>
>
> Hopefully someone can give you some debugging advice, and we can  
> figure
> out whether this is a FreeRADIUS or FreeBSD problem. I doubt that the
> port itself is to blame, as apart from the aforementioned source patch
> (which just adds a single #include line to one file), and a some
> patching to the build system to change the install location of raddb,
> the port simply wraps the contents of the tarball from the FreeRADIUS
> project.

I am using the port as of about a week ago.

One thing I just noticed.  The following is in radiusd.conf:

thread pool {
 start_servers = 5
 max_servers = 32
 min_spare_servers = 3
 max_spare_servers = 10
 max_requests_per_server = 0
}

However, ps -H shows only 3 active threads.  I would have expected  
more.  But perhaps its idle right now.  I think 8 threads is the most  
I have ever seen.  The last crash was trying to start the 8th  
thread.  Perhaps upping min_spare_servers above 8 would help.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[David Wood]

Hi Doug and everyone,

In message <[EMAIL PROTECTED]>, Doug Hardie 
<[EMAIL PROTECTED]> writes
>
>On May 8, 2007, at 00:49, Alan DeKok wrote:
>
>> Doug Hardie wrote:
>>> FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.
>>
>>   Upgrade to 1.1.6.  It has a lot of fixes that may help.
>>
>>   It looks like it's crashing when starting a new child thread.  That
>> may be a pthread issue in the underlying libraries.
>
>Upgraded to the latest of everything.

Including the OS? FreeBSD is up to 6.2-RELEASE(-p4) now. FWIW, I didn't 
find going from 6.1 to 6.2 that painful - though there's always the risk 
of something going wrong.

>Same problem except that it
>only took about an hour before the first crash.
>Any ideas how to figure out what is going on?  Or at least to find
>the request that is in process when the crash occurs?

Can I ask - especially as I'm the maintainer of the FreeBSD FreeRADIUS 
port - are you using the port or not? I've put in a lot of effort to 
tidy up the port over the last few versions, and I believe it is now a 
good quality and easily maintainable port, despite it missing one or two 
features I'd like to add when I get the time.

Most notably, I've done away with unnecessary or irrelevant patches (in 
fact, the only patch that remains is to do with FreeBSD 4.x and will 
probably be ripped out soon).


As an aside, I hope to create a 2.0.0-pre1 port soon - though I've been 
away and very busy, and there's still a ports freeze in place with the 
ongoing work to switch FreeBSD to XOrg 7.2. I don't know whether testing 
with 2.0.0-pre1 is of interest to you, but I intend to try running 
2.0.0-pre1 on my site as soon as possible for testing purposes.


Hopefully someone can give you some debugging advice, and we can figure 
out whether this is a FreeRADIUS or FreeBSD problem. I doubt that the 
port itself is to blame, as apart from the aforementioned source patch 
(which just adds a single #include line to one file), and a some 
patching to the build system to change the install location of raddb, 
the port simply wraps the contents of the tarball from the FreeRADIUS 
project.



Best wishes - hope you can get this one sorted out,





David
-- 
David Wood
[EMAIL PROTECTED]
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Doug Hardie]

On May 8, 2007, at 00:49, Alan DeKok wrote:

> Doug Hardie wrote:
>> FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.
>
>   Upgrade to 1.1.6.  It has a lot of fixes that may help.
>
>   It looks like it's crashing when starting a new child thread.  That
> may be a pthread issue in the underlying libraries.

Upgraded to the latest of everything.  Same problem except that it  
only took about an hour before the first crash.
Any ideas how to figure out what is going on?  Or at least to find  
the request that is in process when the crash occurs?
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Doug Hardie]

On May 8, 2007, at 00:49, Alan DeKok wrote:

> Doug Hardie wrote:
>> FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.
>
>   Upgrade to 1.1.6.  It has a lot of fixes that may help.
>
>   It looks like it's crashing when starting a new child thread.  That
> may be a pthread issue in the underlying libraries.

Well, both the primary and backup machines crashed again today at the  
same time.  Its not the FreeRadius changes that will fix it.  I will  
be upgrading the OS in a few days.  There appear to be some changes  
to pthread library.  Will watch to see what happens after that.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Doug Hardie]

On May 8, 2007, at 00:49, Alan DeKok wrote:

> Doug Hardie wrote:
>> FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.
>
>   Upgrade to 1.1.6.  It has a lot of fixes that may help.
>
>   It looks like it's crashing when starting a new child thread.  That
> may be a pthread issue in the underlying libraries.

I upgraded the secondary server to 1.1.6.  We will see what happens  
the next time the primary crashes.  It will probably be about another  
week before then as they crashed early yesterday.  I expect though  
that the problem is in libpthread.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRadius crash

[Alan DeKok]

Doug Hardie wrote:
> FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.

  Upgrade to 1.1.6.  It has a lot of fixes that may help.

  It looks like it's crashing when starting a new child thread.  That
may be a pthread issue in the underlying libraries.

  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: FreeRadius crash

[A . L . M . Buxey]

Hi,

> FreeRadius 1.1.2 on FreeBSD 6.1 using libpthread.  I have tried using  

upgrade to 1.1.6

alan
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: FreeRADIUS crash on Solaris 10 after start

[Alan DeKok]

Peter Micunek wrote:
> Alan,
> 
> You are right. It is 64-bit machine but
> 
> # file radiusd
> radiusd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required,
> dynamically linked, stripped

The data structures are marked as being 32-bit.  The compiler
should generate the appropriate instructions to perform 32-bit accesses
without causing bus errors due to alignment issues.

  I'm not sure what to suggest.  Maybe a Solaris / Sparc expert knows more.

  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: FreeRADIUS crash on Solaris 10 after start

[Peter Micunek]

Alan,

You are right. It is 64-bit machine but

# file radiusd
radiusd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required,
dynamically linked, stripped

regards
Peter Micunek


On 4/30/07, Alan DeKok <[EMAIL PROTECTED]> wrote:


Peter Micunek wrote:
> and  when I want to start FreeRADIUS it crash:
...
> program terminated by signal BUS (invalid address alignment)
> Current function is lrad_isaac (optimized)
> 37 rngstep( a<<13, a, b, mm, m, m2, r, x);

  Let me guess... it's a 64-bit machine?

> I have same problem with FR 1.1.6. Can you help me fix this problem?

  This is the first I've seen the problem.  Looking at the code, it's
all explicitly 32-bit, so the compiler should produce the correct code
to access 32-bit data that's not aligned on a 64-bit boundary.

  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: FreeRADIUS crash on Solaris 10 after start

[Alan DeKok]

Peter Micunek wrote:
> and  when I want to start FreeRADIUS it crash:
...
> program terminated by signal BUS (invalid address alignment)
> Current function is lrad_isaac (optimized)
> 37 rngstep( a<<13, a, b, mm, m, m2, r, x);

  Let me guess... it's a 64-bit machine?

> I have same problem with FR 1.1.6. Can you help me fix this problem?

  This is the first I've seen the problem.  Looking at the code, it's
all explicitly 32-bit, so the compiler should produce the correct code
to access 32-bit data that's not aligned on a 64-bit boundary.

  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