On 3/6/09 07:53, Arran Cudbard-Bell wrote:

...

If we add a CONSTRAINT to enforce uniqueness for acctuniqueid in the DB, will the failure to insert an accounting record confuse the freerad sql module and will those failures percolate up towards the radius protocol level and thus result in the NAS keep on sending that accounting packet?

Yes. The SQL module will return fail on any errors. This will override the priority of most other modules, and cause the accounting stanza to return fail. The RADIUS server will then ignore the Accounting request, and the NAS will think the RADIUS server is dead.

You should be able to add additional 'uniqueness' with the 'Class' attribute. RFC behavior is identical to User-Name. You set it in the Access-Accept packet, then the NAS includes its value in all future Accounting-Requests.

Example policy for this would be something like : populate_class { # Hashing module only accepts dictionary attributes update request { Tmp-String-0 := "%t" } # # Insert random string into the class attribute # acct_class_unique.accounting update reply { Class := "%{request:Acct-Unique-Session-Id}}" } } and acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port, Class" } acct_unique acct_class_unique { key = "User-Name, Tmp-String-0, NAS-IP-Address, Client-IP-Address, NAS-Port" } For the module configuration. If you're still getting duplicates, check that the NAS is actually sending the value of the Class attribute. Vendors are notoriously bad for ignoring the RFC in this area. Regards, Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2

[snip]

Thanks a bundle for that, I was about to whack my head against the screen here and type "man unlang". ;)

...

If you're still getting duplicates, check that the NAS is actually sending the value of the Class attribute. Vendors are notoriously bad for ignoring the RFC in this area.

Yeah, never mind that we are talking to proxy servers upstream which in turn may talk to other proxy servers (nobody knows) which ultimately talk to the NAS (BRAS) in question.

You might have more luck concatenating the random string with the User-Name and sending that in the Access-Accept. Then stripping it out again when you receive accounting requests. post-auth { update reply { User-Name := "%{User-Name}:%{Acct-Unique-ID}" } ... } -- preacct { ... if(User-Name =~ /([^:]+)(:([[:alnum:]]*))?/){ update request { Acct-Session-ID := "%{Acct-Session-ID}%{3}" User-Name := "%{1}" } } } It's a more commonly used feature so is more likely to work :)

I have seen those quickly recycled Acct-Session-Id's only with one location it seems, other people with twice the connects never had their IDs re-used in the same sample period. So my bet is that this particular NAS will also happily ignore the Class attribute. ^o^

Yey for standards *sigh*.

But nevertheless, a very useful configuration snippet that would do well in a future sample configuration.

Thanks, i'll poke Alan and see if he wants to include it. It'd be nice to have a generic hashing module for string expansions and not have to do some much unlang hackyness, useful for CUI too.

Thanks again for the quick and comprehensive response

No problem. Best of luck ! Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2

On 3/6/09 17:38, Alan DeKok wrote:

Arran Cudbard-Bell wrote:

...

Thanks, i'll poke Alan and see if he wants to include it.

$ git format-patch

:)

Still haven't had feedback on the last one yet !

...

It'd be nice to have a generic hashing module for string expansions and not have to do some much unlang hackyness, useful for CUI too.

update reply { User-Name := "%{md5:foo}" }

It's already there.

Ooooooo useful. Would you be adverse to a patch adding a policy section that provided the requisite behavior for both Access-Accept and Accounting-Request packets ? Or would you like two policy sections. i.e. One that has a switch statement for packet type, or two different policies. The advantage of the one policy is that it's listed with the same name in the require sections of the default config. The disadvantage is the added switch statement. This is more of a general question for future patches... Do you want policies to be self contained, or do you not mind if they sprawl a bit. Thanks, Arran P.S ProCurve switches don't include the Class attribute in Accounting-Requests. Already opened a case. -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2