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.
Schematic
The following diagram shows how everything fits together
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!
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 192.168.1.104.
Accessing RADIUSdesk
Continuing from the previous section we will use the 192.168.1.104 IP Address.
You can now simply point the browser on the Windows machine to the following URL:
http://192.168.1.104/rd.
Remember to replace the 192.168.1.104 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 10.1.0.1 IP Address can be used to access RADIUSdesk from the side which is running the captive portal.
http://10.1.0.1/rd/
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.
FAQ
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.
Item
Value
IP Address
192.168.1.100
Subnet Mask
255.255.255.0
Default Gateway
192.168.1.1
DNS Servers
192.168.1.1
192.168.1.2
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 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1 192.168.1.2
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?
The dynamic page’s content is served based in a common defined key found in the CoovaChilli URL and the entry in the
Dynamic login pages
applet.
This gives you the flexibility to decide which key you will make use of and what its value will be.
We decided that the
ssid
will be the key to use in order to serve the content of the
SA Coast Struisbaai
entry in the
Dynamic login pages
applet of RADIUSdesk.
This can; however be any of the key/value pairs in the query string that is shown during login.
With CoovaAP it is often handy to tweak some of the values available when you are setting the CoovaAP’s captive portal up and see what the result is in the login page’s query string.
We could just as well have chosen
nasid=localhost
and then do the following:
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
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.
GONE ARE THOSE DAYS
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 of
HS_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
