Skip to content

DaloRADIUS Profiles

Posted in Server

In continuation of the RADIUS Inside Out article, we will consider how to handle DaloRADIUS Profiles.

Profiles are a way of enforcing restrictions per user connections. Thus, any user connected to your network, if you wish to regulate how their browsing experience is, such as how much Megabytes can be used, how many days a user is allowed to connect, download and upload bandwidth, and others.

In this article, I’ll share steps to enforce these rules:

  • User can use up to only 500 Megabytes of data (i.e ChilliSpot-Max-Total-Octets)
  • User’s connection to the network after first time login lasts up to only 3 days (i.e Access-Period)

The ChilliSpot-Max-Total-Octets and Access-Period above are known as Attributes of a Profile.

The ChilliSpot-Max-Total-Octets does what its name suggests – helps us track how much data has been used. This is an attribute that comes with Chillispot configurations. So if you’re using a DD-WRT Firmware-enabled Router with Chillispot configurations, you should be able to monitor this attribute easily and straightforward.

The Access-Period also comes with Freeradius and with just a few configurations, we’re good to enforce this attribute.

If you do not want to worry about any of the configurations herein, check out these files:

The SQL Counter:


So, let’s get to it!


Let’s do an example. Let’s say we want to monitor the traffic of each user, and stop them from using more than 500 Megabytes of data. That is, any user created, assigned the group we’re about to create, can’t use more than 500 Megabytes.

In the /etc/freeradius/sql/mysql/counter.conf, add this to the bottom:

Pretty straightforward, right?

Now, in the DaloRADIUS Web management interface, do the following

Create new Profile

Create Profile Daloradius
Create Profile Daloradius

The above screenshot is an example to show what goes where.

  • Add Profile Name
  • Select Vendor of choice, this case we’re gonna use a Chillispot attribute
  • Wait for the ‘Attribute’ section to load, and choose ‘Chillispot-Max-Total-Octets’
  • Click on the ‘Add Attribute’
  • Scroll down a bit, and input the number of Megabytes (in Bytes) you wish to restrict a user to max.
  • Leave the ‘Op’ file as ‘:=’ and ‘Target’ as ‘reply’
  • Click on ‘Add Attribute’ again, and follow same procedure, however this time, just change from ‘reply’ to ‘check’
  • Apply your changes.

If all the above was nonsense to you, see in action under 30 seconds:

To enforce the above, we need to tell Freeradius to consider the above attribute during authorization. With telling Freeradius to do so, the user will get disconnected when the attribute is matched, however, upon re-login, they’ll succeed and enjoy a bit of browsing before kicked off again.

The first step is to allow Freeradius to instantiate our counter module when it starts. We need to go look for the instantiate { } block in /etc/freeradius/radiusd.conf and add our chillispot_max_total_octets, as shown in the screencast below:

Next, we need to include the Chillispot attribute during authorization, so that user can’t login if their data bundle is exhausted.

That will need to happen in the /etc/freeradius/sites-available/default file.

Restart Freeradius.

Create User and assign to the Group created ( or Profile)

Create User Daloradius
Create User Daloradius

Restart the Freeradius instance, and test to see if created user only lasts the number of Megabyte of data usage you set.

Max 3 Days using Access-Period Attribute

One beauty in DaloRADIUS is the ability to view tooltips of what many of the attributes are meant for. For instance, the Access-Period we’re about to use is nicely explained as so:

So, just as done for the Chillispot Max Total Octets steps above, you follow the same steps to add a new Profile or edit the existing profile and append the Access-Period as shown below:

The sqlcounter for the above Access-Period which will be appended to the /etc/freeradius/sql/mysql/counter.conf file is this:

Then, append access_period to both /etc/freeradius/radiusd.conf and /etc/freeradius/sites-available/default files at instantiate { } block and authorize { } block respectively.

Restart Freeradius, and test.