Alan DeKok wrote: > Padam J Singh wrote: >> The attributes I want to send are VSAs anyway, so I fail to see how this >> violates the RFC. > > It doesn't. Technically. But it's a bad idea. > > Can you explain why you need to send the attributes, and what the NAS > does with them? The reason I would like to use this is because the NAS I am building is a network controller which offers advance features like speed select in the same session, add new IP filter policies applied live on an update. I do not want to implement an out of band service (SNMP/SOAP) to achieve the same for something what the RADIUS protocols says is allowed, and FR claiming it adheres to that RFC.
I have also checked up the diameter protocol - sending attributes in an accounting answer is a *very* acceptable thing. I have even confirmed with the RADIUS Server used by Oracle in their BRM applications used in most telcos that sending VSAs in Accounting-Response is OK and supported. The only other option left is to use CoA. However, the radius client libraries that would form part of the NAS do not implement CoA. I have read up the source code of all radius client libraries offered part of FR and even made by others - none of them have a library which could be used to listen for radius packets on a given port and accept and acknowledge CoA/Packet of disconnect. So I would have to write this from scratch, and would be most happy to contribute back to community. > >> The standard install of FR also includes the following in >> attr.accounting_response: > > Yes... I know. > >> The filter does allow any VSA - I wonder why the modules are not written >> to facilitate sending the attributes to the NAS. > > Because only one out of ten thousand users need to send attributes in > an Accounting-Response. And they can't explain why they need to do it. > Googling for the same suggests a whole lot more users are asking the same question. In my opinion anyone implementing Voice billing and real time rating would love to have this. The reason it is traditionally not required is because NASs are generally dumb, and wouldn't require to even look for attributes in updates. However, the new generation billing requirements are forcing more intelligence onto these NASs. > If the requested functionality isn't used for anything, it won't be > added to the server. > I guess the rational thing to do if the worlds best RADIUS server cannot do this out of the box, then use Diameter or implement CoA. > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- PGP Id 9EED2E09 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html