search

pihomeserver / Kupiki-Hotspot-Script

Create automatically a full Wifi Hotspot on Raspberry Pi including a Captive Portal
Other
305 stars 119 forks source link

JSON request times out #60

Closed Alphatester42 closed 7 years ago

Alphatester42 commented 7 years ago

I am uncertain if this is a bug or not, but I am encountering the following error:

Connecting to aptest, I can get to the captive portal, but I only get a spinner. It does not show login fields, then after a short period the webpage errors out: "The last contact with the Controller failed. Error code =JSON request timed out (or reply is not valid)"

Is this something that I am doing wrong, or is this an issue with the RPI and a compatibility with the build?

Thanks!! :-)

---- technical details ----

chilli debug shows: cb_redir_getstate(2844): did not find 192.168.100.1

running RPI v3 with built in wlan0 and a dlink wlan1 root@aptest:~/scripts# uname -a Linux aptest 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux

root@aptest:~/scripts# lsusb Bus 001 Device 006: ID 062a:0001 Creative Labs Notebook Optical Mouse Bus 001 Device 005: ID 045e:00b4 Microsoft Corp. Digital Media Keyboard 1.0A Bus 001 Device 004: ID 2001:3c20 D-Link Corp. Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@aptest:~/scripts# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination
DROP all -- anywhere anywhere
ACCEPT icmp -- anywhere 192.168.100.1
ACCEPT udp -- anywhere 192.168.100.1 udp dpt:domain ACCEPT udp -- anywhere 192.168.100.1 udp dpts:bootps:bootpc ACCEPT udp -- anywhere 255.255.255.255 udp dpts:bootps:bootpc ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:https ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:4990 ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:3990 DROP all -- anywhere 192.168.100.1
ACCEPT tcp -- anywhere 192.168.1.35 tcp dpt:https DROP all -- anywhere 192.168.1.35

Chain FORWARD (policy ACCEPT) target prot opt source destination
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT) target prot opt source destination

CONFIG DETAILS:

root@aptest:/home/pi# cat /etc/chilli/defaults |grep -v "^#"|sort -u

HS_COAPORT=3799 HS_DNS1=208.67.222.222 HS_DNS2=208.67.220.220 HS_LANIF=wlan0 # Subscriber Interface for client devices HS_LOC_NAME="APTest" # WISPr Location Name and used in portal HS_MODE=hotspot HS_NASID=nas01 HS_NETMASK=255.255.255.0 # HotSpot Network Netmask HS_NETWORK=192.168.100.0 # HotSpot Network (must include HS_UAMLISTEN) HS_PROVIDER=Coova HS_PROVIDER_LINK=http://coova.github.io/ HS_RADIUS2=localhost HS_RADIUS=localhost HS_RADSECRET=testing123 # Set to be your RADIUS shared secret HS_SSID=APTest # To send to the captive portal HS_TCP_PORTS="443" HS_TYPE=coovachilli HS_UAMALIASNAME=chilli HS_UAMALLOW=192.168.100.0/24 HS_UAMFORMAT=https://192.168.100.1:443 HS_UAMHOMEPAGE=$HS_UAMFORMAT HS_UAMLISTEN=192.168.100.1 # HotSpot IP Address (on subscriber network) HS_UAMPORT=3990 # HotSpot UAM Port (on subscriber network) HS_UAMSECRET= # Set to be your UAM secret HS_UAMSERVER=$HS_UAMLISTEN HS_UAMUIPORT=4990 # HotSpot UAM "UI" Port (on subscriber network, for embedded portal) HS_WANIF=wlan1 # WAN Interface toward the Internet HS_WWWBIN=/etc/chilli/wwwsh HS_WWWDIR=/etc/chilli/www

root@aptest:~/scripts# more kupiki-hotspot-script.sh

Name of the log file LOGNAME="aptest.log" Path where the logfile will be stored be sure to add a / at the end of the path LOGPATH="/var/log/" Password for user root (MySql/MariaDB not system) MYSQL_PASSWORD="aaaaaaaa" Name of the hotspot that will be visible for users/customers HOTSPOT_NAME="aptest" IP of the hotspot HOTSPOT_IP="192.168.100.1" Use HTTPS to connect to web portal Set value to Y or N HOTSPOT_HTTPS="N" Network where the hotspot is located HOTSPOT_NETWORK="192.168.100.0" Secret word for CoovaChilli COOVACHILLI_SECRETKEY="bbbbb" Secret word for FreeRadius FREERADIUS_SECRETKEY="ccccc" WAN interface (the one with Internet - default 'eth0' or long name for Debian 9+) WAN_INTERFACE=ip link show | grep '^[1-9]' | awk -F ':' '{print $2}' | awk '{$1=$1};1' | grep '^e' (Note:WAN_INTERFACE="wlan1") LAN interface (the one for the hotspot) LAN_INTERFACE="wlan0" Wifi driver LAN_WIFI_DRIVER="nl80211" Install Haserl (required if you want to use the default Coova Portal) Set value to Y or N HASERL_INSTALL="Y" Password used for the generation of the certificate CERT_PASSWORD="ddddd" Number of days to certify the certificate for (default 2 years) CERT_DAYS="730" Make Avahi optional Set value to Y or N AVAHI_INSTALL="Y" echo "wan = $WAN_INTERFACE" echo "lan = $LAN_INTERFACE";read x

pihomeserver commented 7 years ago

that's because the coova instance is not reachable. be sure that the process is running or that the ip set in the js file of the portal is the ip of the server where coova is running

Alphatester42 commented 7 years ago

I see a coovachilli debugerror: cb_redir_getstate(2844): did not find 192.168.100.1

but the processes look ok to me. I am unclear how nginx front page routes to the /etc/chilli/www site though, or how it references the /etc/chilli/*js scripts though. - I apologise, I am not that strong on web dev, or js. Which js file should I be looking at?

root@aptest:/etc/nginx/sites-enabled# ps -ef |egrep "hostapd|sql|ng|chilli|freerad"

root 793 1 0 16:32 ? 00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; www-data 794 793 0 16:32 ? 00:00:00 nginx: worker process mysql 865 1 0 16:32 ? 00:00:09 /usr/sbin/mysqld freerad 1218 1 0 16:32 ? 00:00:00 /usr/sbin/freeradius chilli 4352 1476 0 17:49 pts/1 00:00:00 chilli --debug --fg

I do see the chillilibrary.js script looks to be using 1.0.0.0 though. not sure if this has anything to do with it.

var chilliController = { interval:30 , host:"1.0.0.1" , port:false , ident:'00' , ssl:false , uamService: false };

Alphatester42 commented 7 years ago

maybe I am misunderstanding what you stated... I don't have any js scripts in the /etc/nginx/. Do I need to copy the js files over from the /etc/chilli/www folder, or does the nginx config redirect to the chilli/www directory somehow on the back end? - again, I apologise for my lack of understanding. I am reading and learning as much as I can. Your help is VERY much appreciated!! - Thank you!!

root@aptest:/etc/nginx# find . |grep js root@aptest:/etc/nginx# <-- nothing...

root@aptest:/etc/nginx# ls -al total 92 drwxr-xr-x 11 root root 4096 Sep 14 22:28 . drwxr-xr-x 126 root root 12288 Sep 17 17:48 .. drwxr-xr-x 2 root root 4096 Sep 14 22:28 certs drwxr-xr-x 2 root root 4096 Sep 14 06:14 certs.last1 drwxr-xr-x 2 root root 4096 Sep 12 20:02 certs.orig drwxr-xr-x 2 root root 4096 Jul 12 05:44 conf.d -rw-r--r-- 1 root root 1077 Jul 12 05:44 fastcgi.conf -rw-r--r-- 1 root root 1007 Jul 12 05:44 fastcgi_params -rw-r--r-- 1 root root 2837 Jul 12 05:44 koi-utf -rw-r--r-- 1 root root 2223 Jul 12 05:44 koi-win -rw-r--r-- 1 root root 3957 Jul 12 05:44 mime.types drwxr-xr-x 2 root root 4096 Jul 12 05:44 modules-available drwxr-xr-x 2 root root 4096 Sep 12 19:54 modules-enabled -rw-r--r-- 1 root root 1505 Jul 12 05:44 nginx.conf -rw-r--r-- 1 root root 180 Jul 12 05:44 proxy_params -rw-r--r-- 1 root root 636 Jul 12 05:44 scgi_params drwxr-xr-x 2 root root 4096 Sep 17 18:34 sites-available drwxr-xr-x 2 root root 4096 Sep 15 16:32 sites-enabled drwxr-xr-x 2 root root 4096 Sep 12 19:47 snippets -rw-r--r-- 1 root root 664 Jul 12 05:44 uwsgi_params -rw-r--r-- 1 root root 3071 Jul 12 05:44 win-utf

root@aptest:/etc/nginx/sites-available# cat portal

server { listen 192.168.100.1:80 default_server; root /usr/share/nginx/portal; index index.html; servername ; location / { try_files $uri $uri/ =404; } location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; } }

pihomeserver commented 7 years ago

No the js file is /usr/share/nginx/portal/js/portal.js

    chilliController.host = "192.168.10.1";
    chilliController.port = "3990";
    chilliController.interval = 60;

Where 192.168.10.1 should have been replaced by your coova ip if different, the one set by HOTSPOT_IP defined at the beginning of the script. That's how the portal connects to Coova. In your case it seems that it should be 192.168.100.1

Also i see a rule in your iptable : 

ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:https

I think that's why it does not work. It should be for http. Can you please check that in /etc/chilli/up.sh you have (3 lines before the end) port 80 and not 443 ? 

    ipt -A INPUT -i $TUNTAP -d $LOCAL_IP -p tcp -m tcp --dport 80 -j ACCEPT
Alphatester42 commented 7 years ago

The portal.js script has the proper ip address in it. so that looks correct. I think you are right about the iptables though! I am missing that line. I will add it in and test.

root@aptest:/usr/share/nginx/portal/js# ls bootstrap.min.js ChilliLibrary.js jquery.min.js portal.js root@aptest:/usr/share/nginx/portal/js# grep 192.168 * portal.js: chilliController.host = "192.168.100.1";

--- start cut ---

root@aptest:/etc/chilli# cat up.sh

!/bin/sh

TUNTAP=$(basename $DEV) UNDO_FILE=/var/run/chilli.$TUNTAP.sh

. /etc/chilli/functions

[ -e "$UNDO_FILE" ] && sh $UNDO_FILE 2>/dev/null rm -f $UNDO_FILE 2>/dev/null

ipt() { opt=$1; shift echo "iptables -D $" >> $UNDO_FILE iptables $opt $ }

ipt_in() { ipt -I INPUT -i $TUNTAP $* }

run_up() { if [ -n "$TUNTAP" ] then

ifconfig $TUNTAP mtu $MTU

if [ "$KNAME" != "" ]
then
    ipt -I FORWARD -i $DHCPIF -m coova --name $KNAME -j ACCEPT 
    ipt -I FORWARD -o $DHCPIF -m coova --name $KNAME --dest -j ACCEPT
    ipt -I FORWARD -i $TUNTAP -j ACCEPT
    ipt -I FORWARD -o $TUNTAP -j ACCEPT
    [ -n "$DHCPLISTEN" ] && ifconfig $DHCPIF $DHCPLISTEN
else
    if [ "$LAYER3" != "1" ]
    then
    ipt_in --dst $ADDR -j DROP

    [ -n "$UAMPORT" -a "$UAMPORT" != "0" ] && \
        ipt_in -p tcp -m tcp --dport $UAMPORT --dst $ADDR -j ACCEPT

    [ -n "$UAMUIPORT" -a "$UAMUIPORT" != "0" ] && \
        ipt_in -p tcp -m tcp --dport $UAMUIPORT --dst $ADDR -j ACCEPT

    [ -n "$HS_TCP_PORTS" ] && {
        for port in $HS_TCP_PORTS; do
        ipt_in -p tcp -m tcp --dport $port --dst $ADDR -j ACCEPT
        done
    }

    [ -n "$HS_UDP_PORTS" ] && {
        for port in $HS_UDP_PORTS; do
        ipt_in -p udp -m udp --dport $port --dst $ADDR -j ACCEPT
        done
    }

    ipt_in -p udp -d 255.255.255.255 --destination-port 67:68 -j ACCEPT
    ipt_in -p udp -d $ADDR --destination-port 67:68 -j ACCEPT
    ipt_in -p udp --dst $ADDR --dport 53 -j ACCEPT
    ipt_in -p icmp --dst $ADDR -j ACCEPT

    if [ "$ONLY8021Q" != "1" ]
    then
        ipt -I INPUT -i $DHCPIF -j DROP
    fi
    fi

    if [ "$ONLY8021Q" != "1" ]
    then
    ipt -I FORWARD -i $DHCPIF -j DROP
    ipt -I FORWARD -o $DHCPIF -j DROP
    fi

    ipt -I FORWARD -i $TUNTAP -j ACCEPT
    ipt -I FORWARD -o $TUNTAP -j ACCEPT

        # Help out conntrack to not get confused
        # (stops masquerading from working)
        #ipt -I PREROUTING -t raw -j NOTRACK -i $DHCPIF
        #ipt -I OUTPUT -t raw -j NOTRACK -o $DHCPIF

        # Help out MTU issues with PPPoE or Mesh
    ipt -I FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    ipt -I FORWARD -t mangle -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

    [ "$HS_LAN_ACCESS" != "on" -a "$HS_LAN_ACCESS" != "allow" ] && \
    ipt -I FORWARD -i $TUNTAP \! -o $HS_WANIF -j DROP

    ipt -I FORWARD -i $TUNTAP -o $HS_WANIF -j ACCEPT

    [ "$HS_LOCAL_DNS" = "on" ] && \
    ipt -I PREROUTING -t nat -i $TUNTAP -p udp --dport 53 -j DNAT --to-destination $ADDR
fi
fi

# site specific stuff optional
[ -e /etc/chilli/ipup.sh ] && . /etc/chilli/ipup.sh

}

FLOCK=$(which flock) if [ -n "$FLOCK" ] && [ -z "$LOCKED_FILE" ] then export LOCKED_FILE=/tmp/.chilli-flock flock -x $LOCKED_FILE -c "$0 $@" else run_up fi ipt -I POSTROUTING -t nat -o $HS_WANIF -j MASQUERADE LOCAL_IP=ifconfig $HS_WANIF | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1' ipt -C INPUT -i $TUNTAP -d $LOCAL_IP -j DROP if [ $? -ne 0 ] then ipt -A INPUT -i $TUNTAP -d $LOCAL_IP -p tcp -m tcp --dport 443 -j ACCEPT ipt -A INPUT -i $TUNTAP -d $LOCAL_IP -j DROP fi

--- end cut ---

Alphatester42 commented 7 years ago

Kupiki-hotspot-script:

HOTSPOT_NAME="aptest" IP of the hotspot: HOTSPOT_IP="192.168.100.1"

I added the line to up.sh:

then ipt -A INPUT -i $TUNTAP -d $LOCAL_IP -p tcp -m tcp --dport 443 -j ACCEPT ipt -A INPUT -i $TUNTAP -d $LOCAL_IP -p tcp -m tcp --dport 80 -j ACCEPT ipt -A INPUT -i $TUNTAP -d $LOCAL_IP -j DROP fi

When I restarted coova, iptables had added the new rule to the .1.35 address, not the .100.1 address:

ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:https ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:4990 ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:3990 DROP all -- anywhere 192.168.100.1
ACCEPT tcp -- anywhere 192.168.1.35 tcp dpt:https ACCEPT tcp -- anywhere 192.168.1.35 tcp dpt:http <--- added DROP all -- anywhere 192.168.1.35

still fails though...

I do see in the cfg.bin file that it is referencing port 443. I think that coova thinks that the service is running under https for some reason.

root@aptest:/etc/chilli# strings /var/run/chilli.6844.cfg.bin /var/run/chilli.6844.cfg.bin /var/run/chilli.wlan0.pid 192.168.100.0/255.255.255.0 /etc/chilli/up.sh /etc/chilli/down.sh testing123 nas01 isocc=,cc=,ac=,network=Coova,aptest aptest aptest testing123 wlan0 http://192.168.100.1:3990/prelogin https://192.168.100.1:443 https://192.168.100.1:443 /etc/chilli/www /etc/chilli/wwwsh chilli.wlan0.ipc /etc/chilli/local.conf aptest /var/run/chilli.wlan0.sock chilli

Alphatester42 commented 7 years ago

I had an old install that I was trying to run under https, but had the same error so I re-ran the script with just http which recompiled coova so I thought that it cleaned all this out.

Alphatester42 commented 7 years ago

Should there be a DROP right at the beginning? that looks to me like it is preventing anything underneath from running...

root@aptest:/home/pi# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere anywhere ACCEPT icmp -- anywhere 192.168.100.1 ACCEPT udp -- anywhere 192.168.100.1 udp dpt:domain ACCEPT udp -- anywhere 192.168.100.1 udp dpts:bootps:bootpc ACCEPT udp -- anywhere 255.255.255.255 udp dpts:bootps:bootpc ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:https ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:4990 ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:3990 DROP all -- anywhere 192.168.100.1 ACCEPT tcp -- anywhere 192.168.1.35 tcp dpt:https ACCEPT tcp -- anywhere 192.168.1.35 tcp dpt:http DROP all -- anywhere 192.168.1.35

Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere DROP all -- anywhere anywhere

Alphatester42 commented 7 years ago

I removed the drop at the beginning, but it still fails... I am thinking that I should rebuild from scratch on a clean OS to start fresh

pihomeserver commented 7 years ago

Try to avoid the HTTPS. My understanding from your stacktrace is that iptables look ok as you allow connection to your coova wlan (192.168.100.1) on the correct ports : 

ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:4990
ACCEPT tcp -- anywhere 192.168.100.1 tcp dpt:3990

Try to update manually the /etc/chilli/defaults file to update and replace 443 with 80 (you have to stop / start the service to regenerate the configuration files)

Do you confirm using the Raspbian Stretch Lite and not the complete edition ?

Soon the web interface will help to configure all of that in a full secure way. I hope.

Alphatester42 commented 7 years ago

I was using raspian stretch complete. I also grabbed another microSD and reinstalled from scratch (with stretch complete), then apt-update/apt-upgrade then ran the coova install script again with no https,but ran into the same issue. I then double checked the iptables, and they looked correct. I will re-image with the lite version and see if that works better.

Alphatester42 commented 7 years ago

Once I installed stretch light then everything worked properly. I had to rebuild from scratch though. Odd as one would think that the dependencies and compiling would be the same between the versions as it is the same build config. Do you know what the difference is that would cause the variance? - headless works well though, an in retrospect is a better choice as it is a cleaner build.