I've worked around some of the compile time issues that I'm having and now I have something that is a bit more of a problem. I've configured the server with --enable-developer and I'm running the server with gdb (this happens without gdb too) and this is part of what I see: ... rlm_pap: User authenticated succesfully modcall[authenticate]: module "pap" returns ok for request 0 modcall: leaving group PAP (returns ok) for request 0 Sending Access-Accept of id 41 to 10.15.32.71 port 1645 Service-Type = NAS-Prompt-User Login-Service = Telnet Login-TCP-Port = Telnet Finished request 0 Going to the next request --- Walking the entire request list --- Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () (gdb) Am I wrong in thinking, that in a normal case I should see some type of backtrace? The debug message, walking..., is from radiusd.c at line 737. Here is the code /* * Loop through the request lists once per * second, to clean up old requests. */ if (last_cleaned_lists != time_now) { last_cleaned_lists = time_now; DEBUG2("--- Walking the entire request list ---"); sleep_time = SLEEP_FOREVER; for (listener = mainconfig.listen; listener != NULL; listener = listener->next) { int next; next = listener->update(listener, time_now); if (next < sleep_time) { sleep_time = next; } } } Maybe listener is never NULL? -jason
Jason Ornstein <jason.ornstein@sybase.com> wrote:
I've worked around some of the compile time issues that I'm having and now I have something that is a bit more of a problem. I've configured the server with --enable-developer and I'm running the server with gdb (this happens without gdb too) and this is part of what I see: ...
I'm seriously hacking much of the server core, so it's not overly tested.
Am I wrong in thinking, that in a normal case I should see some type of backtrace?
You should see a backtrace.
Maybe listener is never NULL?
It works in my sandbox, not that it says much... I'd suggest using: fprintf(stderr, "%s[%d]\n", __FILE__, __LINE__); in various places, down the call chain, until you don't see the messages. The point right before that is where it's dying. :) Also, if you're doing a "cvs update", you might want to "make clean;make". I've discovered that the dependencies in the Makefile aren't correct, and doing a "make" sometimes doesn't re-build things it should. Alan DeKok.
* Alan DeKok <aland@ox.org> [2005-05-27 18:08:09 -0400]:
You should see a backtrace.
Bummer.
I'd suggest using: fprintf(stderr, "%s[%d]\n", __FILE__, __LINE__); in various places, down the call chain, until you don't see the messages. The point right before that is where it's dying. :)
I did that in radiusd.c and I have one right before and after this line next = listener->update(listener, time_now); in radiusd.c and it looks like the 4th time through the for loop is when I get the segfault. I I print out the value of next right before and after this assignment I see it going from 0 to 1 to 65536 and then it dumps core. In gdb I see this (gdb) print time_now $1 = 1117235657 (gdb) print next $2 = {<text variable, no debug info>} 0xfef3a088 <next> I'm not sure how I would debug futher the listener->update(listener, time_now) statement. I'll have to read more code for that, but I'm not sure where to look for that just yet. Have a great weekend. -jason
Jason Ornstein <jason.ornstein@sybase.com> wrote:
next = listener->update(listener, time_now);
in radiusd.c and it looks like the 4th time through the for loop is when I get the segfault.
Weird. Try printing stuff in the update function in listen.c Or, 'cvs update;make clean;make'. That might help. Alan DeKok.
* Alan DeKok <aland@ox.org> [2005-05-27 19:35:52 -0400]:
Weird. Try printing stuff in the update function in listen.c
Or, 'cvs update;make clean;make'. That might help.
I just did a fresh checkout and I had to rearrange the #includes in listen.c to get it to compile. I had to move #ifdef HAVE_NET_IF_H #include <net/if.h> #endif from above this section to below it #include <sys/resource.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netdb.h> (moved from line 37 to line 43) If I didn't do that, I get these errors: In file included from listen.c:38: /usr/include/net/if.h:232: error: field `ifa_addr' has incomplete type /usr/include/net/if.h:234: error: field `ifu_broadaddr' has incomplete type /usr/include/net/if.h:235: error: field `ifu_dstaddr' has incomplete type /usr/include/net/if.h:267: error: field `lnr_addr' has incomplete type /usr/include/net/if.h:342: error: field `lifru_addr' has incomplete type /usr/include/net/if.h:343: error: field `lifru_dstaddr' has incomplete type /usr/include/net/if.h:344: error: field `lifru_broadaddr' has incomplete type /usr/include/net/if.h:345: error: field `lifru_token' has incomplete type /usr/include/net/if.h:346: error: field `lifru_subnet' has incomplete type /usr/include/net/if.h:385: error: field `sa_addr' has incomplete type /usr/include/net/if.h:395: error: field `slr_src' has incomplete type /usr/include/net/if.h:396: error: field `slr_grp' has incomplete type /usr/include/net/if.h:415: error: field `ifru_addr' has incomplete type /usr/include/net/if.h:416: error: field `ifru_dstaddr' has incomplete type /usr/include/net/if.h:418: error: field `ifru_broadaddr' has incomplete type /usr/include/net/if.h:639: error: field `ifta_saddr' has incomplete type /usr/include/net/if.h:640: error: field `ifta_daddr' has incomplete type -jason
* Alan DeKok <aland@ox.org> [2005-05-31 14:58:17 -0400]:
Ok, I've fixed that in CVS. Does the resulting executable work?
I don't know as the make install fails. I forgot that I have to take out rlm_eap and rlm_otp from src/modules/stable so that make install works. If I don't do that, I get errors like ld: fatal: library -lrlm_eap_tls: not found -jason
Jason Ornstein <jason.ornstein@sybase.com> wrote:
I don't know as the make install fails. I forgot that I have to take out rlm_eap and rlm_otp from src/modules/stable so that make install works. If I don't do that, I get errors like
ld: fatal: library -lrlm_eap_tls: not found
Yeah, that's annoying. It's in the process of being fixed. You can work around it by doing: $ make clean;make RLM_EAP_LINK_MODE=-static And it shuld build & install. Alan DeKok.
* Alan DeKok <aland@ox.org> [2005-05-31 14:58:17 -0400]:
Ok, I've fixed that in CVS. Does the resulting executable work?
[this is kinda long...but it kinda points to where the problem might be] Not at the moment. [rc.radius start with ARGS set to -sfxx] Module: Instantiated radutmp (radutmp) Initializing the thread pool... Listening on authentication address * port 1812 Listening on accounting address * port 1813 Segmentation Fault - core dumped radiusd That's a step backards from Friday. I'm having the same issues as last week when the backtrace wasn't there. After I start gdb it reads in all the symbols and then when I look at the backtrace I see this: (gdb) bt #0 0x00000000 in ?? () (gdb) bt full #0 0x00000000 in ?? () No symbol table info available. and if I put a breakpoint on line 415 and print out the listener.... ... Initializing the thread pool... Breakpoint 1, main (argc=2, argv=0xffbffbc4) at radiusd.c:412 412 for (listener = mainconfig.listen; (gdb) next 415 listener->print(listener, buffer, sizeof(buffer)); (gdb) 416 switch (listener->type) { (gdb) 422 DEBUG("Listening on accounting address %s", buffer); (gdb) Breakpoint 2, main (argc=2, argv=0xffbffbc4) at radiusd.c:418 418 DEBUG("Listening on authentication address %s", buffer); (gdb) 430 DEBUG("Listening on detail file %s", buffer); (gdb) n Listening on authentication address * port 1812 412 for (listener = mainconfig.listen; (gdb) 415 listener->print(listener, buffer, sizeof(buffer)); (gdb) 416 switch (listener->type) { (gdb) 422 DEBUG("Listening on accounting address %s", buffer); (gdb) 430 DEBUG("Listening on detail file %s", buffer); (gdb) print buffer $9 = "* port 1813", '\0' <repeats 361 times>, "ÿ>óà", '\0' <repeats 20 times>, "¡\224H¹", '\0' <repeats 132 times>, "þç\000\000ÿ>ç´", '\0' <repeats 20 times>, "ÿ¿ôT\000\000\000\022\000\000\000\005\200\000\002\002\000\000\000\003\000\000\000\000ÿ¿íÀÿ;F|ÿ¿íÈÿ;F|ÿ¿ó¤ÿ?\fðÿ:\000\203\000\000\000\000ÿ¿ó\234\000\000\000\000ÿ;q`\000\000\000\003\000\000ÿ\000ÿ>à0\000\000\000\000ÿ>ç´ÿ>à0\201\001\001\000ÿ¿ôT\000\000\000\003ÿ¿ò\210ÿ>óào.1\000o.1\000ÿ¿î ÿ;R|ÿ¿î(ÿ"... (gdb) n Listening on accounting address * port 1813 412 for (listener = mainconfig.listen; (gdb) print mainconfig.listen $10 = (rad_listen_t *) 0x3fbc0 (gdb) s 415 listener->print(listener, buffer, sizeof(buffer)); (gdb) print sizeof(buffer) $11 = 4096 (gdb) print buffer $12 = "* port 1813", '\0' <repeats 361 times>, "ÿ>óà", '\0' <repeats 20 times>, "¡\224H¹", '\0' <repeats 132 times>, "þç\000\000ÿ>ç´", '\0' <repeats 20 times>, "ÿ¿ôT\000\000\000\022\000\000\000\005\200\000\002\002\000\000\000\003\000\000\000\000ÿ¿íÀÿ;F|ÿ¿íÈÿ;F|ÿ¿ó¤ÿ?\fðÿ:\000\203\000\000\000\000ÿ¿ó\234\000\000\000\000ÿ;q`\000\000\000\003\000\000ÿ\000ÿ>à0\000\000\000\000ÿ>ç´ÿ>à0\201\001\001\000ÿ¿ôT\000\000\000\003ÿ¿ò\210ÿ>óào.1\000o.1\000ÿ¿î ÿ;R|ÿ¿î(ÿ"... (gdb) print listener $13 = (rad_listen_t *) 0x4b5a0 (gdb) print listener->print $14 = 0 (gdb) step Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () So, two things. 1. Each time through the switch statment it looks like two case statements are being called. The real one and then the one for RAD_LISTEN_DETAIL (line 430) 2. From that last print out, you can see that, for some reason, that listener->print is pointing to zero and that just isn't good. So I looked a little closer (gdb) print *listener $18 = {next = 0x4ea20, type = RAD_LISTEN_AUTH, fd = 5, identity = 0x0, rl = 0x4b5d0, recv = 0x23b0c <auth_socket_recv>, send = 0x23920 <auth_socket_send>, update = 0x24a6c <generic_update>, print = 0x238b0 <socket_print>, data = 0x4ced8} (gdb) print *listener $20 = {next = 0x4b5a0, type = RAD_LISTEN_ACCT, fd = 6, identity = 0x0, rl = 0x4bde0, recv = 0x23c54 <acct_socket_recv>, send = 0x23a30 <acct_socket_send>, update = 0x24a6c <generic_update>, print = 0x238b0 <socket_print>, data = 0x4a2b0} (gdb) print *listener $22 = {next = 0x0, type = RAD_LISTEN_PROXY, fd = 7, identity = 0x0, rl = 0x0, recv = 0, send = 0, update = 0, print = 0, data = 0x4a2d0} On a hunch, I changed radiusd.conf not to use proxy.conf [was this] proxy_requests = yes $INCLUDE ${confdir}/proxy.conf [is now this] proxy_requests = no and I restarted radius and it started witout dumping core and it doesn't dump core when it receives a radius packet. If I look at proxy.conf and look at the non-comment lines I have this proxy server { retry_delay = 5 retry_count = 3 dead_time = 120 default_fallback = yes post_proxy_authorize = yes } realm LOCAL { type = radius authhost = LOCAL accthost = LOCAL } realm sybase.com { type = radius authhost = dub-token-1.sybase.com:1645 secret = rad1usn0w } But I can comment either or both realm statements and the server still dumps core. Does that help at all? -jason
On Tuesday 31 May 2005 19:27, Jason Ornstein wrote:
(gdb) print *listener $20 = {next = 0x4b5a0, type = RAD_LISTEN_ACCT, fd = 6, identity = 0x0, rl = 0x4bde0, recv = 0x23c54 <acct_socket_recv>, send = 0x23a30 <acct_socket_send>, update = 0x24a6c <generic_update>, print = 0x238b0 <socket_print>, data = 0x4a2b0}
(gdb) print *listener $22 = {next = 0x0, type = RAD_LISTEN_PROXY, fd = 7, identity = 0x0, rl = 0x0, recv = 0, send = 0, update = 0, print = 0, data = 0x4a2d0}
The proxy listener has several pointers that are never set, as shown by your gdb print above. After fixing the print pointer, radiusd dies at line 735 trying to run update for the proxy listener. If there are no uncommitted changes to these code sections, I can post a patch here or in bugzilla that should resolve both of these problems. Kevin Bonner
On Wednesday 01 June 2005 18:56, Alan DeKok wrote:
Kevin Bonner <keb@pa.net> wrote:
The proxy listener has several pointers that are never set, as shown by your gdb print above.
Whoops... that as a dumb mistake.
I've committed a fix which should initialize those pointers.
Thanks.
Alan DeKok
Alan, The fix looks good, but radiusd still segfaults at radiusd.c:735 because the proxy update function is NULL. (gdb) bt #0 0x00000000 in ?? () #1 0x0804e709 in main (argc=2, argv=0xfef163f0) at radiusd.c:735 (gdb) frame 1 #1 0x0804e709 in main (argc=2, argv=0xfef163f0) at radiusd.c:735 735 next = listener->update(listener, time_now); (gdb) print *listener $1 = {next = 0x0, type = RAD_LISTEN_PROXY, fd = 8, identity = 0x0, rl = 0x0, recv = 0x805f098 <proxy_socket_recv>, send = 0x805ecf8 <proxy_socket_send>, update = 0, print = 0x805eb34 <socket_print>, data = 0x883d0f0} Here is a patch which should resolve this problem. ==cut here== diff -u -r1.347 radiusd.c --- radiusd.c 27 May 2005 21:19:57 -0000 1.347 +++ radiusd.c 2 Jun 2005 17:14:17 -0000 @@ -732,7 +732,9 @@ listener = listener->next) { int next; - next = listener->update(listener, time_now); + next = (listener->update != NULL) ? + listener->update(listener, time_now) : + SLEEP_FOREVER; if (next < sleep_time) { sleep_time = next; } ==cut here== Kevin Bonner
* Alan DeKok <aland@ox.org> [2005-05-31 14:58:17 -0400]:
Ok, I've fixed that in CVS. Does the resulting executable work?
Mostly! I'm seeing two issues. The first appears to be less of an issue than the second one. Issue 1: I started the server normally and I noticed that when it receives a request it is still sending output to the screen. Wed Jun 1 12:17:18 2005 : Info: rlm_passwd: Adding "Auth-Type = PAP" Wed Jun 1 12:17:26 2005 : Info: rlm_passwd: Adding "Auth-Type = PAP" Wed Jun 1 12:17:36 2005 : Info: rlm_passwd: Adding "Auth-Type = PAP" One would think that they would end up in the radius.log file due to the fact that I have these lines in my radiusd.conf log_file = ${logdir}/radius.log log_destination = files I'm having issues finding this in the code and I'm wondering if gdb is getting in the way of things. Everywhere I debug I keep seeing, in the mainconfig struct that radlog_dest is RADLOG_SDOUT and not RADLOG_FILES. I can set log_destination = foobar and nothing complains either. Maybe I'm missing something obvious? Issue 2: If I telnet into one of my test Cisco routers or switches that are setup to use radius I see this behavior: a. enter correct username/password everything works b. enter correct username with incorrect password I only see these packets radius access request radius access request radius access request radius access request radius accounting request radius accounting response radius accounting request radius accounting response I'm wondering why after freeradius knows I have an incorrect password it isn't sending an access reject? Instead the router sends the request 4 times since it isn't getting a reponse and then fails over to local login mode and then does the accounting request. Has anyone seen this yet other than me? -jason
Jason Ornstein <jason.ornstein@sybase.com> wrote:
I started the server normally and I noticed that when it receives a request it is still sending output to the screen.
Wed Jun 1 12:17:18 2005 : Info: rlm_passwd: Adding "Auth-Type = PAP"
That's annoying. I'll fix that.
I'm wondering why after freeradius knows I have an incorrect password it isn't sending an access reject? Instead the router sends the request 4 times since it isn't getting a reponse and then fails over to local login mode and then does the accounting request. Has anyone seen this yet other than me?
Set "reject_delay = 0". That should work aroud the issue in 1.0.x. For the CVS head, I've substantially re-written the relevant code so that reject_delay should now work as advertised. Alan DeKok.
participants (3)
-
Alan DeKok -
Jason Ornstein -
Kevin Bonner