İçeriğe geç

RADIUSdesk Üzerine..!

Thanks to those who shared their experience! We give you a heads-up early here in order to ensure a pleasant experience.

  • Each time you start the VM on a machine with different MAC addresses, Debian and Ubuntu lets udev assign a new eth number to these MACs. This will cause the network not to start up as intended.
  • Edit /etc/udev/rules.d/70-persistent-net.rules or simply delete this file and reboot. It will then be recreated at the next boot.
  • On newer versions of VirtualBox (or certain machines) you may get an error message on PAE kernel while the machine tries to boot. You need to enable the PEA feature in the processor settings.
  • Click on the VM in Virtualbox and select Machine -> Settings. Select System -> Processor and tick the Extended features Enable PAE/NX checkbox.
  • Try to start the VM again.


  • The following diagram shows how everything fits together
  • Download and install the latest VirtualBox software from this website: http://www.virtualbox.org/
  • Download the latest OVA file from RADIUSdesk’s project on SourceForge: https://sourceforge.net/projects/radiusdesk/files/VM-Images/
  • Launch the VirtualBox application.
  • Select File -> Import Appliance. This will open a wizard that will ask you to select a OVA file to import.
  • Select the RADIUSdesk OVA file which you just downloaded.
  • After it is imported you should fine-tune the appliance. The most important part is the network interfaces

Configuring the Network of the virtual appliance

  • With VirtualBox open, select the RADIUSdesk virtual machine in the left panel.
  • Select the Network option on the right (The virtual machine should not be running for you to select the interface)
  • This will bring a configuration window up.
  • Adapter 1 should be the interface you connect with to the Internet and it should be bridged (NOT NAT which is the default). In this sample (a Dell laptop) we use the Wi-Fi interface to connect to the Internet).
  • Adapter 2 should also be enabled and should be the interface that will serve as the captive portal. You will typically connect an access point (AP) with DHCP disabled and open security to this interface. You can also connect a switch or hub to this interface. In this sample we use the laptop’s LAN interface to serve as the captive portal.

Testing the waters

  • Everything is now completed and ready for us to test. Start the virtual server and connect with another machine to the interface running the captive portal.
  • The machine you connect with should get a 10.1.0.x IP Address.
  • Try to go into the Internet. You should get a login page.
  • Log in with user dvdwalt and password dvdwalt

Congratulations! Your captive portal is now up and running on Windows!

Determine the VM’s IP Address

  • To determine the IP Address which was handed to the interface connecting to the Internet on the virtual machine do the following.
  • The virtual machine will start up and show a terminal window (The VM does not have any GUI interface).
  • Log into this terminal window using username: system and password: admin.
  • Issue the command ifconfig eth0. The feedback will show the IP Address which you can use in the URL to access RADIUSdesk’s web interface.
  • In the screen shot above the IP Address is shown as

Accessing RADIUSdesk

  • Continuing from the previous section we will use the IP Address.
  • You can now simply point the browser on the Windows machine to the following URL:
  • Remember to replace the with the value relevant to your set-up.
  • You can in fact access RADIUSdesk from any machine that is also on the same network as the Windows machine.
  • To log into RADIUSdesk user the following user: root and password admin.
  • Using the RADIUSdesk you can now add users, create vouchers and monitor usage etc.

Miscellaneous info

  • There is a user called system and password admin that you can use to access the Linux system with. You can access the system directly using the virtual machine’s console or ssh in through the network.
  • The IP Address can be used to access RADIUSdesk from the side which is running the captive portal.
  • Remember that the virtual machine has three classes of credentials.
  • The one is used by the captive portal to give Internet access to users (dvdwalt with password dvdwalt). These users are managed and created using RADIUSdesk.
  • Another is used for accessing the RADIUSdesk’s virtual machine’s web interface (root with password admin). These users are administering RADIUSdesk.
  • The third class of user is a Linux system user on the virtual machine. (system with password admin). This user is used to log into the Ubuntu Linux machine through the terminal or ssh.


The following questions may come in handy in your deployment of the RADIUSdesk virtual machine.

Using a static IP Address on the Adapter 1 interface.

  • Adapter 1 will be eth0 on the virtual machine. We assume the following settings as an example.
IP Address192.168.1.100
Subnet Mask255.255.255.0
Default Gateway192.168.1.1
DNS Servers192.168.1.1
  • With the info above; the /etc/network/interfaces file will look like this:# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address netmask gateway dns-nameservers
  • Reboot the virtual machine to make sure the settings is applied during start-up.

Where is the login page?

  • CoovaChilli has a initial landing page where the back-end will decide if a client to the CoovaChilli captive will be served with the Desktop logn page or the mobile login page.
  • This landing page is:
    http://{VM eth0 IP Address}/cake2/rd_cake/dynamic_details/chilli_browser_detect/

How is the dynamic page served?

  • As you can see that the SA Coast Struisbaai entry’s data will be served whenever a query string containing nasid=localhost or ssid=Struisbaai is part of the login page’s query string.
  • To confirm that this is working; we can fool the login page to think it is going through a captive portal although you can only fool him that much 😉
    • http://{VM eth0 IP Address}/rd_login_pages/desktop/CoovaChilli/build/CoovaLogin/production/index.html?nasid=localhost
    • http://{VM eth0 IP Address}/rd_login_pages/desktop/CoovaChilli/build/CoovaLogin/production/index.html?nasid=localhost
    • http://{VM eth0 IP Address}/rd_login_pages/desktop/CoovaChilli/build/CoovaLogin/production/index.html?ssid=Struisbaai
    • http://{VM eth0 IP Address}/rd_login_pages/mobile/CoovaChilli/index.html?nasid=localhost
    • http://{VM eth0 IP Address}/rd_login_pages/mobile/CoovaChilli/index.html?ssid=Struisbaai
  • The above pages should all serve up content of the SA Coast Struisbaai entry as a result of the query string’s key value pairs which was defined under the Dynamic keys tab of the SA Coast Struisbaai entry.

If you want to kick user off

  • If you want to kick users of from other CoovaChilli devices (like CoovaAP), RADIUSdesk must know how to do it.
  • We do this by specifying two things to an entry in the NAS devices applet.
  • Under Optional Info we need to make the Type CoovaChilli
  • Under Optional Info we need to make the Ports 3799
  • Also ensure that the devices running CoovaChilli is started with the coaport=3799 option as specified here:

UAM port 3660 or 3990?

  • If you come from the YFi Hotspot manger environment; you had to declare this port in some of the login pages and it could get confusing.
  • You also had to specify the IP Address of the server where you serve the login pages from in some of the login pages itself; which is just a pain.
  • These are all taken care of for you! You don’t have to change or tweak a thing.

Adjusting the UAM secret

  • When using other CoovaChilli devices (like CoovaAP) you may want to modify the value of the UAM secret on the virtual machine to match those used on the CoovaAP’s.
  • With the dynamic login pages; you will require a common UAM secret among all the CoovaChilli devices in order for the login page to work correct.
  • Edit the /usr/share/nginx/www/rd_login_pages/services/uam.php file
  • Look for the following line and change accordingly:$uamsecret = 'greatsecret'; //Shared secret between chilli and uam json service
  • You do not need to restart anything and can simply try to connect again from the CoovaChilli device.
  • In order for the local running CoovaChilli instance on the virtual machine to also still be able to make use of the dynamic login pages; edit the /etc/chilli/config file and change to value ofHS_UAMSECRET=greatsecret # Set to be your UAM secret
  • Remember to restart CoovaChilli after the change:sudo /etc/init.d/chilli stop sudo /etc/init.d/chilli start

İlk Yorumu Siz Yapın

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir