Re: Version 2.1.12 has been released
Alan DeKok, 2011-09-30 16:33: * Added support for PCRE from Phil Mayers Sorry for not stepping up before, but it seems to me that this only went into the master, not in the 2.1.x branch. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre release of 2.1.10
Hi, Alan DeKok, 2010-09-06 13:58: It's been a few weeks since the last pre release of 2.1.10. I've put another one up on the web at: I tried it, mainly to get rid of the random segfaults we get every few days (bug #35). Unfortunately, last night it a crashed on one machine (after running for about 60h): Sep 16 04:07:22 radius64-01b kernel: [24863577.558534] ui-freeradius[20331] general protection ip:7f6627405b0e sp:7fff11594180 error:0 in libfreeradius-radius-2.1.10.so[7f66273ee000+1f000] backtrace: #0 fr_packet_cmp (a=0x7f6618064700, b=0xf6f5bc5f78c00c80) at packet.c:139 #1 0x7f66273f7a54 in fr_hash_table_find (ht=0x278fa30, data=0x7fff115941e0) at hash.c:191 #2 0x7f66273f7a99 in fr_hash_table_finddata (ht=0x7f6618064700, data=0xf6f5bc5f78c00c80) at hash.c:484 #3 0x7f662740572b in fr_packet_list_find (pl=value optimized out, request=0x7f6618064700) at packet.c:583 #4 0x00427bd9 in received_request (listener=0x2794400, packet=0xf6f5bc5f78c00c80, prequest=0x79, client=0x7f6627408600) at event.c:2822 #5 0x00415ac6 in auth_socket_recv (listener=0x2794400, pfun=0x7fff11594348, prequest=0x7fff11594340) at listen.c:826 #6 0x00422e5e in event_socket_handler (xel=value optimized out, fd=value optimized out, ctx=value optimized out) at event.c:3410 #7 0x7f6627406a16 in fr_event_loop (el=0x2789c00) at event.c:411 #8 0x0041c322 in main (argc=1, argv=0x80) at radiusd.c:406 Is there anything we can do to help sorting this out? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Change of logging behaviour in 2.1.9
On 18.06.2010 17:48, Alan DeKok wrote: I just wonder why there is such a change in a patch level update. And what the above mentioned bug was about... The bug was that it *wasn't* re-opening the log file on HUP. Since this is expected behavior, it needed to be fixed. But it was already re-opening the log file for every log write, obviously, so I don't see, why that was necessary. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Change of logging behaviour in 2.1.9
Bjørn Mork, 2010-06-17 18:28: * re-open log file after HUP. Closes bug #63. FWIW we have been HUPing the server from a daily, unattended process with FR 2.1.8 since it was released (we need it to rotate log files Ok. That's what we are doing now, too. After all, other daemons (apache, rsyslogd etc.) are doing the same all the time. I just wonder why there is such a change in a patch level update. And what the above mentioned bug was about... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Change of logging behaviour in 2.1.9 (was: Version 2.1.9 has been released)
Hi, Alan DeKok, 2010-05-24 12:28: * re-open log file after HUP. Closes bug #63. Since the update to 2.1.9 a new log file is _only_ opened on HUP. Is this behaviour intended? Previously we just let logrotate rename the old logfile and freeradius created a new radius.log. I'm aware that it is not very efficient to do open/write/close all the time, but it just worked [tm]. Is the only possibility to reopen the log file now to send HUP to the server? I don't feel very comfortable with this. The server reloads the config, modules and whatnot. I think this is not something that one wants to do in a daily, unattended process. Isn't there any other, less intrusive method to tell freeradius to reopen the log file? (besides a restart, of course) Regards, Jakob - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: cannot get core dump of crashing freeradius
Alan DeKok, 04/20/2010 06:21 PM: btw, I wonder why is prctl() is not called when debug_flag is set. I would have thought that one would want to get a core dump especially when running in debug mode. It doesn't switch UIDs when in debug mode. So it inherits whatever AFAICS it does when starting it as root (check in mainconfig.c:532). I'd say a quite common case for debugging is to run freeradius -X as root... OK. This will become a non-issue when the prctl() calls are moved into the fr_suid_* functions. :) Would you like me to prepare a patch for that or would you rather do that yourself? Anyway, here's the aftermath: I got my core dump, finally, and it turns out that we are probably hit by the notorious bug #35 (as I half feared, half hoped :). I will try the fix for list_delete() you proposed if I can get to it... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: cannot get core dump of crashing freeradius
Alan DeKok, 2010-04-20 10:54: So after some debugging I got to the root cause of this: The process's dumpable flag is reset every time the UID is changed. FR does this several times with fr_suid_up() and fr_suid_down() after switch_users() is run, e.g. in listen_bind(). So I guess we have to change the fr_suid_* functions to always set the dumpable flag after setting the uid. Ah... OK. That can be fixed for 2.1.9. Excellent! :) Any idea when it will be released? btw, I wonder why is prctl() is not called when debug_flag is set. I would have thought that one would want to get a core dump especially when running in debug mode. It doesn't switch UIDs when in debug mode. So it inherits whatever AFAICS it does when starting it as root (check in mainconfig.c:532). I'd say a quite common case for debugging is to run freeradius -X as root... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: cannot get core dump of crashing freeradius
Alan DeKok, 2010-04-16 12:05: Often 'root' can't core dump, and programs that change uid can't core dump. It's hard to know what's going on with the OS. ok, I digged deeper into this and made some tests: - no core dump with kill -11 - /proc/sys/fs/suid_dumpable is 0, set it to 1 and restart FR - kill -11 - core dump, yeah! So it's probably a problem with the uid change disabling the process' dumpability (I found nothing in /proc/[pid]/* where I can see this. So we have now all machines running with /proc/sys/fs/suid_dumpable set to 1. Strange thing is, this should not be neccessary with the prctl(PR_SET_DUMPABLE, 1) in mainconfig.c:698. Anyway, I'm now looking forward for FR to crash :) Any hints? doc/bugs. You'll need symbols to find out what's going on. I know, and I have them (in the -dbg package), but they are useless without a core dump :) Maybe the info about /proc/sys/fs/suid_dumpable should be added to doc/bugs... Thanks for your input! Regards, J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: cannot get core dump of crashing freeradius
Alan Buxey, 2010-04-19 16:43: Maybe the info about /proc/sys/fs/suid_dumpable should be added to doc/bugs... to quote the man page: /proc/sys/fs/suid_dumpable (since Linux 2.6.13) ... i dont think this got enough coverage in most information outlets..in fact 2.6.13 has been around for a while but today was the first time i learnt of that behaviour. I agree, even though it's mentioned in the CORE(5) man page. maybe FreeRADIUS code updated to detect this value...and if its set to 0 then it could mention it in the debug output? ;-) Maybe, but with calling prctl(PR_SET_DUMPABLE, 1) this should not be necessary any more. I tried this with a small test program and it worked as specified, but still I won't get a core dump of the FR process unless I set suid_dumpable to 1. So after some debugging I got to the root cause of this: The process's dumpable flag is reset every time the UID is changed. FR does this several times with fr_suid_up() and fr_suid_down() after switch_users() is run, e.g. in listen_bind(). So I guess we have to change the fr_suid_* functions to always set the dumpable flag after setting the uid. btw, I wonder why is prctl() is not called when debug_flag is set. I would have thought that one would want to get a core dump especially when running in debug mode. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
cannot get core dump of crashing freeradius
Hi, we have freeradius 2.1.8 running on a couple of servers and are very happy with it. But every few days FR crashes on one of the servers (a random one, not always the same). The load is significant (average 150 requests/s per server, 400/s peak) but sureley not too high. So everything seems to run fine besides the annoying crashes, which alarms people and make the weekly availibility reports look bad (even though FR is restarted automatically, of course). The previous 1.1.8 installation we upgraded 6 months ago from did not have this problem. Anyways, I really want to find out what's going wrong, so I wanted to get core dumps of these crashes. Only that I just don't get them. - radiusd.conf has allow_core_dumps = yes (and FR says Info: Core dumps are enabled. at startup) - /proc/sys/kernel/core_pattern is set to '/tmp/core.%t.%e.%p', so core dumps can be written to disk (tested with a little programm that forces a segfault) - I put ulimit -c unlimited in the startup script. cat /proc/$(pidof freeradius)/limits shows unlimited for soft and hard limit of Max core file size So what's missing? The only indication of the crash is this line in syslog: Apr 10 17:57:19 kernel: [12268615.000288] freeradius[14846]: segfault at 73818 ip 7f0cb40e875e sp 7fff9c6304c0 error 4 in libfreeradius-radius-2.1.8.so[7f0cb40d1000+1f000] (This is debian lenny x86_64, btw.) Any hints? I even thought about running FR as a foreground process or even with gdb, but I wanted to check here first. Regards and thanks in advance, Jakob - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
operator !* in update {}
Hi,
according to unlang:
!* Delete all occurances of the named attribute, no matter what the
value.
but when I want to use it like that:
post-auth {
Post-Auth-Type REJECT {
update reply {
Idle-Timeout !* 0
Session-Timeout !* 0
}
}
}
but freeradius (2.1.7) does not seem to like it:
/etc/freeradius2//sites/ui.site.conf[205]: Parse error after Idle-Timeout
other operators work, e.g.
...
update reply {
Idle-Timeout -= 7200
Session-Timeout -= 86400
}
...
but that's not handy...
Regards,
Jakob
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: operator !* in update {}
Alexander Clouter, 2009-11-13 13:03:
/etc/freeradius2//sites/ui.site.conf[205]: Parse error after Idle-Timeout
I get the same thing and kept meaning to file a bug report. I opted as
a quick hack:
update reply {
Blar -= %{reply:Blar}
}
Thanks, that's clever!
Also thanks to Alan for the quick fix! The diff is small, so I'll patch
that in.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 1.1.8 has been released
Hi, Alan DeKok, 2009-09-09 14:54: We have released version 1.1.8 to fix an issue with the handling of Tunnel-Password. This is the same issue that was found in version This sounds harmless for most people, I guess, or at least for us, as we don't use Tunnel-Password. But reading CVE-2009-3111 and looking at the patch, it seems that this can crash any server just by sending an empty attribute. That would mean that every 1.1.7 installation should upgrade to 1.1.8 ASAP. Right? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: regexp matches are sensitive to position in check items
Phil Mayers wrote: This is caused by an apparent bug in src/main/valuepair.c. Line 287 should say continue; instead of return 0;. ... I'll be happy to provide a patch, I just don't know if Alan will release any further 1.1.x version. Does the same bug not exist in 2.0? I think not. I took a quick look, and the line I mentioned has just the fix I proposed. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: regexp matches are sensitive to position in check items
Quoting Phil Mayers:
Basically, this works in hints:
DEFAULT NAS-Port-Id =~ (.+):(.+), NAS-Port !* ANY
NAS-Port = `%{expr:1000*%{1} + %{2}}`,
Fall-Through = Yes
...but this does not:
DEFAULT NAS-Port !* ANY, NAS-Port-Id =~ (.+):(.+)
NAS-Port = `%{expr:1000*%{1} + %{2}}`,
Fall-Through = Yes
...as %{1} and %{2} are undefined in the latter case. I would have
expected this to be the opposite case if anything. Is this expected?
I just stumbled over the same, but with huntgroups. Both use paircmp(),
so they have the same problem: a positive !* (T_OP_CMP_FALSE)
condition short-cuts the whole line, so the remaining comparisons are
not done. In your case, the regex is not done then, so %{*} are not defined.
This is caused by an apparent bug in src/main/valuepair.c. Line 287
should say continue; instead of return 0;.
Oh, and to save some processor time, the same logic there (only inverted
) could be used for the =* (T_OP_CMP_TRUE) operator.
I'll be happy to provide a patch, I just don't know if Alan will release
any further 1.1.x version.
In 2.0 I would use an if unlang, but this is on our (soon to be
upgraded) production servers.
Hope we can do this here soon, too.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS 2.0.0-pre2 has been released
Quoting Alan DeKok:
As I understand the virtual servers, it is possible to have all vservers
listen to the same ip/port socket, but have different client
configurations. Is that right?
Hmm... hadn't thought of doing it that way. It could be possible.
Meaning try it and get back to list when you have the results? :)
And would that be a sensible thing to do in a high traffic environment
(many million requests per day)? I'd think that every request would have
to be processed by all the vserser instances only to decide that the
request has to be discarded by most of them.
No. The idea would be do tie a client to a virtual server. Then, all
requests from that client would be sent to one, and only one virtual server.
That's what I want.
Allow me to elaborate on that:
a global listen section:
listen {
ipaddr = 10.0.0.1
type = auth
}
two virtual servers:
server foo {
client 10.1.0.1 {
secret = secret1
}
autz...
auth...
}
server bar {
client 10.2.0.1 {
secret = secret2
}
autz...
auth...
}
So 10.1.0.1 and 10.2.0.1 will both send their requests to the server's
address 10.0.0.1, and freeradius will determine by itself (with little
performance penalty) the proper virtual server for the requests?
And no matter what, a request is handled by *one* virtual server. You
seem to be saying that a request will be handled by many in parallel.
That will never happen, for the reasons you point out.
Ok, that's what I wanted to read :)
But what happens with requests that could be processed by more than one
virtual server? Like, in the example above, if they had both the same
client definition (same ip-address, same secret). Random, sequentially
selected (e.g. first match wins), config error, doomsday?
(Hm, it's really time to set up a test installation... )
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS 2.0.0-pre2 has been released
Quoting Alan T DeKok: Hi, After much waiting, 2.0.0-pre2 has been released. It contains MAJOR Wow, looks very nice! The unlang will probably will allow us to throw away some of our own modules. As I understand the virtual servers, it is possible to have all vservers listen to the same ip/port socket, but have different client configurations. Is that right? And would that be a sensible thing to do in a high traffic environment (many million requests per day)? I'd think that every request would have to be processed by all the vserser instances only to decide that the request has to be discarded by most of them. Regards, Jakob - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Blocking Interim-Update Accounting-Requests
Alan DeKok wrote:
If you are trying to log some packets and not others, then do
conditional logging. e.g. if packet is type I want to log
That's exactly what I want. And it works now with using Acct-Type.
Thanks for that!
For the list archive (using version 1.1.4):
acct_users:
DEFAULT Acct-Status-Type == Interim-Update, Acct-Type := IGNORE
radiusd.conf:
preacct {
files
...
}
accounting {
Acct-Type IGNORE {
ok
}
dumpinacct
ok
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Blocking Interim-Update Accounting-Requests
Hi, is it possible to filter out accounting requests with an Acct-Status-Type of Interim-Update? rlm_attr_filter works obviously only when we are a proxy, and rlm_files with this acct_users changed nothing: DEFAULT Acct-Status-Type == Interim-Update, Auth-Type := Reject DEFAULT Acct-Status-Type == Start, Auth-Type := Accept DEFAULT Acct-Status-Type == Stop, Auth-Type := Accept I guess it's just not possible to handle acct-requests that way... Anybody with an idea? Otherwise I'll have to add that to our logging module. TIA. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
