Checking values of attributes
Pshem Kowalczyk
pshem.k at gmail.com
Wed Jul 8 03:22:22 CEST 2015
Hi,
I failed to state, that these attributes live in their own Vendor space:
VENDOR SparkVentures 4083
BEGIN-VENDOR SparkVentures
Is that sufficient to separate them?
kind regards
Pshem
On Wed, 8 Jul 2015 at 13:19 Alan DeKok <aland at deployingradius.com> wrote:
> On Jul 7, 2015, at 6:56 PM, Pshem Kowalczyk <pshem.k at gmail.com> wrote:
> > I've recently upgraded our servers from 3.0.4 to 3.0.8. We have two
> radius
> > servers that replicate received accounting packets to each other (so the
> > local DBs remain in sync). In order to prevent loops before the packet is
> > sent a local attribute is added (defined in the dictionary) to indicate
> > that it should only be processed locally (and not replicated again).
> >
> > In 3.0.4 we used the following syntax:
> >
> > preacct {
> >
> > ...
> >
> > if ( request:SV-Handled != True ){
> > update {
> > request:SV-Handled := True
> > }
> > replicate
> > }
> > ...
> >
> > }
> > with the attribute defined like this:
> >
> > ATTRIBUTE SV-Handled 2 integer
>
> Uh... no. Don't do that. Attribute 2 already has a defined meaning.
> Go read raddb/dictionary, and create a site-local attribute.
>
> > VALUE SV-Handled False 0
> > VALUE SV-Handled True 1
> >
> > and that condition worked well - only packets from the NAS (that didn't
> > have the attribute at all) were matched.
> >
> > Now, with 3.0.8 the behaviour has changed:
>
> Probably because the packet already has a User-Password attribute...
> which is attribute 2.
>
> > What's the correct syntax here?
>
> Don't redefine attribute 2. Use the site-local attributes defined in
> raddb/dictionary. Then, try it again.
>
> Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list