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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html