Hi Karl,

On Apr 30, 12:22pm, Karl Gaissmaier wrote:
> Subject: Re: (RADIATOR) Question: Problems with forwarding accounting requ
> Hi Mike,
> Mike McCauley schrieb:
> >
> >[...]
> > > > > 2. Question:
> > > > > Is it possible, that the first host already sends the
> > > > > to the NAS, and the second host just stores the records and nothing
> > > > Yes, that should be fine.
> > >
> > > The question is how? Is this done with the AuthByPolicy or how
> > > can I do this? Can't find anything in the docu how to do this.
> > > Sure, it is not the default behavior by 98% users needed.
> >
> > OK, I see your question now. Sorry.
> >
> > Normally, you would put the AuthBy RADIUS as the last AuthBy. It would then
> > forward (just accounting in your case) to the other radius. And when that
> > radius acknowledged, the first server would send that ack back to the
> > NAS.
> >
> Why do I get two replies only in this configuration and not always when
> I have the "AuthByPolicy ContinueWhileAccept"?
> My problem is the documentation under 6.18.1 AuthByPolicy:
> The default is clearly described, but what happens
> with "ContinueWhileAccept". If the first Auth Modul Accepts and the
> second and so one, how many ACCESS-ACCEPTs are sent to the NAS,
> or what module sends it, the first one, the last one or all?
> What happens if only one modul (not the first) rejects,
> what is sent to the NAS?

This is how Radiator handles multiple AuthBys:

Radiator will always accept, reject or ignore according to the result of the
_last_ AuthBy.

Also, if _any_ of the AuthBys are RADIUS, then Radiator will also reply with
whatever is received from the remote Radius, (when and if one is received).

In the case where RADIUS is the last, you get the behaviour you expect, because
AuthBy RADIUS always returns a result of IGNORE, and then (some time later) it
will reply to the NAS with whatever comes back from the remote radius server.

> > But you are wondering how can you make the first server ack immediately,
> > without waiting for the remote server to reply?
> >
> > Well, we dont really recommend it, but you could put your <AuthBy RADIUS>
> > not the last AuthBy. That would make it forward to the remote server and
> > fall through to the next AuthBy (depending onthe AuthByPolicy, of course).
> > disadvantage of this is that _every_ accounting request from the NAS will
get 2
> > acknowledgements (one from the last AuthBy, and one from the AuthBy RADIUS
> > it gets its reply from the remote server)
> > We dont really recomend this, since it better that if the accounting server
> > dies, that the NAS gets no response and can try its secondard radius
> >
> > [...]
> > >
> > > You solved my problem, but perhaps for you is this a hint that something
> > > is strange with this behavior.
> >
> > Well, its a standard dictionary attribute. I dont really understand why it
> > not in your dictionary. Which one were you using?
> I concatenated Ascend and the newest RFC, in order to have first the Ascend
> part and then overwrite the RFC defined Attributes.
> But again, this is not the problem, I think the problem is my
> bad english, therefore you don't understand it.
> I'll try again to explain it:
> Before I started to forward the accounting requests I had no
> WARNINGS in the logfile, the AuthBy FILE didn't complain
> about missing attributes, even there was no such attribute
> in the dictionary. After I inserted the additional
> AuthBy RADIUS I've seen the WARNINGS about the missing
> The academic question is: Why do I see no such
> warnings with AuthBy File and only with
> AuthBy RADIUS?

Because when the packet is sent to the remote radius, Radiator tries to convert
the 'Timestamp' attribute to a radius attribute number. 'Timestamp' is appended
to the request by Radiator (as per the RFC) when it proxies, and it is  usually
not in the incoming request. Therefore, if Timestamp is not in your dictionary,
you will only see the complaint when Radiator tries to proxy.

> hope you understand it despite my english :-(
I do. You English is fine.


Mike McCauley                               [EMAIL PROTECTED]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
Phone +61 3 9598-0985                       Fax   +61 3 9598-0955

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, 
NT, Rhapsody
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to