Checking values of attributes
Hi, 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 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: if the packet has the attribute: (0) Received Accounting-Request Id 147 from 10.100.34.17:34759 to 10.100.34.18:1813 length 1213 ... (0) SV-Handled = True (0) # Executing section preacct from file /etc/raddb/sites-enabled/frontend (0) preacct { (0) frontend_files: acct_users: Matched entry DEFAULT at line 1 (0) [frontend_files] = ok (0) if ( request:SV-Handled != True ){ (0) if ( request:SV-Handled != True ) -> FALSE and if the packed doesn't have it: (4) # Executing section preacct from file /etc/raddb/sites-enabled/frontend (4) preacct { (4) frontend_files: acct_users: Matched entry DEFAULT at line 1 (4) [frontend_files] = ok (4) if ( request:SV-Handled != True ){ (4) ERROR: Failed retrieving values required to evaluate condition So, I've changed the condition to read: if ( %{%{request:SV-Handled}:-False} != True ){ But that doesn't seem to work as expected: When the attribute is there (and set to True) it evaluates: (0) Received Accounting-Request Id 239 from 10.100.34.17:52319 to 10.100.34.18:1813 length 1120 ... (0) SV-Handled = True (0) # Executing section preacct from file /etc/raddb/sites-enabled/frontend (0) preacct { (0) frontend_files: acct_users: Matched entry DEFAULT at line 2 (0) [frontend_files] = ok (0) if ( %{%{request:SV-Handled}:-False} != True ){ (0) if ( %{%{request:SV-Handled}:-False} != True ) -> TRUE So, not so good. I've tried a different setup as well: if ( %{%{integer:request:SV-Handled}:-0} != 1 ){ but that suffers from the same problem: (6) SV-Handled = True (6) # Executing section preacct from file /etc/raddb/sites-enabled/frontend (6) preacct { (6) frontend_files: acct_users: Matched entry DEFAULT at line 1 (6) [frontend_files] = ok (6) if ( %{%{integer:request:SV-Handled}:-0} != 1 ){ (6) if ( %{%{integer:request:SV-Handled}:-0} != 1 ) -> TRUE What's the correct syntax here? kind regards Pshem
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.
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
On Jul 7, 2015, at 9:22 PM, Pshem Kowalczyk <pshem.k@gmail.com> wrote:
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?
Yes. And for copying to multiple servers, see raddb/sites-available/copy-acct-to-home-server The process is documented extensively. And it will work. There is no need for custom local hacks. Alan DeKok.
Hi, I got this going after an off-list suggestion to add a simple check: if ( ! &request:SV-Handled || &request:SV-Handled != True ){ Our requirements are slightly different then what that default config offers: 1. Both of the servers are active (and the NASes load-balance between them) 2. We don't care if an accounting packet goes missing every now and then 3. We don't want to store anything on the machine/file system kind regards Pshem On Wed, 8 Jul 2015 at 13:26 Alan DeKok <aland@deployingradius.com> wrote:
On Jul 7, 2015, at 9:22 PM, Pshem Kowalczyk <pshem.k@gmail.com> wrote:
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?
Yes.
And for copying to multiple servers, see raddb/sites-available/copy-acct-to-home-server
The process is documented extensively. And it will work. There is no need for custom local hacks.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 7, 2015, at 10:03 PM, Pshem Kowalczyk <pshem.k@gmail.com> wrote:
if ( ! &request:SV-Handled || &request:SV-Handled != True ){
That helps a bit.
Our requirements are slightly different then what that default config offers:
1. Both of the servers are active (and the NASes load-balance between them) 2. We don't care if an accounting packet goes missing every now and then 3. We don't want to store anything on the machine/file system
You should do replicate checks based on source IP address. It's simpler and easier. if (Packet-Src-IP-Addr != address.of.other.server) { replicate # to the other server } That's simple and clear. Alan DeKok.
participants (2)
-
Alan DeKok -
Pshem Kowalczyk