Arran Cudbard-Bell wrote: > Ok just the asynchronous nature of CoA requests... It's not really the > servers job to process feedback from the various SNMP probes, IDS's , or > track changes in the authorisation of users or their equipment.
Yes. That's what proxying is for. > I guess I can see very few usage cases for CoA where the server will > actually make the decision to send a CoA request on it's own, so why not > just use the client or client libraries ? if user uses more than 2G of bandwidth, then kick them off. This is a valid decision for a server to make. Forking an external program means that it's independent of the server core, and is more difficult to integrate with SQL, etc. > How were you thinking of triggering CoA events? Didn't you say there > were issues with an instance of the server being both a CoA proxy and a > CoA generator ? Yes. If you're going to proxy CoA requests, there's no need to *generate* a CoA request for the one you're proxying. On the other hand, if you're receiving an accounting request, it may make sense to generate a CoA request. > Have to wait for vendor support *grumble*. > > Let me know when you get your trapeze kit so we can compare notes :) Will do. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
