Freeradius 3.0.10 sigsegv
Hi, we are experiencing a lot of segmentation fault in freeradius 3.0.10. It seems to be something in proxy because we have other freeradius server running without problem. Those one (other two servers) with proxy enabled crash with the same backtrace. Hosts configuration and backtrace follows. Any idea? Thanks in advance Luca Freeradius version is: freeradius: FreeRADIUS Version 3.0.10, for host x86_64-pc-linux-gnu, built on Dec 15 2015 at 10:46:38 The proxy.conf is: proxy server { default_fallback = yes } home_server radius.radius.net { type = auth+acct ipaddr = xxxx port = 1812 secret = "password" status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server radius2.radius.net { type = auth+acct ipaddr = xxx port = 1812 secret = "password" status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server_pool EDUROAM-IT { type = fail-over home_server = radius.radius.net home_server = radius2.radius.net } realm unict.it { # nostrip } realm NULL { nostrip } realm LOCAL { nostrip } realm DEFAULT { pool = EDUROAM-IT nostrip type = radius } eduroam virtual server is: server eduroam { authorize { auth_log suffix if ((control:Proxy-To-Realm == "DEFAULT") && (User-Name =~ /.*@.*.unict.it$/)) { update control { Proxy-To-Realm := NULL } } eap } authenticate { Auth-Type EAP { eap } } preacct { # detail suffix if ((control:Proxy-To-Realm == "DEFAULT") && (User-Name =~ /.*@.*.unict.it$/)) { update control { Proxy-To-Realm := NULL } } } accounting { sql } post-auth { reply_log Post-Auth-Type REJECT { # reply_log } } pre-proxy { attr_filter.pre-proxy pre_proxy_log } post-proxy { post_proxy_log attr_filter.post-proxy } } Here is the backtrace (the same for both of servers): #0 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xa531c0, req_list=0xa53470, check=check@entry=0xa54ce0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 #1 0x00007ffff7bb95d7 in cond_cmp_values (request=0xa531c0, lhs_type=<optimized out>, lhs=<optimized out>, lhs_len=<optimized out>, rhs_type=PW_TYPE_STRING, rhs=0x7fffffffd2d0, rhs_len=8, c=<optimized out>, c=<optimized out>) at src/main/evaluate.c:315 #2 0x00007ffff7bb992a in cond_normalise_and_cmp (request=0x0, c=0x8bd4a0, lhs_type=PW_TYPE_INVALID, lhs_enumv=0x7ffff7bd4230, lhs_enumv@entry=0x0, lhs=0x0, lhs_len=1, lhs_len@entry=0) at src/main/evaluate.c:544 #3 0x00007ffff7bba3ac in radius_evaluate_map (request=request@entry=0xa531c0, modreturn=modreturn@entry=10, depth=depth@entry=0, c=c@entry=0x8bd4a0) at src/main/evaluate.c:612 #4 0x00007ffff7bba4a0 in radius_evaluate_cond (request=0xa531c0, modreturn=10, depth=0, c=0x8bd4a0) at src/main/evaluate.c:708 #5 0x0000000000425228 in modcall_recurse (request=0xa531c0, component=22, depth=22, entry=0x7fffffffdec8, do_next_sibling=false) at src/main/modcall.c:479 #6 0x0000000000424fa9 in modcall_child (request=<optimized out>, component=<optimized out>, depth=<optimized out>, entry=0x7fffffffdeb0, c=<optimized out>, result=0x7fffffffd724, do_next_sibling=true) at src/main/modcall.c:408 #7 0x00000000004252c4 in modcall_recurse (request=0xa531c0, component=22, depth=22, entry=0x7fffffffdeb0, do_next_sibling=false) at src/main/modcall.c:785 #8 0x0000000000424fa9 in modcall_child (request=<optimized out>, component=<optimized out>, depth=<optimized out>, entry=0x7fffffffde98, c=<optimized out>, result=0x7fffffffd9c4, do_next_sibling=true) at src/main/modcall.c:408 #9 0x00000000004252c4 in modcall_recurse (request=0xa531c0, component=22, depth=22, entry=0x7fffffffde98, do_next_sibling=false) at src/main/modcall.c:785 #10 0x0000000000424fa9 in modcall_child (request=<optimized out>, component=<optimized out>, depth=<optimized out>, entry=0x7fffffffde80, c=<optimized out>, result=0x7fffffffdc64, do_next_sibling=true) at src/main/modcall.c:408 #11 0x00000000004252c4 in modcall_recurse (request=0xa531c0, component=22, component@entry=MOD_AUTHORIZE, depth=22, depth@entry=0, entry=0x7fffffffde80, do_next_sibling=false, do_next_sibling@entry=true) at src/main/modcall.c:785 #12 0x0000000000426416 in modcall (component=component@entry=MOD_AUTHORIZE, c=c@entry=0x9c22b0, request=request@entry=0xa531c0) at src/main/modcall.c:1130 #13 0x00000000004210dd in indexed_modcall (comp=MOD_AUTHORIZE, idx=<optimized out>, request=0xa531c0) at src/main/modules.c:1009 #14 0x0000000000410911 in rad_authenticate (request=0xa531c0) at src/main/auth.c:490 #15 0x000000000043409a in request_running (request=0xa531c0, action=<optimized out>) at src/main/process.c:1527 #16 0x0000000000430126 in request_queue_or_run (request=request@entry=0xa531c0, process=process@entry=0x433ee0 <request_running>) at src/main/process.c:1015 #17 0x0000000000431815 in request_receive (ctx=ctx@entry=0xa52a40, listener=listener@entry=0x9ef500, packet=0xa52aa0, client=client@entry=0x972b20, fun=fun@entry=0x4104b0 <rad_authenticate>) at src/main/process.c:1782 #18 0x000000000041bd5e in auth_socket_recv (listener=0x9ef500) at src/main/listen.c:1568 ---Type <return> to continue, or q <return> to quit--- #19 0x000000000042e72e in event_socket_handler (xel=<optimized out>, fd=<optimized out>, ctx=<optimized out>) at src/main/process.c:4556 #20 0x00007ffff7994025 in fr_event_loop (el=0x8e4640) at src/lib/event.c:641 #21 0x0000000000435531 in radius_event_process () at src/main/process.c:5621 #22 0x000000000040f7cc in main (argc=<optimized out>, argv=0x7fffffffecc8) at src/main/radiusd.c:579
On Jan 5, 2016, at 2:43 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
we are experiencing a lot of segmentation fault in freeradius 3.0.10. It seems to be something in proxy because we have other freeradius server running without problem. Those one (other two servers) with proxy enabled crash with the same backtrace.
Hosts configuration and backtrace follows.
Any idea? ... #0 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xa531c0, req_list=0xa53470, check=check@entry=0xa54ce0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536
Can you print the values of the variables there? (gdb) p auth_item (gdb) p auth_item->da (gdb) p from I can't see anything on line 536 which would cause it to crash. All of the pointers are checked before they are dereferenced. Alan DeKok.
Hi Alan, I've got these info from gdb: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xb10ca0, req_list=0xb10f50, check=check@entry=0xb129b0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 536 if ((auth_item->da == from) || (!from)) { (gdb) p auth_item $1 = (VALUE_PAIR *) 0x2e696d696c6f7040 (gdb) p auth_item->da Cannot access memory at address 0x2e696d696c6f7040 (gdb) p from $2 = (const DICT_ATTR *) 0x68ff50 (gdb) Luca Il 05/01/16 15:01, Alan DeKok ha scritto: Il 05/01/16 15:01, Alan DeKok ha scritto:
On Jan 5, 2016, at 2:43 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
we are experiencing a lot of segmentation fault in freeradius 3.0.10. It seems to be something in proxy because we have other freeradius server running without problem. Those one (other two servers) with proxy enabled crash with the same backtrace.
Hosts configuration and backtrace follows.
Any idea? ... #0 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xa531c0, req_list=0xa53470, check=check@entry=0xa54ce0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536
Can you print the values of the variables there?
(gdb) p auth_item (gdb) p auth_item->da (gdb) p from
I can't see anything on line 536 which would cause it to crash. All of the pointers are checked before they are dereferenced.
Alan DeKok.
On Jan 5, 2016, at 9:08 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
Hi Alan, I've got these info from gdb:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xb10ca0, req_list=0xb10f50, check=check@entry=0xb129b0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 536 if ((auth_item->da == from) || (!from)) { (gdb) p auth_item $1 = (VALUE_PAIR *) 0x2e696d696c6f7040 (gdb) p auth_item->da Cannot access memory at address 0x2e696d696c6f7040
Hmm... auth_item is corrupt. That should only happen if there is massive memory corruption. And that code hasn't changed for a long time. So other people *should* have run into it. If you can reproduce it with a slightly modified default configuration, that would help. I could then reproduce it locally and debug it. Otherwise, it's hard for me to remotely debug a problem which only occurs on your machine. Alan DeKok.
Alan, I've just disabled virtual servers and this part of configuration: ## if (EAP-Message) { ## if ( Called-Station-ID =~ /.*:eduroam$/ ) { ## ## if ( User-Name =~ /.*@.*.unict.it$/ ) { ## update control { ## User-Name := "%{1}" ## } ## } ## ## if ( SQL-Group == studente ) { ## reject ## update reply { ## Reply-Message = "Eduroam access for students allowed only if you are outside UniCT campus" ## } ## } ## ## update control { ## Virtual-Server := "wluct" ## } ## } ## if ( Called-Station-ID =~ /.*:WLUCT$/ ) { ## # if ( Calling-Station-ID =~ /.*-01$/ ) { ## if ( SQL-Group != wireless ) { ## reject ## } ## update reply { ## Reply-Message = "WLUCT" ## } ## ## update control { ## Virtual-Server := "wluct" ## } ## } ## if ( Called-Station-ID =~ /.*:WLUCTSTUD$/ ) { ## # if ( Calling-Station-ID =~ /.*-01$/ ) { ## if ( SQL-Group != studente ) { ## reject ## } ## update reply { ## Reply-Message = "WLUCTSTUD" ## } ## ## update control { ## Virtual-Server := "wluctstud" ## } ## } ## ## } I've left proxy configuration, inner-tunnel and proxied virtual server. Now the configuration is pretty similar to default one. I'll check if it will crash again and keep you informed. Luca Il 05/01/16 15:12, Alan DeKok ha scritto:
On Jan 5, 2016, at 9:08 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
Hi Alan, I've got these info from gdb:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xb10ca0, req_list=0xb10f50, check=check@entry=0xb129b0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 536 if ((auth_item->da == from) || (!from)) { (gdb) p auth_item $1 = (VALUE_PAIR *) 0x2e696d696c6f7040 (gdb) p auth_item->da Cannot access memory at address 0x2e696d696c6f7040
Hmm... auth_item is corrupt. That should only happen if there is massive memory corruption. And that code hasn't changed for a long time. So other people *should* have run into it.
If you can reproduce it with a slightly modified default configuration, that would help. I could then reproduce it locally and debug it. Otherwise, it's hard for me to remotely debug a problem which only occurs on your machine.
Alan DeKok.
I forgot to say that the if statement was in authorize section of default site. Luca Il 05/01/16 17:26, Luca Palazzo ha scritto:
Alan, I've just disabled virtual servers and this part of configuration:
## if (EAP-Message) { ## if ( Called-Station-ID =~ /.*:eduroam$/ ) { ## ## if ( User-Name =~ /.*@.*.unict.it$/ ) { ## update control { ## User-Name := "%{1}" ## } ## } ## ## if ( SQL-Group == studente ) { ## reject ## update reply { ## Reply-Message = "Eduroam access for students allowed only if you are outside UniCT campus" ## } ## } ## ## update control { ## Virtual-Server := "wluct" ## } ## } ## if ( Called-Station-ID =~ /.*:WLUCT$/ ) { ## # if ( Calling-Station-ID =~ /.*-01$/ ) { ## if ( SQL-Group != wireless ) { ## reject ## } ## update reply { ## Reply-Message = "WLUCT" ## } ## ## update control { ## Virtual-Server := "wluct" ## } ## } ## if ( Called-Station-ID =~ /.*:WLUCTSTUD$/ ) { ## # if ( Calling-Station-ID =~ /.*-01$/ ) { ## if ( SQL-Group != studente ) { ## reject ## } ## update reply { ## Reply-Message = "WLUCTSTUD" ## } ## ## update control { ## Virtual-Server := "wluctstud" ## } ## } ## ## }
I've left proxy configuration, inner-tunnel and proxied virtual server.
Now the configuration is pretty similar to default one. I'll check if it will crash again and keep you informed.
Luca
Il 05/01/16 15:12, Alan DeKok ha scritto:
On Jan 5, 2016, at 9:08 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
Hi Alan, I've got these info from gdb:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc77a0 in paircompare (request=request@entry=0xb10ca0, req_list=0xb10f50, check=check@entry=0xb129b0, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 536 if ((auth_item->da == from) || (!from)) { (gdb) p auth_item $1 = (VALUE_PAIR *) 0x2e696d696c6f7040 (gdb) p auth_item->da Cannot access memory at address 0x2e696d696c6f7040
Hmm... auth_item is corrupt. That should only happen if there is massive memory corruption. And that code hasn't changed for a long time. So other people *should* have run into it.
If you can reproduce it with a slightly modified default configuration, that would help. I could then reproduce it locally and debug it. Otherwise, it's hard for me to remotely debug a problem which only occurs on your machine.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan, this part of configration in default's authorize section make freeradis sigsegv: if (EAP-Message) { if ( Called-Station-ID =~ /.*:eduroam$/ ) { if ( User-Name =~ /.*@.*.unict.it$/ ) { update control { User-Name := "%{1}" } } if ( SQL-Group == studente ) { reject update reply { Reply-Message = "Eduroam access for students allowed only if you are outside UniCT campus" } } } if ( Called-Station-ID =~ /.*:WLUCT$/ ) { if ( SQL-Group != wireless ) { reject } update reply { Reply-Message = "WLUCT" } } if ( Called-Station-ID =~ /.*:WLUCTSTUD$/ ) { if ( SQL-Group != studente ) { reject } update reply { Reply-Message = "WLUCTSTUD" } } } The remaining config is nearly the default one. Luca
Hi,
if ( User-Name =~ /.*@.*.unict.it$/ ) { update control { User-Name := "%{1}" } }
urgh. you are writing User-Name in the control plane to the component before the realm.....but Stripped-User-Name will do that for you without any strange things or impacting EAP client behaviour. alan
I've just commented it but i got same sigsegv: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc77a0 in paircompare (request=request@entry=0x950d60, req_list=0x951010, check=check@entry=0x952b00, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 536 if ((auth_item->da == from) || (!from)) { (gdb) p from $1 = (const DICT_ATTR *) 0x68ff50 (gdb) p auth_item $2 = (VALUE_PAIR *) 0x2e696d696c6f7040 (gdb) p auth_item->da Cannot access memory at address 0x2e696d696c6f7040 (gdb) Only this part remains: if (EAP-Message) { if ( Called-Station-ID =~ /.*:eduroam$/ ) if ( SQL-Group == studente ) { reject update reply { Reply-Message = "Eduroam access for students allowed only if you are outside UniCT campus" } } } if ( Called-Station-ID =~ /.*:WLUCT$/ ) { if ( SQL-Group != wireless ) { reject } update reply { Reply-Message = "WLUCT" } } if ( Called-Station-ID =~ /.*:WLUCTSTUD$/ ) { if ( SQL-Group != studente ) { reject } update reply { Reply-Message = "WLUCTSTUD" } } } Luca Il 06/01/16 22:20, A.L.M.Buxey@lboro.ac.uk ha scritto:
Hi,
if ( User-Name =~ /.*@.*.unict.it$/ ) { update control { User-Name := "%{1}" } }
urgh. you are writing User-Name in the control plane to the component before the realm.....but Stripped-User-Name will do that for you without any strange things or impacting EAP client behaviour.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jan 6, 2016, at 4:46 PM, Luca Palazzo <luca.palazzo@unict.it> wrote:
I've just commented it but i got same sigsegv:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc77a0 in paircompare (request=request@entry=0x950d60, req_list=0x951010, check=check@entry=0x952b00, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 536 if ((auth_item->da == from) || (!from)) { (gdb) p from $1 = (const DICT_ATTR *) 0x68ff50 (gdb) p auth_item $2 = (VALUE_PAIR *) 0x2e696d696c6f7040 (gdb) p auth_item->da Cannot access memory at address 0x2e696d696c6f7040
That's a garbage value. The server is accessing an attribute which was deleted.
(gdb)
Only this part remains:
if (EAP-Message) { if ( Called-Station-ID =~ /.*:eduroam$/ )
if ( SQL-Group == studente ) { reject update reply { Reply-Message = "Eduroam access for students allowed only if you are outside UniCT campus" }
The "update reply" will never get used. As soon as the server sees the "reject", the packets will be rejected. So swap the order or "reject" and "update reply". I don't think it will help, though. Ad what packet makes it SEGV? You have the code checking for multiple things. Does it SEGV for *all* of them? Or just one? If it's just one, can you delete the *other* checks and still have it SEGV? It would help a LOT to have a simple configuration which I can use here. Right now, your configuration depends on local SQL-Groups, and other things (EAP config, SQL server), which I don't have access to. Alan DeKok.
Alan, I tried a lot of things in these days. The crash has something to do with the sql-group. No using it, it does not crash. It seem to crash when SQL-Group attribute is null, when a user is not found in usergroup table. Can you look deeper in it? BTW: I tried to do the same filter using huntgroup, but I must have missed something, because it does not work. My huntgorup is this: eduroam Called-Station-Id =~ ".*:eduroam$" eduroam Airespace-Wlan-Id == 3 SQL-Group == wireless So no other people than those one in wireless group should be able to use eduroam. But this does not work Luca Il 06/01/16 22:53, Alan DeKok ha scritto:
On Jan 6, 2016, at 4:46 PM, Luca Palazzo <luca.palazzo@unict.it> wrote:
I've just commented it but i got same sigsegv:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc77a0 in paircompare (request=request@entry=0x950d60, req_list=0x951010, check=check@entry=0x952b00, rep_list=rep_list@entry=0x0) at src/main/pair.c:536 536 if ((auth_item->da == from) || (!from)) { (gdb) p from $1 = (const DICT_ATTR *) 0x68ff50 (gdb) p auth_item $2 = (VALUE_PAIR *) 0x2e696d696c6f7040 (gdb) p auth_item->da Cannot access memory at address 0x2e696d696c6f7040
That's a garbage value. The server is accessing an attribute which was deleted.
(gdb)
Only this part remains:
if (EAP-Message) { if ( Called-Station-ID =~ /.*:eduroam$/ )
if ( SQL-Group == studente ) { reject update reply { Reply-Message = "Eduroam access for students allowed only if you are outside UniCT campus" }
The "update reply" will never get used. As soon as the server sees the "reject", the packets will be rejected.
So swap the order or "reject" and "update reply". I don't think it will help, though.
Ad what packet makes it SEGV? You have the code checking for multiple things. Does it SEGV for *all* of them? Or just one? If it's just one, can you delete the *other* checks and still have it SEGV?
It would help a LOT to have a simple configuration which I can use here. Right now, your configuration depends on local SQL-Groups, and other things (EAP config, SQL server), which I don't have access to.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jan 12, 2016, at 11:29 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
I tried a lot of things in these days. The crash has something to do with the sql-group. No using it, it does not crash.
That's weird.
It seem to crash when SQL-Group attribute is null, when a user is not found in usergroup table. Can you look deeper in it?
I'm not sure how. I can't reproduce it here.
BTW: I tried to do the same filter using huntgroup, but I must have missed something, because it does not work.
Hmm...
My huntgorup is this:
eduroam Called-Station-Id =~ ".*:eduroam$" eduroam Airespace-Wlan-Id == 3 SQL-Group == wireless
So no other people than those one in wireless group should be able to use eduroam. But this does not work
That's not what the hunt group checks say. They just define the hunt group. You *also* need to say "reject if not in hunt group". Alan DeKok.
On Jan 13, 2016, at 2:53 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 12, 2016, at 11:29 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
I tried a lot of things in these days. The crash has something to do with the sql-group. No using it, it does not crash.
That's weird.
It seem to crash when SQL-Group attribute is null, when a user is not found in usergroup table. Can you look deeper in it?
Please write a test case, there are many examples for SQL. https://github.com/FreeRADIUS/freeradius-server/tree/v3.1.x/src/tests/module... -Arran
Alan, I finally isolated the problem. If a user is not in any group, so sql-group is null, FR will crash in some time, not immediately. I solved adding a UNION SELECT 'NOGROUP' As GroupName FROM usergroup' to groupcheck query. Anyway, it would be better correcting it in the code, it may cause some other kind of problem. Thanks Luca Il 13/01/16 20:53, Alan DeKok ha scritto:
On Jan 12, 2016, at 11:29 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
I tried a lot of things in these days. The crash has something to do with the sql-group. No using it, it does not crash.
That's weird.
It seem to crash when SQL-Group attribute is null, when a user is not found in usergroup table. Can you look deeper in it?
I'm not sure how. I can't reproduce it here.
BTW: I tried to do the same filter using huntgroup, but I must have missed something, because it does not work.
Hmm...
My huntgorup is this:
eduroam Called-Station-Id =~ ".*:eduroam$" eduroam Airespace-Wlan-Id == 3 SQL-Group == wireless
So no other people than those one in wireless group should be able to use eduroam. But this does not work
That's not what the hunt group checks say. They just define the hunt group. You *also* need to say "reject if not in hunt group".
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jan 17, 2016, at 5:18 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
Alan, I finally isolated the problem. If a user is not in any group, so sql-group is null, FR will crash in some time, not immediately.
Then it's some kind of emory corruption. Which is much harder to track down.
I solved adding a UNION SELECT 'NOGROUP' As GroupName FROM usergroup' to groupcheck query. Anyway, it would be better correcting it in the code, it may cause some other kind of problem.
If I can reproduce it, sure. Otherwise, it's difficult to fix a bug which is sporadic, and unreproducible. Alan DeKok.
Il 17/01/16 21:11, Alan DeKok ha scritto:
On Jan 17, 2016, at 5:18 AM, Luca Palazzo <luca.palazzo@unict.it> wrote:
Alan, I finally isolated the problem. If a user is not in any group, so sql-group is null, FR will crash in some time, not immediately.
Then it's some kind of emory corruption. Which is much harder to track down.
I solved adding a UNION SELECT 'NOGROUP' As GroupName FROM usergroup' to groupcheck query. Anyway, it would be better correcting it in the code, it may cause some other kind of problem.
If I can reproduce it, sure. Otherwise, it's difficult to fix a bug which is sporadic, and unreproducible. It's not so sporadic. It happens at most after some tenth of null result query. It could be fine if you succeed in solving it. Otherwise, we all know now the workaround.
Luca
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Luca Palazzo