Chilli is running on the NetModule router and has three major interfaces:

• A downlink interface for accepting connections from clients - typicaly the WiFi interface
• A radius interface for authenticating clients → Radius server runs on the back end
• An uplink network interface for forwarding traffic to other networks → VPN tunnel to back end

In a Standalone scenario all software runs on the NetModule router and beside the internet connection no other functionality is needed. In a Backend scenario there is additionaly functionality on an additional server. In a typical scenario the router is connected via bridged VPN (layer 2) to the backend server and all trafic is routed through the tunnel. The landing pages as well a radius server for user management are also running on the backend.

In Services→Hotspot you can enable the CoovaChilli standalone Captive Portal With this Captive Portal every WLAN client need to accept the “terms of service” before acces to the internet will be granted. This feature is enabled by default on this patchimage.

This patchrelease is equipped with a preconfigured OEM configuration. The configuration is a good starting point for the hotspot service.. Please keep mind that the OEM preconfiguration will delete the current config on your device and apply the OEM Configuration.

• PWLAN standalone image

The following section describes the steps you need to execute to have the CoovaChilli WLAN Hotspot running. Please do not install this image if you are not connected directly via ethernet to the router. You will loose any remote access during the installation.

1. Visit the web manager and set your administration password
   • After connecting your PC to the router via ethernt you should get an ip address from the 192.168.1.0/24 range. Please visit the website http://192.168.1.1 and set your administration password
2. WWAN Link installation
   • Please configure your WWAN Connection according to the needs of your SIM Card. If this step is successfull you will see a steady Mob1 LED on the front of the router.
3. Enable Hotspot Service
   • Please enable the Hotspot Service under Services→Hotspot. From now on every WLAN Client will see a landing page with the default terms of service before getting access to the internet. See Figure 1 and Figure 2.
4. Checking the Captive Portal
   • Please connect to the WLAN “coovachilli” with a WLAN Client (laptop, smartphone or tablet). Depending on your client device you will get the entry page directly. In most cases you will need to request a webpage with your browser to get the entry page. On this page you need to accept the “terms of service” before you will be forwarded to the Webpage you requested.

To use your own landing page, please take a look at the example you can find on the on the Services→Hotspot Page after you enabled the Custom Landing Page. The Hotspotservice need to be enabled to get the example file. See Figure 3.

After you downloaded the example packe you can use it directly by uploading it with the with the “Browse” Button. After you choose the the example package and pressed apply you will see the logo on the landing pages changed from the CoovaChilli to the netmodule logo. See Figure 4.

Please extracted the files from the example package. Based on this files you can customize every page used for a new wlan client. Be aware to not change the filename of the files included. The hotspot service relies on this file names. The files are used as follows:

• coova.html is the first page the WLAN client will see after requesting a webpage, redirecting to the real landing page
• terms.tmpl is the landing page it self, where the user have to accept the terms of service
• login_sucess.tmpl is the success page after accepting the terms of service and will redirect the user to the page requested at the beginning.
• coova.jpg is just an example image you can exchange this as you like.

Every page is basicly a html page with a few lines of javascript for the redirection. You can edit them as you need.

If you got stock with an error during editing your landing pages you it is passobile to download the example again. Also you can always save the current state of your langind pages from the Hotspot service page. If you like to install a newer version of your custom langing pages please erase the installed version first. See 4.

How to set up a Backend server:

• Debian 8 installation
• CoovaChilli installation on Router (Hotspot image)
• Freeradius Version 2.2.5

sudo apt-get install freeradius freeradius-mysql

schema.sql

###########################################################################
# $Id: 70d8d07b56b44bf4129d7a512a5132ca67d6cd4c $                 #
#                                                                         #
#  schema.sql                       rlm_sql - FreeRADIUS SQL Module       #
#                                                                         #
#     DATABASE schema FOR MySQL rlm_sql module                            #
#                                                                         #
#     TO LOAD:                                                            #
#         mysql -uroot -prootpass radius < schema.sql                     #
#                                                                         #
#                                   Mike Machado <mike@innercite.com>     #
###########################################################################
#
# TABLE STRUCTURE FOR TABLE 'radacct'
#
 
CREATE TABLE radacct (
  radacctid BIGINT(21) NOT NULL AUTO_INCREMENT,
  acctsessionid VARCHAR(64) NOT NULL DEFAULT '',
  acctuniqueid VARCHAR(32) NOT NULL DEFAULT '',
  username VARCHAR(64) NOT NULL DEFAULT '',
  groupname VARCHAR(64) NOT NULL DEFAULT '',
  realm VARCHAR(64) DEFAULT '',
  nasipaddress VARCHAR(15) NOT NULL DEFAULT '',
  nasportid VARCHAR(50) DEFAULT NULL,
  nasporttype VARCHAR(32) DEFAULT NULL,
  acctstarttime datetime NULL DEFAULT NULL,
  acctupdatetime datetime NULL DEFAULT NULL,
  acctstoptime datetime NULL DEFAULT NULL,
  acctinterval INT(12) DEFAULT NULL,
  acctsessiontime INT(12) UNSIGNED DEFAULT NULL,
  acctauthentic VARCHAR(32) DEFAULT NULL,
  connectinfo_start VARCHAR(50) DEFAULT NULL,
  connectinfo_stop VARCHAR(50) DEFAULT NULL,
  acctinputoctets BIGINT(20) DEFAULT NULL,
  acctoutputoctets BIGINT(20) DEFAULT NULL,
  calledstationid VARCHAR(50) NOT NULL DEFAULT '',
  callingstationid VARCHAR(50) NOT NULL DEFAULT '',
  acctterminatecause VARCHAR(32) NOT NULL DEFAULT '',
  servicetype VARCHAR(32) DEFAULT NULL,
  framedprotocol VARCHAR(32) DEFAULT NULL,
  framedipaddress VARCHAR(15) NOT NULL DEFAULT '',
  acctstartdelay INT(12) UNSIGNED DEFAULT NULL,
  acctstopdelay INT(12) UNSIGNED DEFAULT NULL,
  xascendsessionsvrkey VARCHAR(10) DEFAULT NULL,
  PRIMARY KEY  (radacctid),
  UNIQUE KEY acctuniqueid (acctuniqueid),
  KEY username (username),
  KEY framedipaddress (framedipaddress),
  KEY acctsessionid (acctsessionid),
  KEY acctsessiontime (acctsessiontime),
  KEY acctstarttime (acctstarttime),
  KEY acctinterval (acctinterval),
  KEY acctstoptime (acctstoptime),
  KEY nasipaddress (nasipaddress)
) ENGINE = INNODB;
 
#
# TABLE STRUCTURE FOR TABLE 'radcheck'
#
 
CREATE TABLE radcheck (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  username VARCHAR(64) NOT NULL DEFAULT '',
  attribute VARCHAR(64)  NOT NULL DEFAULT '',
  op CHAR(2) NOT NULL DEFAULT '==',
  VALUE VARCHAR(253) NOT NULL DEFAULT '',
  PRIMARY KEY  (id),
  KEY username (username(32))
) ;
 
#
# TABLE STRUCTURE FOR TABLE 'radgroupcheck'
#
 
CREATE TABLE radgroupcheck (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  groupname VARCHAR(64) NOT NULL DEFAULT '',
  attribute VARCHAR(64)  NOT NULL DEFAULT '',
  op CHAR(2) NOT NULL DEFAULT '==',
  VALUE VARCHAR(253)  NOT NULL DEFAULT '',
  PRIMARY KEY  (id),
  KEY groupname (groupname(32))
) ;
 
#
# TABLE STRUCTURE FOR TABLE 'radgroupreply'
#
 
CREATE TABLE radgroupreply (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  groupname VARCHAR(64) NOT NULL DEFAULT '',
  attribute VARCHAR(64)  NOT NULL DEFAULT '',
  op CHAR(2) NOT NULL DEFAULT '=',
  VALUE VARCHAR(253)  NOT NULL DEFAULT '',
  PRIMARY KEY  (id),
  KEY groupname (groupname(32))
) ;
 
#
# TABLE STRUCTURE FOR TABLE 'radreply'
#
 
CREATE TABLE radreply (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  username VARCHAR(64) NOT NULL DEFAULT '',
  attribute VARCHAR(64) NOT NULL DEFAULT '',
  op CHAR(2) NOT NULL DEFAULT '=',
  VALUE VARCHAR(253) NOT NULL DEFAULT '',
  PRIMARY KEY  (id),
  KEY username (username(32))
) ;
 
 
#
# TABLE STRUCTURE FOR TABLE 'radusergroup'
#
 
CREATE TABLE radusergroup (
  username VARCHAR(64) NOT NULL DEFAULT '',
  groupname VARCHAR(64) NOT NULL DEFAULT '',
  priority INT(11) NOT NULL DEFAULT '1',
  KEY username (username(32))
) ;
 
#
# TABLE STRUCTURE FOR TABLE 'radpostauth'
#
 
CREATE TABLE radpostauth (
  id INT(11) NOT NULL AUTO_INCREMENT,
  username VARCHAR(64) NOT NULL DEFAULT '',
  pass VARCHAR(64) NOT NULL DEFAULT '',
  reply VARCHAR(32) NOT NULL DEFAULT '',
  authdate TIMESTAMP NOT NULL,
  PRIMARY KEY  (id)
) ENGINE = INNODB;
 
#
# TABLE STRUCTURE FOR TABLE 'nas'
#
CREATE TABLE nas (
  id INT(10) NOT NULL AUTO_INCREMENT,
  nasname VARCHAR(128) NOT NULL,
  shortname VARCHAR(32),
  TYPE VARCHAR(30) DEFAULT 'other',
  ports INT(5),
  secret VARCHAR(60) DEFAULT 'secret' NOT NULL,
  server VARCHAR(64),
  community VARCHAR(50),
  description VARCHAR(200) DEFAULT 'RADIUS Client',
  PRIMARY KEY (id),
  KEY nasname (nasname)
);

Create radius database mysqladmin -u root -p[MYSQL_ROOT_PASSWORD] create radius

Generate database tables using MySQL schema: sudo schema.sql | mysql -u root -p[MYSQL_ROOT_PASSWORD] radius

Create MySQL radius user and set privileges on radius database: mysql -u root -p[MYSQL_ROOT_PASSWORD] radius GRANT ALL PRIVILEGES ON radius.* to [FREERADIUS_DB_USER]@localhost IDENTIFIED by '[FREERADIUS_DB_PASS]';

Configure the SQL radius module:

sql.conf

# -*- text -*-
##
## sql.conf -- SQL modules
##
##	$Id: 6f346ec9f1d12190f132da20537f99607df71760 $
 
######################################################################
#
#  Configuration for the SQL module
#
#  The database schemas and queries are located in subdirectories:
#
#	sql/DB/schema.sql	Schema
#	sql/DB/dialup.conf	Basic dialup (including policy) queries
#	sql/DB/counter.conf	counter
#	sql/DB/ippool.conf	IP Pools in SQL
#	sql/DB/ippool.sql	schema for IP pools.
#
#  Where "DB" is mysql, mssql, oracle, or postgresql.
#
 
sql {
	#
	#  Set the database to one of:
	#
	#	mysql, mssql, oracle, postgresql
	#
	database = "mysql"
 
	#
	#  Which FreeRADIUS driver to use.
	#
	driver = "rlm_sql_${database}"
 
	# Connection info:
	server = "localhost"
	port = 3306
	login = "radius"
	password = "test12345678"
 
	# Database table configuration for everything except Oracle
	radius_db = "radius"
	# If you are using Oracle then use this instead
        # radius_db = "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=your_sid)))"
 
	# If you want both stop and start records logged to the
	# same SQL table, leave this as is.  If you want them in
	# different tables, put the start table in acct_table1
	# and stop table in acct_table2
	acct_table1 = "radacct"
	acct_table2 = "radacct"
 
	# Allow for storing data after authentication
	postauth_table = "radpostauth"
 
	authcheck_table = "radcheck"
	authreply_table = "radreply"
 
	groupcheck_table = "radgroupcheck"
	groupreply_table = "radgroupreply"
 
	# Table to keep group info
	usergroup_table = "radusergroup"
 
	# If set to 'yes' (default) we read the group tables
	# If set to 'no' the user MUST have Fall-Through = Yes in the radreply table
	# read_groups = yes
 
	# Remove stale session if checkrad does not see a double login
	deletestalesessions = yes
 
	# Print all SQL statements when in debug mode (-x)
	sqltrace = no
	sqltracefile = ${logdir}/sqltrace.sql
 
	# number of sql connections to make to server
	#
	# Setting this to LESS than the number of threads means
	# that some threads may starve, and you will see errors
	# like "No connections available and at max connection limit"
	#
	# Setting this to MORE than the number of threads means
	# that there are more connections than necessary.
	# 
	num_sql_socks = ${thread[pool].max_servers}
 
	# number of seconds to dely retrying on a failed database
	# connection (per_socket)
	connect_failure_retry_delay = 60
 
	# lifetime of an SQL socket.  If you are having network issues
	# such as TCP sessions expiring, you may need to set the socket
	# lifetime.  If set to non-zero, any open connections will be
	# closed "lifetime" seconds after they were first opened.
	lifetime = 0
 
	# Maximum number of queries used by an SQL socket.  If you are
	# having issues with SQL sockets lasting "too long", you can
	# limit the number of queries performed over one socket.  After
	# "max_qeuries", the socket will be closed.  Use 0 for "no limit".
	max_queries = 0
 
	# Set to 'yes' to read radius clients from the database ('nas' table)
	# Clients will ONLY be read on server startup.  For performance
	# and security reasons, finding clients via SQL queries CANNOT
	# be done "live" while the server is running.
	# 
	readclients = yes
 
	# Table to keep radius client info
	nas_table = "nas"
 
	# Read driver-specific configuration
	$INCLUDE sql/${database}/dialup.conf
}

Uncomment and or change the following parameters: databae = “mysql” server = “localhost” port = 3306 login = “FREERADIUS_DB_USER” password = “FREERADIUS_DB_PASS” readclients = yes

Add chillispot SQL counters:

counter.conf

# -*- text -*-
##
## counter.conf -- PostgreSQL queries for rlm_sqlcounter
##
##	$Id: a327819efb27c5342579ebb310aa47e9c4ade5d6 $
 
#  Rather than maintaining seperate (GDBM) DATABASES OF
#  accounting info FOR each counter, this module uses the DATA
#  stored IN the raddacct TABLE BY the SQL modules. This
#  module NEVER does any DATABASE INSERTs OR UPDATEs.  It IS
#  totally dependent ON the SQL module TO process Accounting
#  packets.
#
#  The 'sqlmod_inst' parameter holds the instance OF the SQL
#  module TO USE WHEN querying the SQL DATABASE. Normally it
#  IS just "sql".  IF you define more AND one SQL module
#  instance (usually FOR failover situations), you can
#  specify which module has access TO the Accounting DATA
#  (radacct TABLE).
#
#  The 'reset' parameter defines WHEN the counters are ALL
#  reset TO zero.  It can be hourly, daily, weekly, monthly OR
#  never.  It can also be USER defined. It should be OF the
#  form:
#  	num[hdwm] WHERE:
#  	h: hours, d: days, w: weeks, m: months
#  	IF the letter IS ommited days will be assumed. IN example:
#  	reset = 10h (reset every 10 hours)
#  	reset = 12  (reset every 12 days)
#
#  The 'key' parameter specifies the UNIQUE identifier FOR the
#  counter records (usually 'User-Name').
#
#  The 'query' parameter specifies the SQL query used TO GET
#  the CURRENT Counter VALUE FROM the DATABASE. There are 3
#  parameters that can be used IN the query:
#		%k	'key' parameter
#		%b	unix TIME VALUE OF beginning OF reset period
#		%e	unix TIME VALUE OF END OF reset period
#
#  The 'check-name' parameter IS the name OF the 'check'
#  attribute TO USE TO access the counter IN the 'users' file
#  OR SQL radcheck OR radcheckgroup TABLES.
#
#  DEFAULT  Max-Daily-SESSION > 3600, Auth-TYPE = Reject
#      Reply-Message = "You've used up more than one hour today"
#
sqlcounter dailycounter {
	counter-name = Daily-Session-TIME
	check-name = Max-Daily-SESSION
	reply-name = Session-Timeout
	sqlmod-inst = SQL
	KEY = User-Name
	reset = daily
 
	# This query properly handles calls that span FROM the
	# previous reset period INTO the CURRENT period but
	# involves more WORK FOR the SQL server than those
	# below
	query = "SELECT SUM(acctsessiontime - \
                 GREATEST((%b - UNIX_TIMESTAMP(acctstarttime)), 0)) \
                 FROM radacct WHERE username = '%{%k}' AND \
                 UNIX_TIMESTAMP(acctstarttime) + acctsessiontime > '%b'"
 
	# This query ignores calls that started IN a previous
	# reset period AND continue INTO INTO this one. But it
	# IS a little easier ON the SQL server
#	query = "SELECT SUM(acctsessiontime) FROM radacct WHERE \
#                username = '%{%k}' AND acctstarttime > FROM_UNIXTIME('%b')"
 
	# This query IS the same AS above, but demonstrates an
	# additional counter parameter '%e' which IS the
	# TIMESTAMP FOR the END OF the period
#	query = "SELECT SUM(acctsessiontime) FROM radacct \
#                WHERE username = '%{%k}' AND acctstarttime BETWEEN \
#                FROM_UNIXTIME('%b') AND FROM_UNIXTIME('%e')"
}
 
sqlcounter monthlycounter {
	counter-name = Monthly-Session-TIME
		check-name = Max-Monthly-SESSION
		reply-name = Session-Timeout
		sqlmod-inst = SQL
		KEY = User-Name
		reset = monthly
 
	# This query properly handles calls that span FROM the
	# previous reset period INTO the CURRENT period but
	# involves more WORK FOR the SQL server than those
	# below
	query = "SELECT SUM(acctsessiontime - \
                 GREATEST((%b - UNIX_TIMESTAMP(acctstarttime)), 0)) \
                 FROM radacct WHERE username='%{%k}' AND \
                 UNIX_TIMESTAMP(acctstarttime) + acctsessiontime > '%b'"
 
	# This query ignores calls that started IN a previous
	# reset period AND continue INTO INTO this one. But it
	# IS a little easier ON the SQL server
#	query = "SELECT SUM(acctsessiontime) FROM radacct WHERE \
#                username='%{%k}' AND acctstarttime > FROM_UNIXTIME('%b')"
 
	# This query IS the same AS above, but demonstrates an
	# additional counter parameter '%e' which IS the
	# TIMESTAMP FOR the END OF the period
#	query = "SELECT SUM(acctsessiontime) FROM radacct \
#                WHERE username='%{%k}' AND acctstarttime BETWEEN \
#                FROM_UNIXTIME('%b') AND FROM_UNIXTIME('%e')"
}
 
sqlcounter noresetcounter {
        counter-name = Max-All-Session-TIME 
                check-name = Max-All-SESSION 
                sqlmod-inst = SQL 
                KEY = User-Name 
                reset = never 
        query = "SELECT IFNULL(SUM(AcctSessionTime),0) FROM radacct WHERE UserName='%{%k}'" 
}
 
sqlcounter chillispot_max_bytes {
    counter-name = Max-Total-Octets
    check-name = ChilliSpot-Max-Total-Octets
    reply-name = ChilliSpot-Max-Total-Octets
    reply-message = "You have reached your bandwidth limit"
    sqlmod-inst = SQL
    KEY = User-Name
    reset = never
    query = "SELECT IFNULL((SUM(AcctInputOctets + AcctOutputOctets)),0) FROM radacct WHERE username = '%{${key}}' AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%%b'"
}

sudo vi /etc/freeradius/sql/mysql/counter.conf

Add this lines at the end of the above file:

sqlcounter chillispot_max_bytes {
    counter-name = Max-Total-Octets
    check-name = ChilliSpot-Max-Total-Octets
    reply-name = ChilliSpot-Max-Total-Octets
    reply-message = "You have reached your bandwidth limit"
    sqlmod-inst = sql
    key = User-Name
    reset = never
    query = "SELECT IFNULL((SUM(AcctInputOctets + AcctOutputOctets)),0) FROM radacct WHERE username = '%{${key}}' AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%%b'"
}

clients.conf

# -*- text -*-
##
## clients.conf -- client configuration directives
##
##	$Id: 729c15d3e84c6cdb54a5f3652d93a2d7f8725fd4 $
 
#######################################################################
#
#  Define RADIUS clients (usually a NAS, Access Point, etc.).
 
#
#  Defines a RADIUS client.
#
#  '127.0.0.1' is another name for 'localhost'.  It is enabled by default,
#  to allow testing of the server after an initial installation.  If you
#  are not going to be permitting RADIUS queries from localhost, we suggest
#  that you delete, or comment out, this entry.
#
#
 
#
#  Each client has a "short name" that is used to distinguish it from
#  other clients.
#
#  In version 1.x, the string after the word "client" was the IP
#  address of the client.  In 2.0, the IP address is configured via
#  the "ipaddr" or "ipv6addr" fields.  For compatibility, the 1.x
#  format is still accepted.
#
client localhost {
	#  Allowed values are:
	#	dotted quad (1.2.3.4)
	#       hostname    (radius.example.com)
	ipaddr = 127.0.0.1
 
	#  OR, you can use an IPv6 address, but not both
	#  at the same time.
#	ipv6addr = ::	# any.  ::1 == localhost
 
	#
	#  A note on DNS:  We STRONGLY recommend using IP addresses
	#  rather than host names.  Using host names means that the
	#  server will do DNS lookups when it starts, making it
	#  dependent on DNS.  i.e. If anything goes wrong with DNS,
	#  the server won't start!
	#
	#  The server also looks up the IP address from DNS once, and
	#  only once, when it starts.  If the DNS record is later
	#  updated, the server WILL NOT see that update.
	#
 
	#  One client definition can be applied to an entire network.
	#  e.g. 127/8 should be defined with "ipaddr = 127.0.0.0" and
	#  "netmask = 8"
	#
	#  If not specified, the default netmask is 32 (i.e. /32)
	#
	#  We do NOT recommend using anything other than 32.  There
	#  are usually other, better ways to achieve the same goal.
	#  Using netmasks of other than 32 can cause security issues.
	#
	#  You can specify overlapping networks (127/8 and 127.0/16)
	#  In that case, the smallest possible network will be used
	#  as the "best match" for the client.
	#
	#  Clients can also be defined dynamically at run time, based
	#  on any criteria.  e.g. SQL lookups, keying off of NAS-Identifier,
	#  etc.
	#  See raddb/sites-available/dynamic-clients for details.
	#
 
#	netmask = 32
 
	#
	#  The shared secret use to "encrypt" and "sign" packets between
	#  the NAS and FreeRADIUS.  You MUST change this secret from the
	#  default, otherwise it's not a secret any more!
	#
	#  The secret can be any string, up to 8k characters in length.
	#
	#  Control codes can be entered vi octal encoding,
	#	e.g. "\101\102" == "AB"
	#  Quotation marks can be entered by escaping them,
	#	e.g. "foo\"bar"
	#
	#  A note on security:  The security of the RADIUS protocol
	#  depends COMPLETELY on this secret!  We recommend using a
	#  shared secret that is composed of:
	#
	#	upper case letters
	#	lower case letters
	#	numbers
	#
	#  And is at LEAST 8 characters long, preferably 16 characters in
	#  length.  The secret MUST be random, and should not be words,
	#  phrase, or anything else that is recognizable.
	#
	#  The default secret below is only for testing, and should
	#  not be used in any real environment.
	#
	secret		= test12345678
 
	#
	#  Old-style clients do not send a Message-Authenticator
	#  in an Access-Request.  RFC 5080 suggests that all clients
	#  SHOULD include it in an Access-Request.  The configuration
	#  item below allows the server to require it.  If a client
	#  is required to include a Message-Authenticator and it does
	#  not, then the packet will be silently discarded.
	#
	#  allowed values: yes, no
	require_message_authenticator = no
 
	#
	#  The short name is used as an alias for the fully qualified
	#  domain name, or the IP address.
	#
	#  It is accepted for compatibility with 1.x, but it is no
	#  longer necessary in 2.0
	#
#	shortname	= localhost
 
	#
	# the following three fields are optional, but may be used by
	# checkrad.pl for simultaneous use checks
	#
 
	#
	# The nastype tells 'checkrad.pl' which NAS-specific method to
	#  use to query the NAS for simultaneous use.
	#
	#  Permitted NAS types are:
	#
	#	cisco
	#	computone
	#	livingston
	#	juniper
	#	max40xx
	#	multitech
	#	netserver
	#	pathras
	#	patton
	#	portslave
	#	tc
	#	usrhiper
	#	other		# for all other types
 
	#
	nastype     = other	# localhost isn't usually a NAS...
 
	#
	#  The following two configurations are for future use.
	#  The 'naspasswd' file is currently used to store the NAS
	#  login name and password, which is used by checkrad.pl
	#  when querying the NAS for simultaneous use.
	#
#	login       = !root
#	password    = someadminpas
 
	#
	#  As of 2.0, clients can also be tied to a virtual server.
	#  This is done by setting the "virtual_server" configuration
	#  item, as in the example below.
	#
#	virtual_server = home1
 
	#
	#  A pointer to the "home_server_pool" OR a "home_server"
	#  section that contains the CoA configuration for this
	#  client.  For an example of a coa home server or pool,
	#  see raddb/sites-available/originate-coa
#	coa_server = coa
}
 
# IPv6 Client
#client ::1 {
#	secret		= testing123
#	shortname	= localhost
#}
#
# All IPv6 Site-local clients
#client fe80::/16 {
#	secret		= testing123
#	shortname	= localhost
#}
 
#client some.host.org {
#	secret		= testing123
#	shortname	= localhost
#}
 
#
#  You can now specify one secret for a network of clients.
#  When a client request comes in, the BEST match is chosen.
#  i.e. The entry from the smallest possible network.
#
#client 192.168.0.0/24 {
#	secret		= testing123-1
#	shortname	= private-network-1
#}
#
#client 192.168.0.0/16 {
#	secret		= testing123-2
#	shortname	= private-network-2
#}
 
 
#client 10.10.10.10 {
#	# secret and password are mapped through the "secrets" file.
#	secret      = testing123
#	shortname   = liv1
#       # the following three fields are optional, but may be used by
#       # checkrad.pl for simultaneous usage checks
#	nastype     = livingston
#	login       = !root
#	password    = someadminpas
#}
 
#######################################################################
#
#  Per-socket client lists.  The configuration entries are exactly
#  the same as above, but they are nested inside of a section.
#
#  You can have as many per-socket client lists as you have "listen"
#  sections, or you can re-use a list among multiple "listen" sections.
#
#  Un-comment this section, and edit a "listen" section to add:
#  "clients = per_socket_clients".  That IP address/port combination
#  will then accept ONLY the clients listed in this section.
#
#clients per_socket_clients {
#	client 192.168.3.4 {
#		secret = testing123
#        }
#}
 
client 192.168.1.0/24 {
	secret		= [SECRET]
        nastype     = other
}

Change the password to the password used above for FreeRadius MySQL database: secret = [FREERADIUS_DB_PASS]

or create new client:

# example for clients with net address 192.168.1.0/24
client 192.168.1.0/24 {
        secret          =  [FREERADIUS_DB_PASS]
        nastype         = other
}

Configure radius server:

radiusd.conf

# -*- text -*-
##
## radiusd.conf	-- FreeRADIUS server configuration file.
##
##	http://www.freeradius.org/
##	$Id: 201b70b31b5bb4c2ef98c102690daa3462d5e1e3 $
##
 
######################################################################
#
#	Read "man radiusd" before editing this file.  See the section
#	titled DEBUGGING.  It outlines a method where you can quickly
#	obtain the configuration you want, without running into
#	trouble.
#
#	Run the server in debugging mode, and READ the output.
#
#		$ radiusd -X
#
#	We cannot emphasize this point strongly enough.  The vast
#	majority of problems can be solved by carefully reading the
#	debugging output, which includes warnings about common issues,
#	and suggestions for how they may be fixed.
#
#	There may be a lot of output, but look carefully for words like:
#	"warning", "error", "reject", or "failure".  The messages there
#	will usually be enough to guide you to a solution.
#
#	If you are going to ask a question on the mailing list, then
#	explain what you are trying to do, and include the output from
#	debugging mode (radiusd -X).  Failure to do so means that all
#	of the responses to your question will be people telling you
#	to "post the output of radiusd -X".
 
######################################################################
#
#  	The location of other config files and logfiles are declared
#  	in this file.
#
#  	Also general configuration for modules can be done in this
#  	file, it is exported through the API to modules that ask for
#  	it.
#
#	See "man radiusd.conf" for documentation on the format of this
#	file.  Note that the individual configuration items are NOT
#	documented in that "man" page.  They are only documented here,
#	in the comments.
#
#	As of 2.0.0, FreeRADIUS supports a simple processing language
#	in the "authorize", "authenticate", "accounting", etc. sections.
#	See "man unlang" for details.
#
 
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius
radacctdir = ${logdir}/radacct
 
#
#  name of the running server.  See also the "-n" command-line option.
name = freeradius
 
#  Location of config and logfiles.
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/${name}
 
# Should likely be ${localstatedir}/lib/radiusd
db_dir = ${raddbdir}
 
#
# libdir: Where to find the rlm_* modules.
#
#   This should be automatically set at configuration time.
#
#   If the server builds and installs, but fails at execution time
#   with an 'undefined symbol' error, then you can use the libdir
#   directive to work around the problem.
#
#   The cause is usually that a library has been installed on your
#   system in a place where the dynamic linker CANNOT find it.  When
#   executing as root (or another user), your personal environment MAY
#   be set up to allow the dynamic linker to find the library.  When
#   executing as a daemon, FreeRADIUS MAY NOT have the same
#   personalized configuration.
#
#   To work around the problem, find out which library contains that symbol,
#   and add the directory containing that library to the end of 'libdir',
#   with a colon separating the directory names.  NO spaces are allowed.
#
#   e.g. libdir = /usr/local/lib:/opt/package/lib
#
#   You can also try setting the LD_LIBRARY_PATH environment variable
#   in a script which starts the server.
#
#   If that does not work, then you can re-configure and re-build the
#   server to NOT use shared libraries, via:
#
#	./configure --disable-shared
#	make
#	make install
#
libdir = /usr/lib/freeradius
 
#  pidfile: Where to place the PID of the RADIUS server.
#
#  The server may be signalled while it's running by using this
#  file.
#
#  This file is written when ONLY running in daemon mode.
#
#  e.g.:  kill -HUP `cat /var/run/radiusd/radiusd.pid`
#
pidfile = ${run_dir}/${name}.pid
 
#  chroot: directory where the server does "chroot".
#
#  The chroot is done very early in the process of starting the server.
#  After the chroot has been performed it switches to the "user" listed
#  below (which MUST be specified).  If "group" is specified, it switchs
#  to that group, too.  Any other groups listed for the specified "user"
#  in "/etc/group" are also added as part of this process.
#
#  The current working directory (chdir / cd) is left *outside* of the
#  chroot until all of the modules have been initialized.  This allows
#  the "raddb" directory to be left outside of the chroot.  Once the
#  modules have been initialized, it does a "chdir" to ${logdir}.  This
#  means that it should be impossible to break out of the chroot.
#
#  If you are worried about security issues related to this use of chdir,
#  then simply ensure that the "raddb" directory is inside of the chroot,
#  end be sure to do "cd raddb" BEFORE starting the server.
#
#  If the server is statically linked, then the only files that have
#  to exist in the chroot are ${run_dir} and ${logdir}.  If you do the
#  "cd raddb" as discussed above, then the "raddb" directory has to be
#  inside of the chroot directory, too.
#
#chroot = /path/to/chroot/directory
 
# user/group: The name (or #number) of the user/group to run radiusd as.
#
#   If these are commented out, the server will run as the user/group
#   that started it.  In order to change to a different user/group, you
#   MUST be root ( or have root privleges ) to start the server.
#
#   We STRONGLY recommend that you run the server with as few permissions
#   as possible.  That is, if you're not using shadow passwords, the
#   user and group items below should be set to radius'.
#
#  NOTE that some kernels refuse to setgid(group) when the value of
#  (unsigned)group is above 60000; don't use group nobody on these systems!
#
#  On systems with shadow passwords, you might have to set 'group = shadow'
#  for the server to be able to read the shadow password file.  If you can
#  authenticate users while in debug mode, but not in daemon mode, it may be
#  that the debugging mode server is running as a user that can read the
#  shadow info, and the user listed below can not.
#
#  The server will also try to use "initgroups" to read /etc/groups.
#  It will join all groups where "user" is a member.  This can allow
#  for some finer-grained access controls.
#
user = radiusd
group = radiusd
 
#  panic_action: Command to execute if the server dies unexpectedly.
#
#  FOR PRODUCTION SYSTEMS, ACTIONS SHOULD ALWAYS EXIT.
#  AN INTERACTIVE ACTION MEANS THE SERVER IS NOT RESPONDING TO REQUESTS.
#  AN INTERACTICE ACTION MEANS THE SERVER WILL NOT RESTART.
#
#  The panic action is a command which will be executed if the server
#  receives a fatal, non user generated signal, i.e. SIGSEGV, SIGBUS,
#  SIGABRT or SIGFPE.
#
#  This can be used to start an interactive debugging session so
#  that information regarding the current state of the server can
#  be acquired.
#
#  The following string substitutions are available:
#  - %e   The currently executing program e.g. /sbin/radiusd
#  - %p   The PID of the currently executing program e.g. 12345
#
#  Standard ${} substitutions are also allowed.
#
#  An example panic action for opening an interactive session in GDB would be:
#
#panic_action = "gdb %e %p"
#
#  Again, don't use that on a production system.
#
#  An example panic action for opening an automated session in GDB would be:
#
#panic_action = "gdb -silent -x ${raddbdir}/panic.gdb %e %p > ${logdir}/gdb-%e-%p.log 2>&1"
#
#  That command can be used on a production system.
#
 
#  max_request_time: The maximum time (in seconds) to handle a request.
#
#  Requests which take more time than this to process may be killed, and
#  a REJECT message is returned.
#
#  WARNING: If you notice that requests take a long time to be handled,
#  then this MAY INDICATE a bug in the server, in one of the modules
#  used to handle a request, OR in your local configuration.
#
#  This problem is most often seen when using an SQL database.  If it takes
#  more than a second or two to receive an answer from the SQL database,
#  then it probably means that you haven't indexed the database.  See your
#  SQL server documentation for more information.
#
#  Useful range of values: 5 to 120
#
max_request_time = 30
 
#  cleanup_delay: The time to wait (in seconds) before cleaning up
#  a reply which was sent to the NAS.
#
#  The RADIUS request is normally cached internally for a short period
#  of time, after the reply is sent to the NAS.  The reply packet may be
#  lost in the network, and the NAS will not see it.  The NAS will then
#  re-send the request, and the server will respond quickly with the
#  cached reply.
#
#  If this value is set too low, then duplicate requests from the NAS
#  MAY NOT be detected, and will instead be handled as seperate requests.
#
#  If this value is set too high, then the server will cache too many
#  requests, and some new requests may get blocked.  (See 'max_requests'.)
#
#  Useful range of values: 2 to 10
#
cleanup_delay = 5
 
#  max_requests: The maximum number of requests which the server keeps
#  track of.  This should be 256 multiplied by the number of clients.
#  e.g. With 4 clients, this number should be 1024.
#
#  If this number is too low, then when the server becomes busy,
#  it will not respond to any new requests, until the 'cleanup_delay'
#  time has passed, and it has removed the old requests.
#
#  If this number is set too high, then the server will use a bit more
#  memory for no real benefit.
#
#  If you aren't sure what it should be set to, it's better to set it
#  too high than too low.  Setting it to 1000 per client is probably
#  the highest it should be.
#
#  Useful range of values: 256 to infinity
#
max_requests = 1024
 
#  listen: Make the server listen on a particular IP address, and send
#  replies out from that address. This directive is most useful for
#  hosts with multiple IP addresses on one interface.
#
#  If you want the server to listen on additional addresses, or on
#  additionnal ports, you can use multiple "listen" sections.
#
#  Each section make the server listen for only one type of packet,
#  therefore authentication and accounting have to be configured in
#  different sections.
#
#  The server ignore all "listen" section if you are using '-i' and '-p'
#  on the command line.
#
listen {
	#  Type of packets to listen for.
	#  Allowed values are:
	#	auth	listen for authentication packets
	#	acct	listen for accounting packets
	#	proxy   IP to use for sending proxied packets
	#	detail  Read from the detail file.  For examples, see
	#               raddb/sites-available/copy-acct-to-home-server
	#	status  listen for Status-Server packets.  For examples,
	#		see raddb/sites-available/status
	#	coa     listen for CoA-Request and Disconnect-Request
	#		packets.  For examples, see the file
	#		raddb/sites-available/coa
	#
	type = auth
 
	#  Note: "type = proxy" lets you control the source IP used for
	#        proxying packets, with some limitations:
	#
	#    * A proxy listener CANNOT be used in a virtual server section.
	#    * You should probably set "port = 0".
	#    * Any "clients" configuration will be ignored.
	#
	#  See also proxy.conf, and the "src_ipaddr" configuration entry
	#  in the sample "home_server" section.  When you specify the
	#  source IP address for packets sent to a home server, the
	#  proxy listeners are automatically created.
 
	#  IP address on which to listen.
	#  Allowed values are:
	#	dotted quad (1.2.3.4)
	#       hostname    (radius.example.com)
	#       wildcard    (*)
	ipaddr = *
 
	#  OR, you can use an IPv6 address, but not both
	#  at the same time.
#	ipv6addr = ::	# any.  ::1 == localhost
 
	#  Port on which to listen.
	#  Allowed values are:
	#	integer port number (1812)
	#	0 means "use /etc/services for the proper port"
	port = 0
 
	#  Some systems support binding to an interface, in addition
	#  to the IP address.  This feature isn't strictly necessary,
	#  but for sites with many IP addresses on one interface,
	#  it's useful to say "listen on all addresses for eth0".
	#
	#  If your system does not support this feature, you will
	#  get an error if you try to use it.
	#
#	interface = eth0
 
	#  Per-socket lists of clients.  This is a very useful feature.
	#
	#  The name here is a reference to a section elsewhere in
	#  radiusd.conf, or clients.conf.  Having the name as
	#  a reference allows multiple sockets to use the same
	#  set of clients.
	#
	#  If this configuration is used, then the global list of clients
	#  is IGNORED for this "listen" section.  Take care configuring
	#  this feature, to ensure you don't accidentally disable a
	#  client you need.
	#
	#  See clients.conf for the configuration of "per_socket_clients".
	#
#	clients = per_socket_clients
}
 
#  This second "listen" section is for listening on the accounting
#  port, too.
#
listen {
	ipaddr = *
#	ipv6addr = ::
	port = 0
	type = acct
#	interface = eth0
#	clients = per_socket_clients
}
 
#  hostname_lookups: Log the names of clients or just their IP addresses
#  e.g., www.freeradius.org (on) or 206.47.27.232 (off).
#
#  The default is 'off' because it would be overall better for the net
#  if people had to knowingly turn this feature on, since enabling it
#  means that each client request will result in AT LEAST one lookup
#  request to the nameserver.   Enabling hostname_lookups will also
#  mean that your server may stop randomly for 30 seconds from time
#  to time, if the DNS requests take too long.
#
#  Turning hostname lookups off also means that the server won't block
#  for 30 seconds, if it sees an IP address which has no name associated
#  with it.
#
#  allowed values: {no, yes}
#
hostname_lookups = no
 
#  Core dumps are a bad thing.  This should only be set to 'yes'
#  if you're debugging a problem with the server.
#
#  allowed values: {no, yes}
#
allow_core_dumps = no
 
#  Regular expressions
#
#  These items are set at configure time.  If they're set to "yes",
#  then setting them to "no" turns off regular expression support.
#
#  If they're set to "no" at configure time, then setting them to "yes"
#  WILL NOT WORK.  It will give you an error.
#
regular_expressions	= yes
extended_expressions	= yes
 
#
#  Logging section.  The various "log_*" configuration items
#  will eventually be moved here.
#
log {
	#
	#  Destination for log messages.  This can be one of:
	#
	#	files - log to "file", as defined below.
	#	syslog - to syslog (see also the "syslog_facility", below.
	#	stdout - standard output
	#	stderr - standard error.
	#
	#  The command-line option "-X" over-rides this option, and forces
	#  logging to go to stdout.
	#
	destination = files
 
	#
	#  The logging messages for the server are appended to the
	#  tail of this file if destination == "files"
	#
	#  If the server is running in debugging mode, this file is
	#  NOT used.
	#
	file = ${logdir}/radius.log
 
	#
	#  If this configuration parameter is set, then log messages for
	#  a *request* go to this file, rather than to radius.log.
	#
	#  i.e. This is a log file per request, once the server has accepted
	#  the request as being from a valid client.  Messages that are
	#  not associated with a request still go to radius.log.
	#
	#  Not all log messages in the server core have been updated to use
	#  this new internal API.  As a result, some messages will still
	#  go to radius.log.  Please submit patches to fix this behavior.
	#
	#  The file name is expanded dynamically.  You should ONLY user
	#  server-side attributes for the filename (e.g. things you control).
	#  Using this feature MAY also slow down the server substantially,
	#  especially if you do thinks like SQL calls as part of the
	#  expansion of the filename.
	#
	#  The name of the log file should use attributes that don't change
	#  over the lifetime of a request, such as User-Name,
	#  Virtual-Server or Packet-Src-IP-Address.  Otherwise, the log
	#  messages will be distributed over multiple files.
	#
	#  Logging can be enabled for an individual request by a special
	#  dynamic expansion macro:  %{debug: 1}, where the debug level
	#  for this request is set to '1' (or 2, 3, etc.).  e.g.
	#
	#	...
	#	update control {
	#	       Tmp-String-0 = "%{debug:1}"
	#	}
	#	...
	#
	#  The attribute that the value is assigned to is unimportant,
	#  and should be a "throw-away" attribute with no side effects.
	#
	#requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log
 
	#
	#  Which syslog facility to use, if ${destination} == "syslog"
	#
	#  The exact values permitted here are OS-dependent.  You probably
	#  don't want to change this.
	#
	syslog_facility = daemon
 
	#  Log the full User-Name attribute, as it was found in the request.
	#
	# allowed values: {no, yes}
	#
	stripped_names = no
 
	#  Log authentication requests to the log file.
	#
	#  allowed values: {no, yes}
	#
	auth = no
 
	#  Log passwords with the authentication requests.
	#  auth_badpass  - logs password if it's rejected
	#  auth_goodpass - logs password if it's correct
	#
	#  allowed values: {no, yes}
	#
	auth_badpass = no
	auth_goodpass = no
 
	#  Log additional text at the end of the "Login OK" messages.
	#  for these to work, the "auth" and "auth_goopass" or "auth_badpass"
	#  configurations above have to be set to "yes".
	#
	#  The strings below are dynamically expanded, which means that
	#  you can put anything you want in them.  However, note that
	#  this expansion can be slow, and can negatively impact server
	#  performance.
	#
#	msg_goodpass = ""
#	msg_badpass = ""
}
 
#  The program to execute to do concurrency checks.
checkrad = ${sbindir}/checkrad
 
# SECURITY CONFIGURATION
#
#  There may be multiple methods of attacking on the server.  This
#  section holds the configuration items which minimize the impact
#  of those attacks
#
security {
	#
	#  max_attributes: The maximum number of attributes
	#  permitted in a RADIUS packet.  Packets which have MORE
	#  than this number of attributes in them will be dropped.
	#
	#  If this number is set too low, then no RADIUS packets
	#  will be accepted.
	#
	#  If this number is set too high, then an attacker may be
	#  able to send a small number of packets which will cause
	#  the server to use all available memory on the machine.
	#
	#  Setting this number to 0 means "allow any number of attributes"
	max_attributes = 200
 
	#
	#  reject_delay: When sending an Access-Reject, it can be
	#  delayed for a few seconds.  This may help slow down a DoS
	#  attack.  It also helps to slow down people trying to brute-force
	#  crack a users password.
	#
	#  Setting this number to 0 means "send rejects immediately"
	#
	#  If this number is set higher than 'cleanup_delay', then the
	#  rejects will be sent at 'cleanup_delay' time, when the request
	#  is deleted from the internal cache of requests.
	#
	#  Useful ranges: 1 to 5
	reject_delay = 1
 
	#
	#  status_server: Whether or not the server will respond
	#  to Status-Server requests.
	#
	#  When sent a Status-Server message, the server responds with
	#  an Access-Accept or Accounting-Response packet.
	#
	#  This is mainly useful for administrators who want to "ping"
	#  the server, without adding test users, or creating fake
	#  accounting packets.
	#
	#  It's also useful when a NAS marks a RADIUS server "dead".
	#  The NAS can periodically "ping" the server with a Status-Server
	#  packet.  If the server responds, it must be alive, and the
	#  NAS can start using it for real requests.
	#
	#  See also raddb/sites-available/status
	#
	status_server = yes
 
	#
	#  allow_vulnerable_openssl: Allow the server to start with
	#  versions of OpenSSL known to have critical vulnerabilities.
	#
	#  This check is based on the version number reported by libssl
	#  and may not reflect patches applied to libssl by
	#  distribution maintainers.
	#
	allow_vulnerable_openssl = yes
}
 
# PROXY CONFIGURATION
#
#  proxy_requests: Turns proxying of RADIUS requests on or off.
#
#  The server has proxying turned on by default.  If your system is NOT
#  set up to proxy requests to another server, then you can turn proxying
#  off here.  This will save a small amount of resources on the server.
#
#  If you have proxying turned off, and your configuration files say
#  to proxy a request, then an error message will be logged.
#
#  To disable proxying, change the "yes" to "no", and comment the
#  $INCLUDE line.
#
#  allowed values: {no, yes}
#
proxy_requests  = yes
$INCLUDE proxy.conf
 
 
# CLIENTS CONFIGURATION
#
#  Client configuration is defined in "clients.conf".
#
 
#  The 'clients.conf' file contains all of the information from the old
#  'clients' and 'naslist' configuration files.  We recommend that you
#  do NOT use 'client's or 'naslist', although they are still
#  supported.
#
#  Anything listed in 'clients.conf' will take precedence over the
#  information from the old-style configuration files.
#
 $INCLUDE clients.conf
 
 
# THREAD POOL CONFIGURATION
#
#  The thread pool is a long-lived group of threads which
#  take turns (round-robin) handling any incoming requests.
#
#  You probably want to have a few spare threads around,
#  so that high-load situations can be handled immediately.  If you
#  don't have any spare threads, then the request handling will
#  be delayed while a new thread is created, and added to the pool.
#
#  You probably don't want too many spare threads around,
#  otherwise they'll be sitting there taking up resources, and
#  not doing anything productive.
#
#  The numbers given below should be adequate for most situations.
#
thread pool {
	#  Number of servers to start initially --- should be a reasonable
	#  ballpark figure.
	start_servers = 5
 
	#  Limit on the total number of servers running.
	#
	#  If this limit is ever reached, clients will be LOCKED OUT, so it
	#  should NOT BE SET TOO LOW.  It is intended mainly as a brake to
	#  keep a runaway server from taking the system with it as it spirals
	#  down...
	#
	#  You may find that the server is regularly reaching the
	#  'max_servers' number of threads, and that increasing
	#  'max_servers' doesn't seem to make much difference.
	#
	#  If this is the case, then the problem is MOST LIKELY that
	#  your back-end databases are taking too long to respond, and
	#  are preventing the server from responding in a timely manner.
	#
	#  The solution is NOT do keep increasing the 'max_servers'
	#  value, but instead to fix the underlying cause of the
	#  problem: slow database, or 'hostname_lookups=yes'.
	#
	#  For more information, see 'max_request_time', above.
	#
	max_servers = 32
 
	#  Server-pool size regulation.  Rather than making you guess
	#  how many servers you need, FreeRADIUS dynamically adapts to
	#  the load it sees, that is, it tries to maintain enough
	#  servers to handle the current load, plus a few spare
	#  servers to handle transient load spikes.
	#
	#  It does this by periodically checking how many servers are
	#  waiting for a request.  If there are fewer than
	#  min_spare_servers, it creates a new spare.  If there are
	#  more than max_spare_servers, some of the spares die off.
	#  The default values are probably OK for most sites.
	#
	min_spare_servers = 3
	max_spare_servers = 10
 
	#  When the server receives a packet, it places it onto an
	#  internal queue, where the worker threads (configured above)
	#  pick it up for processing.  The maximum size of that queue
	#  is given here.
	#
	#  When the queue is full, any new packets will be silently
	#  discarded.
	#
	#  The most common cause of the queue being full is that the
	#  server is dependent on a slow database, and it has received
	#  a large "spike" of traffic.  When that happens, there is
	#  very little you can do other than make sure the server
	#  receives less traffic, or make sure that the database can
	#  handle the load.
	#
#	max_queue_size = 65536
 
	#  There may be memory leaks or resource allocation problems with
	#  the server.  If so, set this value to 300 or so, so that the
	#  resources will be cleaned up periodically.
	#
	#  This should only be necessary if there are serious bugs in the
	#  server which have not yet been fixed.
	#
	#  '0' is a special value meaning 'infinity', or 'the servers never
	#  exit'
	max_requests_per_server = 0
}
 
# MODULE CONFIGURATION
#
#  The names and configuration of each module is located in this section.
#
#  After the modules are defined here, they may be referred to by name,
#  in other sections of this configuration file.
#
modules {
	#
	#  Each module has a configuration as follows:
	#
	#	name [ instance ] {
	#		config_item = value
	#		...
	#	}
	#
	#  The 'name' is used to load the 'rlm_name' library
	#  which implements the functionality of the module.
	#
	#  The 'instance' is optional.  To have two different instances
	#  of a module, it first must be referred to by 'name'.
	#  The different copies of the module are then created by
	#  inventing two 'instance' names, e.g. 'instance1' and 'instance2'
	#
	#  The instance names can then be used in later configuration
	#  INSTEAD of the original 'name'.  See the 'radutmp' configuration
	#  for an example.
	#
 
	#
	#  As of 2.0.5, most of the module configurations are in a
	#  sub-directory.  Files matching the regex /[a-zA-Z0-9_.]+/
	#  are loaded.  The modules are initialized ONLY if they are
	#  referenced in a processing section, such as authorize,
	#  authenticate, accounting, pre/post-proxy, etc.
	#
	$INCLUDE ${confdir}/modules/
 
	#  Extensible Authentication Protocol
	#
	#  For all EAP related authentications.
	#  Now in another file, because it is very large.
	#
	$INCLUDE eap.conf
 
	#  Include another file that has the SQL-related configuration.
	#  This is another file only because it tends to be big.
	#
	$INCLUDE sql.conf
 
	#
	#  This module is an SQL enabled version of the counter module.
	#
	#  Rather than maintaining seperate (GDBM) databases of
	#  accounting info for each counter, this module uses the data
	#  stored in the raddacct table by the sql modules. This
	#  module NEVER does any database INSERTs or UPDATEs.  It is
	#  totally dependent on the SQL module to process Accounting
	#  packets.
	#
	$INCLUDE sql/mysql/counter.conf
 
	#
	#  IP addresses managed in an SQL table.
	#
#	$INCLUDE sqlippool.conf
}
 
# Instantiation
#
#  This section orders the loading of the modules.  Modules
#  listed here will get loaded BEFORE the later sections like
#  authorize, authenticate, etc. get examined.
#
#  This section is not strictly needed.  When a section like
#  authorize refers to a module, it's automatically loaded and
#  initialized.  However, some modules may not be listed in any
#  of the following sections, so they can be listed here.
#
#  Also, listing modules here ensures that you have control over
#  the order in which they are initalized.  If one module needs
#  something defined by another module, you can list them in order
#  here, and ensure that the configuration will be OK.
#
instantiate {
	#
	#  Allows the execution of external scripts.
	#  The entire command line (and output) must fit into 253 bytes.
	#
	#  e.g. Framed-Pool = `%{exec:/bin/echo foo}`
	exec
 
	#
	#  The expression module doesn't do authorization,
	#  authentication, or accounting.  It only does dynamic
	#  translation, of the form:
	#
	#	Session-Timeout = `%{expr:2 + 3}`
	#
	#  This module needs to be instantiated, but CANNOT be
	#  listed in any other section.  See 'doc/rlm_expr' for
	#  more information.
	#
	#  rlm_expr is also responsible for registering many
	#  other xlat functions such as md5, sha1 and lc.
	#
	#  We do not recommend removing it's listing here.
	expr
 
	#
	# We add the counter module here so that it registers
	# the check-name attribute before any module which sets
	# it
#	daily
	expiration
	logintime
 
	# subsections here can be thought of as "virtual" modules.
	#
	# e.g. If you have two redundant SQL servers, and you want to
	# use them in the authorize and accounting sections, you could
	# place a "redundant" block in each section, containing the
	# exact same text.  Or, you could uncomment the following
	# lines, and list "redundant_sql" in the authorize and
	# accounting sections.
	#
	#redundant redundant_sql {
	#	sql1
	#	sql2
	#}
        chillispot_max_bytes
        noresetcounter
}
 
######################################################################
#
#	Policies that can be applied in multiple places are listed
#	globally.  That way, they can be defined once, and referred
#	to multiple times.
#
######################################################################
$INCLUDE policy.conf
 
######################################################################
#
#	Load virtual servers.
#
#	This next $INCLUDE line loads files in the directory that
#	match the regular expression: /[a-zA-Z0-9_.]+/
#
#	It allows you to define new virtual servers simply by placing
#	a file into the raddb/sites-enabled/ directory.
#
$INCLUDE sites-enabled/
 
######################################################################
#
#	All of the other configuration sections like "authorize {}",
#	"authenticate {}", "accounting {}", have been moved to the
#	the file:
#
#		raddb/sites-available/default
#
#	This is the "default" virtual server that has the same
#	configuration as in version 1.0.x and 1.1.x.  The default
#	installation enables this virtual server.  You should
#	edit it to create policies for your local site.
#
#	For more documentation on virtual servers, see:
#
#		raddb/sites-available/README
#
######################################################################

sudo vi /etc/freeradius/radiusd.conf

uncomment following includes if necessary: $INCLUDE clients.conf $INCLUDE sql.conf $INCLUDE sql/mysql/counter.conf

Under the instantiate section add the following counter modules: chillispot_max_bytes noresetcounter

Configure the default virtual server under sites-available:

default

######################################################################
#
#	As of 2.0.0, FreeRADIUS supports virtual hosts using the
#	"server" section, and configuration directives.
#
#	Virtual hosts should be put into the "sites-available"
#	directory.  Soft links should be created in the "sites-enabled"
#	directory to these files.  This is done in a normal installation.
#
#	If you are using 802.1X (EAP) authentication, please see also
#	the "inner-tunnel" virtual server.  You wll likely have to edit
#	that, too, for authentication to work.
#
#	$Id: 520ccbc90f3a09cd6a80e1e3b16000b7ba94d884 $
#
######################################################################
#
#	Read "man radiusd" before editing this file.  See the section
#	titled DEBUGGING.  It outlines a method where you can quickly
#	obtain the configuration you want, without running into
#	trouble.  See also "man unlang", which documents the format
#	of this file.
#
#	This configuration is designed to work in the widest possible
#	set of circumstances, with the widest possible number of
#	authentication methods.  This means that in general, you should
#	need to make very few changes to this file.
#
#	The best way to configure the server for your local system
#	is to CAREFULLY edit this file.  Most attempts to make large
#	edits to this file will BREAK THE SERVER.  Any edits should
#	be small, and tested by running the server with "radiusd -X".
#	Once the edits have been verified to work, save a copy of these
#	configuration files somewhere.  (e.g. as a "tar" file).  Then,
#	make more edits, and test, as above.
#
#	There are many "commented out" references to modules such
#	as ldap, sql, etc.  These references serve as place-holders.
#	If you need the functionality of that module, then configure
#	it in radiusd.conf, and un-comment the references to it in
#	this file.  In most cases, those small changes will result
#	in the server being able to connect to the DB, and to
#	authenticate users.
#
######################################################################
 
#
#	In 1.x, the "authorize", etc. sections were global in
#	radiusd.conf.  As of 2.0, they SHOULD be in a server section.
#
#	The server section with no virtual server name is the "default"
#	section.  It is used when no server name is specified.
#
#	We don't indent the rest of this file, because doing so
#	would make it harder to read.
#
 
#  Authorization. First preprocess (hints and huntgroups files),
#  then realms, and finally look in the "users" file.
#
#  Any changes made here should also be made to the "inner-tunnel"
#  virtual server.
#
#  The order of the realm modules will determine the order that
#  we try to find a matching realm.
#
#  Make *sure* that 'preprocess' comes before any realm if you 
#  need to setup hints for the remote radius server
authorize {
	#
	#  Security settings.  Take a User-Name, and do some simple
	#  checks on it, for spaces and other invalid characters.  If
	#  it looks like the user is trying to play games, reject it.
	#
	#  This should probably be enabled by default.
	#
	#  See policy.conf for the definition of the filter_username policy.
	#
#	filter_username
 
	#
	#  The preprocess module takes care of sanitizing some bizarre
	#  attributes in the request, and turning them into attributes
	#  which are more standard.
	#
	#  It takes care of processing the 'raddb/hints' and the
	#  'raddb/huntgroups' files.
	#preprocess
 
	#
	#  If you want to have a log of authentication requests,
	#  un-comment the following line, and the 'detail auth_log'
	#  section, above.
	auth_log
 
	#
	#  The chap module will set 'Auth-Type := CHAP' if we are
	#  handling a CHAP request and Auth-Type has not already been set
	chap
 
	#
	#  If the users are logging in with an MS-CHAP-Challenge
	#  attribute for authentication, the mschap module will find
	#  the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
	#  to the request, which will cause the server to then use
	#  the mschap module for authentication.
	mschap
 
	#
	#  If you have a Cisco SIP server authenticating against
	#  FreeRADIUS, uncomment the following line, and the 'digest'
	#  line in the 'authenticate' section.
	digest
 
	#
	#  The WiMAX specification says that the Calling-Station-Id
	#  is 6 octets of the MAC.  This definition conflicts with
	#  RFC 3580, and all common RADIUS practices.  Un-commenting
	#  the "wimax" module here means that it will fix the
	#  Calling-Station-Id attribute to the normal format as
	#  specified in RFC 3580 Section 3.21
#	wimax
 
	#
	#  Look for IPASS style 'realm/', and if not found, look for
	#  '@realm', and decide whether or not to proxy, based on
	#  that.
#	IPASS
 
	#
	#  If you are using multiple kinds of realms, you probably
	#  want to set "ignore_null = yes" for all of them.
	#  Otherwise, when the first style of realm doesn't match,
	#  the other styles won't be checked.
	#
	suffix
#	ntdomain
 
	#
	#  This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
	#  authentication.
	#
	#  It also sets the EAP-Type attribute in the request
	#  attribute list to the EAP type from the packet.
	#
	#  As of 2.0, the EAP module returns "ok" in the authorize stage
	#  for TTLS and PEAP.  In 1.x, it never returned "ok" here, so
	#  this change is compatible with older configurations.
	#
	#  The example below uses module failover to avoid querying all
	#  of the following modules if the EAP module returns "ok".
	#  Therefore, your LDAP and/or SQL servers will not be queried
	#  for the many packets that go back and forth to set up TTLS
	#  or PEAP.  The load on those servers will therefore be reduced.
	#
	eap {
		ok = return
	}
 
	#
	#  Pull crypt'd passwords from /etc/passwd or /etc/shadow,
	#  using the system API's to get the password.  If you want
	#  to read /etc/passwd or /etc/shadow directly, see the
	#  passwd module in radiusd.conf.
	#
	unix
 
	#
	#  Read the 'users' file
#	files
 
	#
	#  Look in an SQL database.  The schema of the database
	#  is meant to mirror the "users" file.
	#
	#  See "Authorization Queries" in sql.conf
	sql
 
	#
	#  If you are using /etc/smbpasswd, and are also doing
	#  mschap authentication, the un-comment this line, and
	#  configure the 'smbpasswd' module.
#	smbpasswd
 
	#
	#  The ldap module will set Auth-Type to LDAP if it has not
	#  already been set
#	ldap
 
	#
	#  Enforce daily limits on time spent logged in.
#	daily
 
	#
	# Use the checkval module
#	checkval
 
	expiration
	logintime
 
	#
	#  If no other module has claimed responsibility for
	#  authentication, then try to use PAP.  This allows the
	#  other modules listed above to add a "known good" password
	#  to the request, and to do nothing else.  The PAP module
	#  will then see that password, and use it to do PAP
	#  authentication.
	#
	#  This module should be listed last, so that the other modules
	#  get a chance to set Auth-Type for themselves.
	#
	pap
 
	#
	#  If "status_server = yes", then Status-Server messages are passed
	#  through the following section, and ONLY the following section.
	#  This permits you to do DB queries, for example.  If the modules
	#  listed here return "fail", then NO response is sent.
	#
#	Autz-Type Status-Server {
#
#	}
        noresetcounter
        chillispot_max_bytes
}
 
 
#  Authentication.
#
#
#  This section lists which modules are available for authentication.
#  Note that it does NOT mean 'try each module in order'.  It means
#  that a module from the 'authorize' section adds a configuration
#  attribute 'Auth-Type := FOO'.  That authentication type is then
#  used to pick the apropriate module from the list below.
#
 
#  In general, you SHOULD NOT set the Auth-Type attribute.  The server
#  will figure it out on its own, and will do the right thing.  The
#  most common side effect of erroneously setting the Auth-Type
#  attribute is that one authentication method will work, but the
#  others will not.
#
#  The common reasons to set the Auth-Type attribute by hand
#  is to either forcibly reject the user (Auth-Type := Reject),
#  or to or forcibly accept the user (Auth-Type := Accept).
#
#  Note that Auth-Type := Accept will NOT work with EAP.
#
#  Please do not put "unlang" configurations into the "authenticate"
#  section.  Put them in the "post-auth" section instead.  That's what
#  the post-auth section is for.
#
authenticate {
	#
	#  PAP authentication, when a back-end database listed
	#  in the 'authorize' section supplies a password.  The
	#  password can be clear-text, or encrypted.
	Auth-Type PAP {
		pap
	}
 
	#
	#  Most people want CHAP authentication
	#  A back-end database listed in the 'authorize' section
	#  MUST supply a CLEAR TEXT password.  Encrypted passwords
	#  won't work.
	Auth-Type CHAP {
		chap
	}
 
	#
	#  MSCHAP authentication.
	Auth-Type MS-CHAP {
		mschap
	}
 
	#
	#  If you have a Cisco SIP server authenticating against
	#  FreeRADIUS, uncomment the following line, and the 'digest'
	#  line in the 'authorize' section.
	digest
 
	#
	#  Pluggable Authentication Modules.
#	pam
 
	#
	#  See 'man getpwent' for information on how the 'unix'
	#  module checks the users password.  Note that packets
	#  containing CHAP-Password attributes CANNOT be authenticated
	#  against /etc/passwd!  See the FAQ for details.
	#
	#  For normal "crypt" authentication, the "pap" module should
	#  be used instead of the "unix" module.  The "unix" module should
	#  be used for authentication ONLY for compatibility with legacy
	#  FreeRADIUS configurations.
	#
	unix
 
	# Uncomment it if you want to use ldap for authentication
	#
	# Note that this means "check plain-text password against
	# the ldap database", which means that EAP won't work,
	# as it does not supply a plain-text password.
#	Auth-Type LDAP {
#		ldap
#	}
 
	#
	#  Allow EAP authentication.
	eap
 
	#
	#  The older configurations sent a number of attributes in
	#  Access-Challenge packets, which wasn't strictly correct.
	#  If you want to filter out these attributes, uncomment
	#  the following lines.
	#
#	Auth-Type eap {
#		eap {
#			handled = 1  
#		}
#		if (handled && (Response-Packet-Type == Access-Challenge)) {
#			attr_filter.access_challenge.post-auth
#			handled  # override the "updated" code from attr_filter
#		}
#	}
}
 
 
#
#  Pre-accounting.  Decide which accounting type to use.
#
preacct {
	preprocess
 
	#
	#  Session start times are *implied* in RADIUS.
	#  The NAS never sends a "start time".  Instead, it sends
	#  a start packet, *possibly* with an Acct-Delay-Time.
	#  The server is supposed to conclude that the start time
	#  was "Acct-Delay-Time" seconds in the past.
	#
	#  The code below creates an explicit start time, which can
	#  then be used in other modules.
	#
	#  The start time is: NOW - delay - session_length
	#
 
#	  update request {
#	  	FreeRADIUS-Acct-Session-Start-Time = "%{expr: %l - %{%{Acct-Session-Time}:-0} - %{%{Acct-Delay-Time}:-0}}"
#	}
 
 
	#
	#  Ensure that we have a semi-unique identifier for every
	#  request, and many NAS boxes are broken.
	acct_unique
 
	#
	#  Look for IPASS-style 'realm/', and if not found, look for
	#  '@realm', and decide whether or not to proxy, based on
	#  that.
	#
	#  Accounting requests are generally proxied to the same
	#  home server as authentication requests.
#	IPASS
	suffix
#	ntdomain
 
	#
	#  Read the 'acct_users' file
	files
}
 
#
#  Accounting.  Log the accounting data.
#
accounting {
	#
	#  Create a 'detail'ed log of the packets.
	#  Note that accounting requests which are proxied
	#  are also logged in the detail file.
	detail
#	daily
 
	#  Update the wtmp file
	#
	#  If you don't use "radlast", you can delete this line.
#	unix
 
	#
	#  For Simultaneous-Use tracking.
	#
	#  Due to packet losses in the network, the data here
	#  may be incorrect.  There is little we can do about it.
	radutmp
#	sradutmp
 
	#  Return an address to the IP Pool when we see a stop record.
#	main_pool
 
	#
	#  Log traffic to an SQL database.
	#
	#  See "Accounting queries" in sql.conf
	sql
 
	#
	#  If you receive stop packets with zero session length,
	#  they will NOT be logged in the database.  The SQL module
	#  will print a message (only in debugging mode), and will
	#  return "noop".
	#
	#  You can ignore these packets by uncommenting the following
	#  three lines.  Otherwise, the server will not respond to the
	#  accounting request, and the NAS will retransmit.
	#
#	if (noop) {
#		ok
#	}
 
	#
	#  Instead of sending the query to the SQL server,
	#  write it into a log file.
	#
#	sql_log
 
	#  Cisco VoIP specific bulk accounting
#	pgsql-voip
 
	# For Exec-Program and Exec-Program-Wait
	exec
 
	#  Filter attributes from the accounting response.
	attr_filter.accounting_response
 
	#
	#  See "Autz-Type Status-Server" for how this works.
	#
#	Acct-Type Status-Server {
#
#	}
}
 
 
#  Session database, used for checking Simultaneous-Use. Either the radutmp 
#  or rlm_sql module can handle this.
#  The rlm_sql module is *much* faster
session {
	radutmp
 
	#
	#  See "Simultaneous Use Checking Queries" in sql.conf
	sql
}
 
 
#  Post-Authentication
#  Once we KNOW that the user has been authenticated, there are
#  additional steps we can take.
post-auth {
	#  Get an address from the IP Pool.
#	main_pool
 
	#
	#  If you want to have a log of authentication replies,
	#  un-comment the following line, and the 'detail reply_log'
	#  section, above.
	reply_log
 
	#
	#  After authenticating the user, do another SQL query.
	#
	#  See "Authentication Logging Queries" in sql.conf
	sql
 
	#
	#  Instead of sending the query to the SQL server,
	#  write it into a log file.
	#
#	sql_log
 
	#
	#  Un-comment the following if you have set
	#  'edir_account_policy_check = yes' in the ldap module sub-section of
	#  the 'modules' section.
	#
#	ldap
 
	# For Exec-Program and Exec-Program-Wait
	exec
 
	#
	#  Calculate the various WiMAX keys.  In order for this to work,
	#  you will need to define the WiMAX NAI, usually via
	#
	#	update request {
	#	       WiMAX-MN-NAI = "%{User-Name}"
	#	}
	#
	#  If you want various keys to be calculated, you will need to
	#  update the reply with "template" values.  The module will see
	#  this, and replace the template values with the correct ones
	#  taken from the cryptographic calculations.  e.g.
	#
	# 	update reply {
	#		WiMAX-FA-RK-Key = 0x00
	#		WiMAX-MSK = "%{EAP-MSK}"
	#	}
	#
	#  You may want to delete the MS-MPPE-*-Keys from the reply,
	#  as some WiMAX clients behave badly when those attributes
	#  are included.  See "raddb/modules/wimax", configuration
	#  entry "delete_mppe_keys" for more information.
	#
#	wimax
 
	#  If there is a client certificate (EAP-TLS, sometimes PEAP
	#  and TTLS), then some attributes are filled out after the
	#  certificate verification has been performed.  These fields
	#  MAY be available during the authentication, or they may be
	#  available only in the "post-auth" section.
	#
	#  The first set of attributes contains information about the
	#  issuing certificate which is being used.  The second
	#  contains information about the client certificate (if
	#  available).
#
#	update reply {
#	       Reply-Message += "%{TLS-Cert-Serial}"
#	       Reply-Message += "%{TLS-Cert-Expiration}"
#	       Reply-Message += "%{TLS-Cert-Subject}"
#	       Reply-Message += "%{TLS-Cert-Issuer}"
#	       Reply-Message += "%{TLS-Cert-Common-Name}"
#	       Reply-Message += "%{TLS-Cert-Subject-Alt-Name-Email}"
#
#	       Reply-Message += "%{TLS-Client-Cert-Serial}"
#	       Reply-Message += "%{TLS-Client-Cert-Expiration}"
#	       Reply-Message += "%{TLS-Client-Cert-Subject}"
#	       Reply-Message += "%{TLS-Client-Cert-Issuer}"
#	       Reply-Message += "%{TLS-Client-Cert-Common-Name}"
#	       Reply-Message += "%{TLS-Client-Cert-Subject-Alt-Name-Email}"
#	}
 
	#  MacSEC requires the use of EAP-Key-Name.  However, we don't
	#  want to send it for all EAP sessions.  Therefore, the EAP
	#  modules put required data into the EAP-Session-Id attribute.
	#  This attribute is never put into a request or reply packet.
	#
	#  Uncomment the next few lines to copy the required data into
	#  the EAP-Key-Name attribute
#	if (reply:EAP-Session-Id) {
#		update reply {
#			EAP-Key-Name := "%{reply:EAP-Session-Id}"
#		}
#	}
 
	#  If the WiMAX module did it's work, you may want to do more
	#  things here, like delete the MS-MPPE-*-Key attributes.
	#
	#	if (updated) {
	#		update reply {
	#			MS-MPPE-Recv-Key !* 0x00
	#			MS-MPPE-Send-Key !* 0x00
	#		}
	#	}
 
	#
	#  Access-Reject packets are sent through the REJECT sub-section of the
	#  post-auth section.
	#
	#  Add the ldap module name (or instance) if you have set 
	#  'edir_account_policy_check = yes' in the ldap module configuration
	#
	Post-Auth-Type REJECT {
		# log failed authentications in SQL, too.
#		sql
		attr_filter.access_reject
	}
}
 
#
#  When the server decides to proxy a request to a home server,
#  the proxied request is first passed through the pre-proxy
#  stage.  This stage can re-write the request, or decide to
#  cancel the proxy.
#
#  Only a few modules currently have this method.
#
pre-proxy {
#	attr_rewrite
 
	#  Uncomment the following line if you want to change attributes
	#  as defined in the preproxy_users file.
#	files
 
	#  Uncomment the following line if you want to filter requests
	#  sent to remote servers based on the rules defined in the
	#  'attrs.pre-proxy' file.
#	attr_filter.pre-proxy
 
	#  If you want to have a log of packets proxied to a home
	#  server, un-comment the following line, and the
	#  'detail pre_proxy_log' section, above.
#	pre_proxy_log
}
 
#
#  When the server receives a reply to a request it proxied
#  to a home server, the request may be massaged here, in the
#  post-proxy stage.
#
post-proxy {
 
	#  If you want to have a log of replies from a home server,
	#  un-comment the following line, and the 'detail post_proxy_log'
	#  section, above.
#	post_proxy_log
 
#	attr_rewrite
 
	#  Uncomment the following line if you want to filter replies from
	#  remote proxies based on the rules defined in the 'attrs' file.
#	attr_filter.post-proxy
 
	#
	#  If you are proxying LEAP, you MUST configure the EAP
	#  module, and you MUST list it here, in the post-proxy
	#  stage.
	#
	#  You MUST also use the 'nostrip' option in the 'realm'
	#  configuration.  Otherwise, the User-Name attribute
	#  in the proxied request will not match the user name
	#  hidden inside of the EAP packet, and the end server will
	#  reject the EAP request.
	#
	eap
 
	#
	#  If the server tries to proxy a request and fails, then the
	#  request is processed through the modules in this section.
	#
	#  The main use of this section is to permit robust proxying
	#  of accounting packets.  The server can be configured to
	#  proxy accounting packets as part of normal processing.
	#  Then, if the home server goes down, accounting packets can
	#  be logged to a local "detail" file, for processing with
	#  radrelay.  When the home server comes back up, radrelay
	#  will read the detail file, and send the packets to the
	#  home server.
	#
	#  With this configuration, the server always responds to
	#  Accounting-Requests from the NAS, but only writes
	#  accounting packets to disk if the home server is down.
	#
#	Post-Proxy-Type Fail {
#			detail
#	}
}

Under authorize section: Comment the following: #filter_username #files

Uncomment the following: auth_log unix

Change the following if necessary: '-sql' to sql

Add the following at the end of authorize section: chillispot_max_bytes noresetcounter

Next under accounting section, Uncomment the following: radutmp

Change the following if necessary: '-sql' to sql

Next under session section, Uncomment the following: radutmp sql

Next under post-auth section, Uncomment the following: reply_log

Change the following if necessary: '-sql' to sql

Configure the inner tunnel requests virtual server under sites-available:

inner-tunnel

# -*- text -*-
######################################################################
#
#	This is a virtual server that handles *only* inner tunnel
#	requests for EAP-TTLS and PEAP types.
#
#	$Id: bb0b93bc9cc9ade4e78725ea113d6f228937fef7 $
#
######################################################################
 
server inner-tunnel {
 
#
#  This next section is here to allow testing of the "inner-tunnel"
#  authentication methods, independently from the "default" server.
#  It is listening on "localhost", so that it can only be used from
#  the same machine.
#
#	$ radtest USER PASSWORD 127.0.0.1:18120 0 testing123
#
#  If it works, you have configured the inner tunnel correctly.  To check
#  if PEAP will work, use:
#
#	$ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123
#
#  If that works, PEAP should work.  If that command doesn't work, then
#
#	FIX THE INNER TUNNEL CONFIGURATION SO THAT IT WORKS.
#
#  Do NOT do any PEAP tests.  It won't help.  Instead, concentrate
#  on fixing the inner tunnel configuration.  DO NOTHING ELSE.
#
listen {
       ipaddr = 127.0.0.1
       port = 18120
       type = auth
}
 
 
#  Authorization. First preprocess (hints and huntgroups files),
#  then realms, and finally look in the "users" file.
#
#  The order of the realm modules will determine the order that
#  we try to find a matching realm.
#
#  Make *sure* that 'preprocess' comes before any realm if you 
#  need to setup hints for the remote radius server
authorize {
	#
	#  The chap module will set 'Auth-Type := CHAP' if we are
	#  handling a CHAP request and Auth-Type has not already been set
	chap
 
	#
	#  If the users are logging in with an MS-CHAP-Challenge
	#  attribute for authentication, the mschap module will find
	#  the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
	#  to the request, which will cause the server to then use
	#  the mschap module for authentication.
	mschap
 
	#
	#  Pull crypt'd passwords from /etc/passwd or /etc/shadow,
	#  using the system API's to get the password.  If you want
	#  to read /etc/passwd or /etc/shadow directly, see the
	#  passwd module, above.
	#
#	unix
 
	#
	#  Look for IPASS style 'realm/', and if not found, look for
	#  '@realm', and decide whether or not to proxy, based on
	#  that.
#	IPASS
 
	#
	#  If you are using multiple kinds of realms, you probably
	#  want to set "ignore_null = yes" for all of them.
	#  Otherwise, when the first style of realm doesn't match,
	#  the other styles won't be checked.
	#
	#  Note that proxying the inner tunnel authentication means
	#  that the user MAY use one identity in the outer session
	#  (e.g. "anonymous", and a different one here
	#  (e.g. "user@example.com").  The inner session will then be
	#  proxied elsewhere for authentication.  If you are not
	#  careful, this means that the user can cause you to forward
	#  the authentication to another RADIUS server, and have the
	#  accounting logs *not* sent to the other server.  This makes
	#  it difficult to bill people for their network activity.
	#
	suffix
#	ntdomain
 
	#
	#  The "suffix" module takes care of stripping the domain
	#  (e.g. "@example.com") from the User-Name attribute, and the
	#  next few lines ensure that the request is not proxied.
	#
	#  If you want the inner tunnel request to be proxied, delete
	#  the next few lines.
	#
	update control {
	       Proxy-To-Realm := LOCAL
	}
 
	#
	#  This module takes care of EAP-MSCHAPv2 authentication.
	#
	#  It also sets the EAP-Type attribute in the request
	#  attribute list to the EAP type from the packet.
	#
	#  The example below uses module failover to avoid querying all
	#  of the following modules if the EAP module returns "ok".
	#  Therefore, your LDAP and/or SQL servers will not be queried
	#  for the many packets that go back and forth to set up TTLS
	#  or PEAP.  The load on those servers will therefore be reduced.
	#
	eap {
		ok = return
	}
 
	#
	#  Read the 'users' file
	files
 
	#
	#  Look in an SQL database.  The schema of the database
	#  is meant to mirror the "users" file.
	#
	#  See "Authorization Queries" in sql.conf
	sql
 
	#
	#  If you are using /etc/smbpasswd, and are also doing
	#  mschap authentication, the un-comment this line, and
	#  configure the 'etc_smbpasswd' module, above.
#	etc_smbpasswd
 
	#
	#  The ldap module will set Auth-Type to LDAP if it has not
	#  already been set
#	ldap
 
	#
	#  Enforce daily limits on time spent logged in.
#	daily
 
	#
	# Use the checkval module
#	checkval
 
	expiration
	logintime
 
	#
	#  If no other module has claimed responsibility for
	#  authentication, then try to use PAP.  This allows the
	#  other modules listed above to add a "known good" password
	#  to the request, and to do nothing else.  The PAP module
	#  will then see that password, and use it to do PAP
	#  authentication.
	#
	#  This module should be listed last, so that the other modules
	#  get a chance to set Auth-Type for themselves.
	#
	pap
        noresetcounter
        chillispot_max_bytes
}
 
 
#  Authentication.
#
#
#  This section lists which modules are available for authentication.
#  Note that it does NOT mean 'try each module in order'.  It means
#  that a module from the 'authorize' section adds a configuration
#  attribute 'Auth-Type := FOO'.  That authentication type is then
#  used to pick the apropriate module from the list below.
#
 
#  In general, you SHOULD NOT set the Auth-Type attribute.  The server
#  will figure it out on its own, and will do the right thing.  The
#  most common side effect of erroneously setting the Auth-Type
#  attribute is that one authentication method will work, but the
#  others will not.
#
#  The common reasons to set the Auth-Type attribute by hand
#  is to either forcibly reject the user, or forcibly accept him.
#
authenticate {
	#
	#  PAP authentication, when a back-end database listed
	#  in the 'authorize' section supplies a password.  The
	#  password can be clear-text, or encrypted.
	Auth-Type PAP {
		pap
	}
 
	#
	#  Most people want CHAP authentication
	#  A back-end database listed in the 'authorize' section
	#  MUST supply a CLEAR TEXT password.  Encrypted passwords
	#  won't work.
	Auth-Type CHAP {
		chap
	}
 
	#
	#  MSCHAP authentication.
	Auth-Type MS-CHAP {
		mschap
	}
 
	#
	#  Pluggable Authentication Modules.
#	pam
 
	#
	#  See 'man getpwent' for information on how the 'unix'
	#  module checks the users password.  Note that packets
	#  containing CHAP-Password attributes CANNOT be authenticated
	#  against /etc/passwd!  See the FAQ for details.
	#  
	unix
 
	# Uncomment it if you want to use ldap for authentication
	#
	# Note that this means "check plain-text password against
	# the ldap database", which means that EAP won't work,
	# as it does not supply a plain-text password.
#	Auth-Type LDAP {
#		ldap
#	}
 
	#
	#  Allow EAP authentication.
	eap
}
 
######################################################################
#
#	There are no accounting requests inside of EAP-TTLS or PEAP
#	tunnels.
#
######################################################################
 
 
#  Session database, used for checking Simultaneous-Use. Either the radutmp 
#  or rlm_sql module can handle this.
#  The rlm_sql module is *much* faster
session {
	radutmp
 
	#
	#  See "Simultaneous Use Checking Queries" in sql.conf
	sql
}
 
 
#  Post-Authentication
#  Once we KNOW that the user has been authenticated, there are
#  additional steps we can take.
post-auth {
	# Note that we do NOT assign IP addresses here.
	# If you try to assign IP addresses for EAP authentication types,
	# it WILL NOT WORK.  You MUST use DHCP.
 
	#
	#  If you want to have a log of authentication replies,
	#  un-comment the following line, and the 'detail reply_log'
	#  section, above.
	reply_log
 
	#
	#  After authenticating the user, do another SQL query.
	#
	#  See "Authentication Logging Queries" in sql.conf
	sql
 
	#
	#  Instead of sending the query to the SQL server,
	#  write it into a log file.
	#
#	sql_log
 
	#
	#  Un-comment the following if you have set
	#  'edir_account_policy_check = yes' in the ldap module sub-section of
	#  the 'modules' section.
	#
#	ldap
 
	#
	#  Access-Reject packets are sent through the REJECT sub-section of the
	#  post-auth section.
	#
	#  Add the ldap module name (or instance) if you have set 
	#  'edir_account_policy_check = yes' in the ldap module configuration
	#
	Post-Auth-Type REJECT {
		# log failed authentications in SQL, too.
#		sql
		attr_filter.access_reject
	}
 
	#
	#  The example policy below updates the outer tunnel reply
	#  (usually Access-Accept) with the User-Name from the inner
	#  tunnel User-Name.  Since this section is processed in the
	#  context of the inner tunnel, "request" here means "inner
	#  tunnel request", and "outer.reply" means "outer tunnel
	#  reply attributes".
	#
	#  This example is most useful when the outer session contains
	#  a User-Name of "anonymous@....", or a MAC address.  If it
	#  is enabled, the NAS SHOULD use the inner tunnel User-Name
	#  in subsequent accounting packets.  This makes it easier to
	#  track user sessions, as they will all be based on the real
	#  name, and not on "anonymous".
	#
	#  The problem with doing this is that it ALSO exposes the
	#  real user name to any intermediate proxies.  People use
	#  "anonymous" identifiers outside of the tunnel for a very
	#  good reason: it gives them more privacy.  Setting the reply
	#  to contain the real user name removes ALL privacy from
	#  their session.
	#
	#  If you want privacy to remain, see the
	#  Chargeable-User-Identity attribute from RFC 4372.  In order
	#  to use that attribute, you will have to allocate a
	#  per-session identifier for the user, and store it in a
	#  long-term database (e.g. SQL).  You should also use that
	#  attribute INSTEAD of the configuration below.
	#
	#update outer.reply {
	#	User-Name = "%{request:User-Name}"
	#}
 
}
 
#
#  When the server decides to proxy a request to a home server,
#  the proxied request is first passed through the pre-proxy
#  stage.  This stage can re-write the request, or decide to
#  cancel the proxy.
#
#  Only a few modules currently have this method.
#
pre-proxy {
#	attr_rewrite
 
	#  Uncomment the following line if you want to change attributes
	#  as defined in the preproxy_users file.
#	files
 
	#  Uncomment the following line if you want to filter requests
	#  sent to remote servers based on the rules defined in the
	#  'attrs.pre-proxy' file.
#	attr_filter.pre-proxy
 
	#  If you want to have a log of packets proxied to a home
	#  server, un-comment the following line, and the
	#  'detail pre_proxy_log' section, above.
#	pre_proxy_log
}
 
#
#  When the server receives a reply to a request it proxied
#  to a home server, the request may be massaged here, in the
#  post-proxy stage.
#
post-proxy {
 
	#  If you want to have a log of replies from a home server,
	#  un-comment the following line, and the 'detail post_proxy_log'
	#  section, above.
#	post_proxy_log
 
#	attr_rewrite
 
	#  Uncomment the following line if you want to filter replies from
	#  remote proxies based on the rules defined in the 'attrs' file.
#	attr_filter.post-proxy
 
	#
	#  If you are proxying LEAP, you MUST configure the EAP
	#  module, and you MUST list it here, in the post-proxy
	#  stage.
	#
	#  You MUST also use the 'nostrip' option in the 'realm'
	#  configuration.  Otherwise, the User-Name attribute
	#  in the proxied request will not match the user name
	#  hidden inside of the EAP packet, and the end server will
	#  reject the EAP request.
	#
	eap
 
	#
	#  If the server tries to proxy a request and fails, then the
	#  request is processed through the modules in this section.
	#
	#  The main use of this section is to permit robust proxying
	#  of accounting packets.  The server can be configured to
	#  proxy accounting packets as part of normal processing.
	#  Then, if the home server goes down, accounting packets can
	#  be logged to a local "detail" file, for processing with
	#  radrelay.  When the home server comes back up, radrelay
	#  will read the detail file, and send the packets to the
	#  home server.
	#
	#  With this configuration, the server always responds to
	#  Accounting-Requests from the NAS, but only writes
	#  accounting packets to disk if the home server is down.
	#
#	Post-Proxy-Type Fail {
#			detail
#	}
 
}
 
} # inner-tunnel server block

sudo vi /etc/freeradius/sites-available/inner-tunnel

Under authorize section, change the following if necessary: '-sql' to sql

Add the following at the end of authorize section: chillispot_max_bytes noresetcounter

Next under the session section, Uncomment the following: sql

Next under post-auth section, Uncomment the following: reply_log

Change the following if necessary: '-sql' to sql

Create Admin User in radius MySQL database: echo “INSERT INTO radcheck (UserName, Attribute, Value, Op) VALUES ('[ADMIN_USER]', 'Cleartext-Password', '[ADMIN_PASSWORD]', ':=');” | mysql -u radius -p[FREERADIUS_DB_PASS] radius

Start radius for initialization and testing purposes radtest [ADMIN_USER] [ADMIN_PASSWORD] 127.0.0.1 0 [FREERADIUS_DB_PASS]

If you get a message like this one, then you are done with the minimal and required radius setup for the next steps: Received Access-Accept Id 174 from 127.0.0.1:1812 to 0.0.0.0:0 length 20

To add users so they can access the Internet using your hotspot, run the following command for each user. You can automate it using a script if you wish.

echo “INSERT INTO radcheck (UserName, Attribute, Value, Op) VALUES ('[LOGIN_NAME]', 'ChilliSpot-Max-Total-Octets', '[MAX_TOTAL_OCTETS]', ':=');” | mysql -u radius -p[FREERADIUS_DB_PASS] radius