-Name = jcc'
rlm_acct_unique: Acct-Unique-Session-ID = b9953681ea576605.
perl_pool: item 0x8185d50 asigned new request. Handled so far: 1
found interpetator at address 0x8185d50
rlm_perl: Added pair User-Name = jcc
rlm_perl: Added pair Acct-Session-Id = accounting-session-1
rlm_perl: Added pair Sip
Justin Church [EMAIL PROTECTED] wrote:
Anything in this debug indicate why the server doesn't send
Accounting-Response?
The server didn't log the accounting information anywhere, therefore
it's not safe to tell the NAS that the accoutning information was
stored on the server.
Alan DeKok.
The server created an entry in my detail file. Is that not considered
logging? If not, where should I look to see why the server isn't logging?
rad_recv: Accounting-Request packet from host 152.2.199.26 port 32839,
id=139, length=80
User-Name = jcc
NAS-Port = 5060
Nevermind. I turned off -X and found this in radius.log:
Mon Sep 25 18:19:23 2006 : Error: rlm_unix: no Accounting-Status-Type
attribute in request.
It shows up in stdout with -X also, but not as an Error, so I overlooked it.
Added Accounting-Status-Type to packet, and server is now
Was there any final word on the direction of this and when it might be
available?
Thanks.
-jc
Peter Nixon wrote:
On Thu 07 Sep 2006 15:07, Alan DeKok wrote:
Kostas Kalevras [EMAIL PROTECTED] wrote:
Just a side note on the clone packets issue i ve come across it in
another situation. We act
Justin Church [EMAIL PROTECTED] wrote:
Was there any final word on the direction of this and when it might be
available?
Whenever someone gets time to do the work...
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
On Wed, 6 Sep 2006, Alan DeKok wrote:
Justin Church [EMAIL PROTECTED] wrote:
OK. The patch worked, since I can now run radiusd -n radrelay w/o the
Abort, but I still am not seeing a way to replicate to multiple
accounting servers with radiusd -n radrelay.
Unfortunately, it doesn't yet do
On Thu 07 Sep 2006 08:05, Kostas Kalevras wrote:
On Wed, 6 Sep 2006, Alan DeKok wrote:
Justin Church [EMAIL PROTECTED] wrote:
OK. The patch worked, since I can now run radiusd -n radrelay w/o the
Abort, but I still am not seeing a way to replicate to multiple
accounting servers with
Kostas Kalevras [EMAIL PROTECTED] wrote:
Just a side note on the clone packets issue i ve come across it in
another situation. We act as a proxy for various ISPs and we need to
have a way to replicate accounting-on/off packets (which obviously
don't carry a [EMAIL PROTECTED] attribute) to all
Justin Church [EMAIL PROTECTED] wrote:
How would the proxy.conf work? Would you define N identical realms with
different remote servers, and the 1-N proxy server would replicate to
the first N matches it finds in proxy.conf?
That's an option.
I'm open to suggestions as to how to
On Thu 07 Sep 2006 15:07, Alan DeKok wrote:
Kostas Kalevras [EMAIL PROTECTED] wrote:
Just a side note on the clone packets issue i ve come across it in
another situation. We act as a proxy for various ISPs and we need to
have a way to replicate accounting-on/off packets (which obviously
Thanks for the great work, Alan. I've built the latest CVS head and am
able to manipulate the attributes in %RAD_REQUEST with rlm_perl.
However, I notice that radrelay has been deprecated and the
functionality moved into radiusd. How am I to run simultaneous
instances of radiusd on the same
Justin Church [EMAIL PROTECTED] wrote:
However, I notice that radrelay has been deprecated and the
functionality moved into radiusd. How am I to run simultaneous
instances of radiusd on the same host - 1 to listen to type 'acct' and 1
to listen to type 'detail'? I apologize if I'm missing
OK. The patch worked, since I can now run radiusd -n radrelay w/o the
Abort, but I still am not seeing a way to replicate to multiple
accounting servers with radiusd -n radrelay. I need to take accounting
requests that arrive at main-radius in radrelay-detail and replicate
them to
Justin Church [EMAIL PROTECTED] wrote:
OK. The patch worked, since I can now run radiusd -n radrelay w/o the
Abort, but I still am not seeing a way to replicate to multiple
accounting servers with radiusd -n radrelay.
Unfortunately, it doesn't yet do that. The issue is that the server
Justin Church [EMAIL PROTECTED] wrote:
Is this in the CVS head, yet?
Yes.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Pshem Kowalczyk [EMAIL PROTECTED] wrote:
So I've compiled the source and gave it a try, but it behaved exactly
as the stable version - didn't replace nor removed any attributes. Is
this supposed to work?
I tested the pre and post proxy methods:
...
# Function to handle pre_proxy
sub
On 8/29/06, Alan DeKok [EMAIL PROTECTED] wrote:
Pshem Kowalczyk [EMAIL PROTECTED] wrote:
So I've compiled the source and gave it a try, but it behaved exactly
as the stable version - didn't replace nor removed any attributes. Is
this supposed to work?
I tested the pre and post proxy methods:
Pshem Kowalczyk [EMAIL PROTECTED] wrote:
$RAD_REQUEST{'User-Name'} = 'testuser';
You're re-writing the request packet (i.e. the one from the NAS),
not the packet that's about to be sent to the home server.
Try: $RAD_PROXY_REQUEST{'User-Name'} = 'testuser';
I added:
use
On 8/30/06, Alan DeKok [EMAIL PROTECTED] wrote:
Pshem Kowalczyk [EMAIL PROTECTED] wrote:
$RAD_REQUEST{'User-Name'} = 'testuser';
You're re-writing the request packet (i.e. the one from the NAS),
not the packet that's about to be sent to the home server.
Try:
On Wednesday 23 August 2006 20:25, Alan DeKok wrote:
Peter Nixon [EMAIL PROTECTED] wrote:
That would seem like th logical way to do it, and would certainly make
the perl code clearer..
Ok. Unless Boian Jordanov has concerns, I'll commit a patch in a
few days.
Please i have no concerns
Hi
I've noticed this comment in the cvs log (for rlm_perl.c):
Over-write existing vp's with new ones.
This means that the Perl module works more like the other modules,
which have absolute power over the VP's, and less like the users
file, which updates the VP's via
On 22/08/06, Alan DeKok [EMAIL PROTECTED] wrote:
i.e. put the attributes into perl hashes, and then make those perlhashes definitive for the new values of the attributes.This wouldinvolve throwing away the previous attributes entirely.So you wouldhave to be *very* careful about modifying the
On Wed 23 Aug 2006 01:49, Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question,
I think what I'm really trying to do is rewrite $RAD_REQUEST, not
$RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any
way - either change or add.
When might this be available?
Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question, I
think what I'm really trying to do is rewrite $RAD_REQUEST, not
$RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any
way - either change or add.
Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question, I
think what I'm really trying to do is rewrite $RAD_REQUEST, not
$RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any
way - either change or add.
Hmm... looking into it in a little
Peter Nixon [EMAIL PROTECTED] wrote:
That would seem like th logical way to do it, and would certainly make the
perl code clearer..
Ok. Unless Boian Jordanov has concerns, I'll commit a patch in a
few days.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
George C. Kaplan [EMAIL PROTECTED] wrote:
Sounds good. I assume you'll include %RAD_CHECK, as well as
%RAD_REQUEST and %RAD_REPLY in this change. That would bring rlm_perl
into line with other authentication modules, which can alter any of the
three attribute lists.
Yes.
What would be
JC My goal is to inspect the received attributes
JC using rlm_perl in the preacct{} phase before they are written to log in
JC the accounting{} phase and possibly remove/rewrite/add attributes before
JC they are logged. Is this possible with rlm_perl?
1) You are trying this thing:
preacct{
if(
I'm running freeradius v. 1.1.0 and am trying to use rlm_perl to rewrite
accounting attributes before they are written to log with detail and
then replicated with radrelay. Here is the version of example.pl that
I'm using (I've only added a single statement to the preacct function):
use
Yes, this is due to the way rlm_perl works by default (new pairs
can be added but existing ones not changed). Look back a week or so in
the mailing list archives to the problem I was having. There is a patch
on the list that will allegedly make it into HEAD. The patch works
nicely for me.
AlexOn
on
the list that will allegedly make it into HEAD. The patch works nicely
for me.
Alex
On 22/08/06, *Justin Church* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
I'm running freeradius v. 1.1.0 and am trying to use rlm_perl to rewrite
accounting attributes before they are written
Justin Church [EMAIL PROTECTED] wrote:
I see the patch you're referring to, but after rethinking my question, I
think what I'm really trying to do is rewrite $RAD_REQUEST, not
$RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any
way - either change or add.
Yeah, I just
I see the patch you're referring to, but after rethinking my question, I
think what I'm really trying to do is rewrite $RAD_REQUEST, not
$RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any
way - either change or add.
Hmm... looking into it in a little more detail,
On 8/23/06, Alan DeKok [EMAIL PROTECTED] wrote:
I see the patch you're referring to, but after rethinking my question, I
think what I'm really trying to do is rewrite $RAD_REQUEST, not
$RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any
way - either change or add.
Alan DeKok wrote:
I see the patch you're referring to, but after rethinking my question, I
think what I'm really trying to do is rewrite $RAD_REQUEST, not
$RAD_REPLY, and it does not appear that I can alter $RAD_REQUEST in any
way - either change or add.
Hmm... looking into it in a little
36 matches
Mail list logo
