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=, > 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=, > fd=, ctx=) 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 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
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
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
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
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: 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
match client's shortname in huntgroups file
Hi, is there an easy/good way to determine the huntgroup depending on the the shortname from clients.conf? We have more than 100 clients configured (with a "ProviderLocationCounter" pattern), so the information is duplicated in the huntgroups file (multiple times, as the huntgroup is also determined by Called-Station-Id). So it would really simplify things to have the shortname available for matching in the huntgroups file. I could extend one of our custom modules to put the name into a VSA and use that like 'Client-Shortname == "blub"' (already did it in a test environment and it works fine), but that seems a little clumsy to me, so I wondered if there's an easier way. unrelated side note: As I see, client_find() walks linearly through the client list. Shouldn't we keep this in a more appropriate data structure, like a btree or a trie, and/or save the once found RADCLIENT* pointer in the REQUEST struct? I understand that it doesn't matter for most installations (and we don't have any performance problems, either), it just does not feel right to waste so many cpu cycles :) regards, J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html