RADIUSdesk

Trace:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
getting_started:18_install_ubuntu_coovachilli [2019/12/21 04:34] – [Enable CoovaChilli] admingetting_started:18_install_ubuntu_coovachilli [2019/12/23 12:27] (current) – [Installing CoovaChilli] admin
Line 25: Line 25:
  
 <code bash> <code bash>
 +# If you downloaded with wget
 tar -xzvf 1.5.tar.gz tar -xzvf 1.5.tar.gz
 +# If you downloaded with the browser 
 +tar -xzvf coova-chilli-1.5.tar.gz
 cd coova-chilli-1.5/ cd coova-chilli-1.5/
  
Line 80: Line 83:
   * Save the file and start CoovaChilli   * Save the file and start CoovaChilli
 <code bash> <code bash>
 +   #First enable the service so it will start up during boot
    sudo systemctl enable chilli    sudo systemctl enable chilli
    # Feedback code should be...    # Feedback code should be...
Line 150: Line 154:
   * Use the following /etc/chilli/config file as a guideline to configure CoovaChilli   * Use the following /etc/chilli/config file as a guideline to configure CoovaChilli
 <code bash> <code bash>
 +HS_WANIF=enp0s3              # WE ALSO Need to specify this
 HS_LANIF=enp0s8              # Subscriber Interface for client devices HS_LANIF=enp0s8              # Subscriber Interface for client devices
 HS_NETWORK=10.1.0.0        # HotSpot Network (must include HS_UAMLISTEN) HS_NETWORK=10.1.0.0        # HotSpot Network (must include HS_UAMLISTEN)
Line 165: Line 170:
 HS_NASIP=127.0.0.1    # To explicitly set NAS-IP-Address HS_NASIP=127.0.0.1    # To explicitly set NAS-IP-Address
 HS_UAMSERVER=$HS_UAMLISTEN HS_UAMSERVER=$HS_UAMLISTEN
-HS_UAMFORMAT=http://\$HS_UAMLISTEN/cake2/rd_cake/dynamic_details/chilli_browser_detect/+HS_UAMFORMAT=http://\$HS_UAMLISTEN/cake3/rd_cake/dynamic-details/chilli-browser-detect/
 HS_MACAUTH=on              # To turn on MAC Authentication HS_MACAUTH=on              # To turn on MAC Authentication
 HS_TCP_PORTS="80 23 8000" HS_TCP_PORTS="80 23 8000"
Line 176: Line 181:
 HS_LOC_NAME="My HotSpot"           # WISPr Location Name and used in portal HS_LOC_NAME="My HotSpot"           # WISPr Location Name and used in portal
 HS_COAPORT=3799 HS_COAPORT=3799
 +#Please specify the DNS servers of your choice here
 +#Here we specified out own DSL router and as a fallback one of the Google servers
 +HS_DNS1=192.168.1.1
 +HS_DNS2=8.8.8.8
 </code> </code>
  
Line 184: Line 193:
 </code> </code>
  
-  * Also comment the DNS server settings out in ///etc/chilli/defaults// to force CoovaChilli to use the DNS servers of the system that it is running on. 
-<code bash> 
-# OpenDNS Servers 
-#HS_DNS1=208.67.222.222 
-#HS_DNS2=208.67.220.220 
-</code> 
   * Use the following ///etc/chilli/ipup.sh// file as a guideline   * Use the following ///etc/chilli/ipup.sh// file as a guideline
 <code bash> <code bash>
-UAM server specified as 10.1.0.1 +#UAM server specified as 10.1.0.1 
 iptables -I INPUT -i tun0 -p tcp -m tcp --dport 80 --dst 10.1.0.1 -j ACCEPT iptables -I INPUT -i tun0 -p tcp -m tcp --dport 80 --dst 10.1.0.1 -j ACCEPT
 iptables -I INPUT -i tun0 -p tcp -m tcp --dport 443 --dst 10.1.0.1 -j ACCEPT iptables -I INPUT -i tun0 -p tcp -m tcp --dport 443 --dst 10.1.0.1 -j ACCEPT
 iptables -I INPUT -i tun0 -p tcp -m tcp --dport 22 --dst 10.1.0.1 -j ACCEPT iptables -I INPUT -i tun0 -p tcp -m tcp --dport 22 --dst 10.1.0.1 -j ACCEPT
 iptables -I INPUT -i tun0 -p tcp -m tcp --dport 8000 --dst 10.1.0.1 -j ACCEPT iptables -I INPUT -i tun0 -p tcp -m tcp --dport 8000 --dst 10.1.0.1 -j ACCEPT
 +# force-add the final rule necessary to fix routing tables (Enabling NAT)
 +iptables -F POSTROUTING -t nat
 +iptables -I POSTROUTING -t nat -o $HS_WANIF -j MASQUERADE
 </code> </code>
   * Use the following ///etc/chilli/ipdown.sh// file as a guideline   * Use the following ///etc/chilli/ipdown.sh// file as a guideline
 <code bash> <code bash>
-UAM server specified as 10.1.0.1 +#UAM server specified as 10.1.0.1 
 iptables -D INPUT -i tun0 -p tcp -m tcp --dport 80 --dst 10.1.0.1 -j ACCEPT iptables -D INPUT -i tun0 -p tcp -m tcp --dport 80 --dst 10.1.0.1 -j ACCEPT
 iptables -D INPUT -i tun0 -p tcp -m tcp --dport 443 --dst 10.1.0.1 -j ACCEPT iptables -D INPUT -i tun0 -p tcp -m tcp --dport 443 --dst 10.1.0.1 -j ACCEPT
Line 207: Line 213:
 </code> </code>
  
-===== Add NAT support ===== 
-  * By default CoovaChilli does not do NAT between the two interfaces. We have to add NAT support during start-up in order to have a working system.  
- 
-<WRAP center round alert 60%> 
-Failing to do this step will leave you with a broken system. 
-</WRAP> 
- 
-  * Edit the ///etc/init.d/chilli// file and add the following: 
-<code bash> 
-test ${HS_ADMINTERVAL:-0} -gt 0 && { 
-    (crontab -l 2>&- | grep -v $0 
-        echo "*/$HS_ADMINTERVAL * * * * $0 radconfig" 
-        ) | crontab - 2>&- 
-} 
- 
-#NAT mod 
-iptables -F POSTROUTING -t nat 
-iptables -I POSTROUTING -t nat -o $HS_WANIF -j MASQUERADE 
-#END NAT mod 
- 
-ifconfig $HS_LANIF 0.0.0.0 
- 
-</code> 
  
 ===== Test it out ===== ===== Test it out =====
   * Restart CoovaChilli for the latest changes to be effected.   * Restart CoovaChilli for the latest changes to be effected.
 <code bash> <code bash>
-sudo /etc/init.d/chilli stop +sudo systemctl stop chilli 
-sudo /etc/init.d/chilli start+sudo systemctl status chilli 
 +sudo systemctl start chilli 
 </code> </code>
   * Confirm it started fine   * Confirm it started fine
 <code bash> <code bash>
-sudo tail /var/log/messages+sudo systemctl status chilli
  
 ....... .......
 +● chilli.service - LSB: Start CoovaChilli daemon at boot time
 +   Loaded: loaded (/etc/init.d/chilli; generated)
 +   Active: active (running) since Sat 2019-12-21 03:05:26 UTC; 2s ago
 +     Docs: man:systemd-sysv-generator(8)
 +  Process: 7619 ExecStart=/etc/init.d/chilli start (code=exited, status=0/SUCCES
 +    Tasks: 1 (limit: 1108)
 +   CGroup: /system.slice/chilli.service
 +           └─7706 /usr/sbin/chilli -c /etc/chilli.conf
  
-May 23 13:17:01 RADIUSdesk-Beta1-1 CRON[2427]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly) +Dec 21 03:05:26 osboxes systemd[1]: Started LSB: Start CoovaChilli daemon at boo 
-May 23 13:18:28 RADIUSdesk-Beta1-1 coova-chilli[2109]: chilli.c: 5511: DHCP Released MAC=08-00-27-90-61-AE IP=10.1.0.2 +Dec 21 03:05:26 osboxes chilli[7706]: PID 7706 saving options to /var/run/chilli 
-May 23 13:20:48 RADIUSdesk-Beta1-1 crontab[2444]: (root) LIST (root) +Dec 21 03:05:26 osboxes chilli[7706]: PID 7706 loading binary options file /var/ 
-May 23 13:20:48 RADIUSdesk-Beta1-1 crontab[2446]: (root) REPLACE (root) +Dec 21 03:05:26 osboxes chilli[7706]: Loading modules 
-May 23 13:20:48 RADIUSdesk-Beta1-1 coova-chilli[2109]: chilli.c: 7544: CoovaChilli shutting down +Dec 21 03:05:26 osboxes chilli[7706]: CoovaChilli 1.4. Copyright 2002-2005 Mondr 
-May 23 13:20:48 RADIUSdesk-Beta1-1 coova-chilli[2448]: main-script.c: 94: Running /etc/chilli/down.sh (107/0) +Dec 21 03:05:26 osboxes chilli[7706]: TX queue length set to 100 
-May 23 13:20:51 RADIUSdesk-Beta1-1 coova-chilli[2561]: CoovaChilli(ChilliSpot) 1.3.0. Copyright 2002-2005 Mondru AB. Licensed under GPL. Copyright 2006-2012 David Bird (Coova Technologies) <support@coova.com>. Licensed under GPL. See http://www.coova.org/ for details. +Dec 21 03:05:26 osboxes coova-chilli[7713]: PID 7713 loading binary options file 
-May 23 13:20:51 RADIUSdesk-Beta1-1 coova-chilli[2561]: tun.c: 605: TX queue length set to 100 +Dec 21 03:05:26 osboxes coova-chilli[7713]: Loading modules 
-May 23 13:20:51 RADIUSdesk-Beta1-1 coova-chilli[2563]: main-script.c: 94: Running /etc/chilli/up.sh (0/0) +Dec 21 03:05:26 osboxes coova-chilli[7713]: USER root(0/0), GROUP root(0/0) CHIL 
-May 23 13:21:01 RADIUSdesk-Beta1-1 cron[809]: (root) RELOAD (crontabs/root) +Dec 21 03:05:26 osboxes coova-chilli[7713]: Running /etc/chilli/up.sh (0/0)
 ....... .......
 </code> </code>
  
-===== Making things permanent ===== +  * Reboot the system and make sure CoovaChilli started up fine 
-  * Ensure that CoovaChilli will start up after reboots.+ 
 +===== Troubleshooting tips ===== 
 +  * When things does not work is can be a bit tricky to figure out which part does not work. 
 +  * It might help if you see the captive portal as a mini router with a WAN side and a LAN side. 
 +  * So then there are a couple of important things to check. 
 + 
 +==== Are you getting an IP address ==== 
 +  * The captive portal also serve as a DHCP server and a device connecting to it with DHCP enabled should get an IP address from it. 
 +  * You can check both sides (server and client) 
 +  * To check on the server issue the following command.
 <code bash> <code bash>
-sudo update-rc.d chilli start 99 2 3 4 5 . stop 20 0 1 6 .+sudo chilli_query list 
 +08-00-27-54-A5-85 10.1.0.3 dnat 157706717100000002 0 08-00-27-54-A5-85 0/0 0/0 0/0 0/0 0 0 0/0 0/0 - 
 +08-00-27-8C-D3-32 10.1.0.2 dnat 157706713900000001 0 08-00-27-8C-D3-32 0/0 0/0 0/0 0/0 0 0 0/0 0/0 -
 </code> </code>
-  * Reboot the system and make sure CoovaChilli started up fine+  * You can read more about the **chilli_query** command here: [[https://coova.github.io/CoovaChilli/chilli_query(1).html|Chilli Query]] 
 +  * After consulting the documentation we can conclude that the captive portal has two clients connected but none has been authenticated. 
 +  * This means that they 'should' be redirected to a login page. 
 +  * If you are not redirected to a login page we can try the following procedure which basically comes down to two things that is not working as intended. 
 +        * The routing between the LAN and WAN is not working correct. 
 +        * The DNS on the setup is not working correct. 
 + 
 +==== Forcing the login page to display ==== 
 +  * CoovaChilli has a special URL which will log you out and redirect you to the login page. 
 +  * The URL is http://1.0.0.0 
 +  * If you do get a login page you can next try to test the routing and the DNS. 
 + 
 +==== Test the routing  ==== 
 +  * To test the routing you can use the chilli_query command and manually authorize the client. 
 +<code bash> 
 +#Show the current list 
 +sudo chilli_query list 
 +08-00-27-54-A5-85 10.1.0.3 dnat 157706717100000002 0 08-00-27-54-A5-85 0/0 0/0 0/0 0/0 0 0 0/0 0/0 http://detectportal.firefox.com/success.txt 
 +08-00-27-8C-D3-32 10.1.0.2 dnat 157706713900000001 0 08-00-27-8C-D3-32 0/0 0/0 0/0 0/0 0 0 0/0 0/0 - 
 +#Authorize the client we want to test 
 + sudo chilli_query authorize ip 10.1.0.3 
 +#Note how 'dnat' now changed to 'pass' and the 5th field changed from 0 to 1 
 +system@osboxes:~$ sudo chilli_query list 
 +08-00-27-54-A5-85 10.1.0.3 pass 157706717100000002 1 08-00-27-54-A5-85 6/0 0/0 7073/0 3253/0 0 0 0%/0 0%/0 http://detectportal.firefox.com/success.txt 
 +08-00-27-8C-D3-32 10.1.0.2 dnat 157706713900000001 0 08-00-27-8C-D3-32 0/0 0/0 0/0 0/0 0 0 0/0 0/0 - 
 +</code> 
 +  * On the client you can now try to go to an IP Address that is reachable on the WAN side. I tried to get to the IP Address of my DSL router (192.168.1.1) and could reach it. This means that the traffic flow between the LAN of my captive portal to the LAN of the captive portal is fine. 
 +  * I can now again log this client off using the chilli_query command 
 +<code bash> 
 +sudo chilli_query logoff ip 10.1.0.3 
 +#'pass' changed again back to 'dnat' 
 +system@osboxes:~$ sudo chilli_query list 
 +08-00-27-54-A5-85 10.1.0.3 dnat 157706939200000002 0 08-00-27-54-A5-85 0/0 0/0 460326/0 146821/0 0 0 0/0 0/0 http://detectportal.firefox.com/success.txt 
 +08-00-27-8C-D3-32 10.1.0.2 dnat 157706713900000001 0 08-00-27-8C-D3-32 0/0 0/0 0/0 0/0 0 0 0/0 0/0 - 
 +</code> 
 +  * Next we will test DNS 
 + 
 +==== Test the DNS  ==== 
 +  * DNS traffic has to flow regardless of a client being authurised (pass) or not (dnat). 
 +  * In order for the client to magically pop up the login page, DNS has also to work correct. 
 +  * A common problem is that sometimes the client has their own DNS servers specified and then (depending on the configuration settings of CoovaChilli) it might not allow the DNS traffic to those server through. (Leaving things broken). 
 +  * After you confirmed that the client does not have any hard defined DNS servers you can try a ping test. 
 +  * With a ping test you just want to test and confirm that the DNS is working correct on the client. 
 +  * You can try and ping any known FQDN and see if the system resolve that to an IP address. 
 +  * Here I try to ping www.radiusdesk.com. As you can see the name resolution worked correct, but since I am not yet authorized (still in dnat state) the pings are not going through which is fine. 
 +<code bash> 
 +ping www.radiusdesk.com 
 +PING radiusdesk.com (164.160.91.12) 56(84) bytes of data. 
 +^C 
 +--- radiusdesk.com ping statistics --- 
 +2 packets transmitted, 0 received, 100% packet loss, time 1025ms 
 +</code> 
 + 
 +==== Conclusion  ==== 
 +  * By using these check points on the captive portal setup, you can now point to a component which does not work as intended and try to resolve it. 
 +        * Be it the login page. 
 +        * The routing between WAN and LAN. 
 +        * The DNS service. 
Last modified: 2019/12/21 04:34