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@deployingradius.com> wrote:
On Jul 7, 2015, at 6:56 PM, Pshem Kowalczyk <pshem.k@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