Differences

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

--- getting_started:18_install_ubuntu_coovachilli [2019/12/21 05:50] – [Add NAT support] admin
+++ getting_started:18_install_ubuntu_coovachilli [2019/12/23 12:27] (current) – [Installing CoovaChilli] admin
@@ Line 25: / Line 25: @@
 <code bash>
+# If you downloaded with wget
 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/
@@ Line 179: / Line 182: @@
 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 routers
+#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
@@ Line 214: / Line 217: @@
   * Restart CoovaChilli for the latest changes to be effected.
 <code bash>
-sudo systemctl daemon-reload
 sudo systemctl stop chilli
 sudo systemctl status chilli
@@ Line 248: / Line 250: @@
   * Reboot the system and make sure CoovaChilli started up fine
+===== 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>
+sudo chilli_query list
+-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 -
+-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>
+  * 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
+-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
+-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
+-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
+-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
+-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
+-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 ---
+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.

RADIUSdesk

Page Tools

Site Tools

User Tools

Differences