How to properly originate CoA?

Alan DeKok aland at deployingradius.com
Fri Jun 26 03:49:38 CEST 2015


On Jun 17, 2015, at 6:49 PM, firing neurons <firingneurons at mail.com> wrote:
>   I have a 3.0.8 server with auth, acct and CoA working. I am only
>   sending NAS-IP-Address and User-Name in the CoA request right now. I
>   have the update coa in accouting so that a CoA is sent on each interim
>   update. Also, I have a custom counter that does monthly bytes counting
>   working.

  That's good.

>   I want to rate limit users for X amount of data and then throttle or
>   disconnect (send Acceses-Reject) them based on the group they belong
>   to. My current plan:
> 
>   Have the data and speed limits assgined by groups. So there will be
>   group check items for the data consumed and group reply items that will
>   assign the speed limit via NAS specific attributes. I use mpd. It
>   doesn't support the Max-Octets attributes :/. So disconnection and rate
>   change can only be done either by a hard timeoute (bad) or by CoA.

  That should work.

>   Questions:
>   How can I send diffrent values of rate in the CoA requests depending
>   upon the data usage? I have the basic idea that I have to use xlat sql
>   query but I don't speak sql.

  You'll have to learn.  It should be simple.  Get an SQL tool, and try the SQL queries by hand.  They're mostly pretty simple, to be honest.

> Has the query already been done?

  No.

>   The monthly counter takes care of preventing users from connecting once
>   they cross the data limit but they must be disconnected once. How do I
>   send PoD or CoA based on the group of the user?

  You just check for the group and then do "update coa" ...

	if (LDAP-Group == "bad guys") {
		update coa {
			...
		}
	}

>   Where can I find the documentaion for state variables?

  What do you mean by that?

> How can I avoid
>   the recalculation of acct data on each interim update and unnessasory
>   CoA requests?

  You don't.  The SQL table stores user data.  You recalculate it on every interim packet, and update SQL.  Then, if they're over the limit, disconnect them.

  Once they're disconnected, you won't be receiving interim update packets, and you won't be recalculating accounting data, and you won't be sending more CoA packets.

  Alan DeKok.




More information about the Freeradius-Users mailing list