On Thu, 8 May 2003, Alan DeKok wrote:
> [EMAIL PROTECTED] wrote:
> > support multiple Replicate-To-Realm attributes in the acct_users file? Can
> > I do something like this in acct_users and is it supported?:
>
> The server no longer supports Replicate-To-Realm. Similar
> functionality can be acheived using features outside of the server.
>
> e.g. Selectively logging packets to a 'detail' file, and then using
> 'radrelay' to replicate those records:
>
> DEFAULT Called-Station-Id =~ "123456[0-3]789", Acct-Type = 'foo'
>
> where "foo" is an instance of the 'detail' module.
Well I finally got around to using this method and it seems to be working
fine. I do have a couple of questions though. I'm using snapshot 20030602.
In the accounting{} section, it isn't obvious to me what instances are
called at what time for different Acct-Type's. If I call number
123456789 the accounting{} section only seems to 'execute' the instances
within Acct_IDA and not the other ones (e.g. radutmp) and I therefore
have to duplicate everything inside each instance. Is this correct?
Current configuration is something like this:
(acct_users):
DEFAULT Called-Station-Id == "123456789", Acct-Type := "Acct_IDA"
Fall-Through = No
DEFAULT Called-Station-Id == "876543210", Acct-Type := "Acct_TEST"
Fall-Through = No
DEFAULT Acct-Type := "Acct_STANDARD"
Fall-Through = No
(radiusd.conf):
modules {
[--SNIP--]
detail detail_IDA {
detailfile = ${radacctdir}/detail_IDA
detailperm = 0600
locking = yes
}
detail detail_TEST {
detailfile = ${radacctdir}/detail_TEST
detailperm = 0600
locking = yes
}
detail detail_STANDARD {
detailfile = ${radacctdir}/detail_STANDARD
detailperm = 0600
locking = yes
}
}
accounting {
detail
sql
radutmp
Acct-Type Acct_IDA {
detail
sql
detail_STANDARD
detail_IDA
}
Acct-Type Acct_TEST {
detail
sql
detail_STANDARD
detail_TEST
}
}
The second point is a bug I found in radrelay. We use CVXs and there are
some pretty large attributes included in the accounting packet.
FreeRadius is happy with these attributes but radrelay hangs when reading
it and causes FreeRadius to start dropping the packets with these errors:
Tue Jun 3 11:28:30 2003 : Error: rlm_detail: Failed to aquire filelock
for /var/log/radius_proxy/radacct/detail_STANDARD, giving up
A partial stop packet that causes this is has "Attribute-172818433" with a
large hexadecimal value as below (obfuscated-not original):
Acct-Status-Type = Stop
NAS-Identifier = "cvx5"
Attr-172818433 =
0x86345834658346583465237987aedcf789e7dc97987987897ec987de9f789ce897d987de987cde98798cde978979c8797cde97d97cf9e7df98c7d9e87c97de97fc987edf97ed97fc97def97c97e987c89d79f7e97fcabababdec97ed9f7c9ef9c7def9c79de7f9c7e9f7c9de7f89c79e7f97897089089785e7645c56d463fce65476ef89cef0980e8cf986de6f5ce6d6e3df65e76cef87ed9c09e8f90c8e90f9ce6f76ced56f4e6d3fce6f4de86f9de78f0ef80def89ef78e5f574e56fe56f4e76fde78f9dcd
Attr-172818435 = 0x3030303030303030303030303030303030303030
Service-Type = Framed-User
NAS-Port = 1063
NAS-Port-Type = Async
Called-Station-Id = "1234567890"
Calling-Station-Id = "987654321"
Acct-Delay-Time = 15
Framed-IP-Address = 1.2.3.14
User-Name = "JoeBloggs"
Framed-Protocol = PPP
Acct-Input-Octets = 1076
Acct-Output-Octets = 1344
[--SNIP--]
It would appear that there is some sort of buffer overflow possibility
here in read_one() in radrelay.c
A patch is included below. I realise that this doesn't fix the problem,
but merely hides it, but it is good enough to get me going again with
RadRelay.
diff against: "$Id: radrelay.c,v 1.9 2002/12/04 17:24:29 aland Exp $";
[EMAIL PROTECTED] main]# diff -u radrelay.c.orig radrelay.c
--- radrelay.c.orig 2003-06-03 12:39:13.000000000 +0100
+++ radrelay.c 2003-06-03 12:40:59.000000000 +0100
@@ -179,7 +179,7 @@
{
VALUE_PAIR *vp;
char *s;
- char buf[256];
+ char buf[1024];
char key[32], val[32];
int skip;
long fpos;
Cheers,
Dave.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
