Alan DeKok wrote:
Padam J Singh wrote:
From the RFC 2866:
Yes, I have read the RFC's. They're even in the FreeRADIUS source tree. They'are referenced from http://freeradius.org/rfc/, which was built by me.
The RFC doesn't categorically say that an accounting response packet SHOULD NOT have attributes.
Read the REST of the RFC. Specifically, the Table of Attributes.
Citing the Table of Attributes: No attributes should be found in Accounting-Response packets except Proxy-State and possibly Vendor- Specific. The attributes I want to send are VSAs anyway, so I fail to see how this violates the RFC.
The NAS is an application I have written - so I will be able to parse attributes in an accounting response.
Your application is wrong. If it needs to have attributes sent back in an Accounting-Response packet, then it's not doing RADIUS properly.
According to the RFC - VSAs are allowed, and it is up to the vendor to implement handling such responses.
If the standard postgres module cannot be used to send back attributes in an accounting-response packet, can I do the same using any other module like JRadius? I have gone through the rlm_jradius source code, and it looks like it doesn't differentiate between accounting and authorization responses when reading value pairs.
If you can get something to work, good luck. But the server is NOT intended to send attributes back in the Accounting-Response.
The standard install of FR also includes the following in attr.accounting_response: DEFAULT Vendor-Specific =* ANY, Message-Authenticator =* ANY, Proxy-State =* ANY The filter does allow any VSA - I wonder why the modules are not written to facilitate sending the attributes to the NAS.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- PGP Id 9EED2E09