Disconnecting Active RADIUS Users


  • The RADIUS protocol uses UDP to communicate between the client and the server.
  • The client initiates all communication and the server simply replies.
  • There are however times when the need arise for the server to initiate communication to the client.
  • A typical example will be when there is a need to disconnect an active user.
  • Since January 2023 RADIUSdesk introduced an update that will allow you do send disconnect requests to RADIUS Clients in order to disconnect active users.

Some technical information

  • In order for the RADIUS server to communicate with the RADIUS Client we need determine two things.
    • The type of client.
    • The type of client in turn will determine how we will communicate with the RADIUS Client.
  • We currently support two types of clients.
    • CoovaChilli (Used by MESHdesk and APdesk)
    • Mikrotik
  • In the rest of the document we will discuss how the RADIUSdesk system communicate with these two types of clients.
  • We will also take a look where to make changes in order to add support for additional types of RADIUS Clients.

CoovaChilli on MESHdesk and APdesk

  • MESHdesk and APdesk automatically adds an associated RADIUS Client when adding a Captive Portal exit point.
  • This RADIUS Client will have the type of Coova-On-Meshdesk.

  • Disconnecting a user will then utilize the /var/www/rdcore/cake4/rd_cake/src/Controller/Component/KickerComponent.php component to contact the AP with instructions to disconnect the user.
  • When the MQTT mechanism is implemented disconnecting will be in real-time.
  • Without the MQTT mechanism disconnecting a user will take up to one minute.
  • The disconnect command used on CoovaChilli will be chilli_query logout mac <MAC Address>


  • With the Mikrotik RADIUS Clients we make use of the RouterOS API Client to communicate with the Mikrotik. (https://github.com/EvilFreelancer/routeros-api-php)
  • This library is already included with RADIUSdesk.
  • Many times there will be a NAT connection between the Mikrotik and the RADIUSdesk server preventing the server to reach the Mikrotik directly.
  • Mikrotik fortunately supports a large amount of VPN technologies which you can choose from.
  • If needed, please select one of your choosing. Setting them up is well documented in the Mikrotik documentation in the link above.
  • When adding a RADIUS Client and selecting the Mikrotik-API type you will be presented with a dialog to supply the detail for the API connection to the Mikrotik.
  • There is also a Test API Connection button which allows you to confirm that the API communication to the Mikrotik is indeed working.
  • In the screenshot above you can see part of the reply from the Mikrotik indicating that the communication via the API is established and good.
  • We also added a Mikrotik API button to the toolbar for RADIUS Clients.

  • The button is disabled by default and becomes enabled when you select a RADIUS Client of type Mikrotik-API.
  • Selecting it will open a new tab with two sub-tabs. One listing active Hotspot users and the other listing active PPPoE users.
  • You can select and disconnect listed users in those sub-tabs.

Add Support for additional types

  • This section is a technical section for those who wants to introduce new RADIUS Client types.
  • The list in the drop-down is specified in the following file: /var/www/rdcore/cake4/rd_cake/config/RadiusDesk.php
//Define nas types
$config['nas_types'][0]     = ['name' => 'Other',            	'id' => 'other',       		'active' => true];
$config['nas_types'][1]     = ['name' => 'Coova-On-Meshdesk', 'id' => 'CoovaMeshdesk',   	'active' => true];
$config['nas_types'][2]     = ['name' => 'Mikrotik-API',	'id' => 'Mikrotik-API',   	'active' => true];
  • Then when selecting an active user in Activity Monitor to disconnect behind the scenes the code will determine the type of RADIUS Client based on the nasidentifier field. (This is in the radacct table and has to match the value in the dynamic-clients table)
  • This all happens inside the /var/www/rdcore/cake4/rd_cake/src/Controller/Component/KickerComponent.php file.
  • Thus adding support for additional types will involve adding additional sections to the PHP code.
  • See the snippet below.
//First we try to locate the client under dynamic_clients
$dc = $this->DynamicClients->find()
	->where(['DynamicClients.nasidentifier' => $nasidentifier])
	if($dc->type == $this->coova_md){ //It is type CoovaMeshdesk => Now try and locate AP to send command to 
		//We have a convention of nasidentifier for meshdesk => mcp_<captive_portal_id> and apdesk => ap_<ap id>_cp_<captive_portal_id>
		if(preg_match('/^mcp_/' ,$nasidentifier)){ //MESHdesk     		
		if(preg_match('/^ap_/' ,$nasidentifier)){ //APdesk		
		sleep(1); //Give MQTT time to do its thing....  			
  • That's the only things involved in disconnecting an active RADIUS user.
  • The FUP implementation also utilizes this mechanism so this also serve as a core component for the FUP implementation to be successful.