Randy Moore <[EMAIL PROTECTED]> wrote: > Here is what I've been able to determine: > > A CHAP authentication request will cause a SegFault IF it: > 1) Matches a UserName in the radcheck table > 2) Hits the server while the daemon is waiting in 'cleanup_delay' period
That's very weird. I don't see why CHAP is so magical, or why the cleanup_delay matters. But since the problem only happens with SQL, I'll tak a leap in the dark, and say there's a bug in the SQL module. > CHAP authentication requests that match an entry in the 'users' file do NOT > cause a segfault. Probably because some other code path in the SQL module is being taken. > Replicating the problem is quite easy. Simply use radclient to send a > couple of CHAP authentication requests (that match a user in your SQL > radcheck table) one right after the other (within the time set by your > cleanup_delay parameter). Yeah, but I don't run SQL, so it's a little harder for me to take a look at it. > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 23259)] > 0x40026fdc in rlm_sql_authenticate (instance=0x80b80d8, request=0x80ea080) > at rlm_sql.c:376 > 376 memcpy(password_pair->strvalue, row[0], > strlen(row[0])); So I presume that either 'password_pair' is NULL, or row[0] is NULL. Knowing which one is NULL would help. Do: (gdb) p password_pair (gdb) p row[0] What *may* be happening is that the 'paircreate' function on line 375 is failing. The code never checks for a failure, so it will SEGV, instead of recovering. Hmm... in fact, most of the CHAP specific code should be removed from the SQL module. Now that we have rlm_chap, it can take care of all of these issues. Try configuring the modules so that 'chap' is before 'sql' in the authorize section, and there is NO 'sql' in the authenticate section, but there IS a 'chap'. If that works, then the simplest solution is to just delete the CHAP authentication code from the SQL module. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
