Open nvasa opened 4 years ago
Hi, You can paste the iptables rules.
Hi, I have tested up.sh with original iptable rules as follows for kname=chilli
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
and also tried after adding following: ipt -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ipt -A INPUT -d $ADDR -i $DHCPIF -p tcp -m tcp --dport 3990 -m coova --name chilli -j ACCEPT ipt -N INPUT$TUNTAP ipt -A INPUT$TUNTAP -d $ADDR -i $TUNTAP -p tcp -m tcp --dport 3990 -j ACCEPT ipt -A INPUT$TUNTAP -j RETURN ipt -A INPUT -i $TUNTAP -j INPUT$TUNTAP
ipt -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT ipt -A FORWARD -i $DHCPIF -o $HS_WANIF -m coova --name chilli -j ACCEPT ipt -A FORWARD -i $HS_WANIF -o $DHCPIF -m coova --name chilli --dest -j ACCEPT ipt -A FORWARD -i $TUNTAP -o $HS_WANIF -j ACCEPT ipt -A FORWARD -i $HS_WANIF -o $TUNTAP -j ACCEPT
In both cases, behavior is same as above i.e. not getting success page on browser and no internet connection though chilli passes it as mentioned in above post.
Thanx,
You probably don't want conntrack with xt_coova. I'd remove those lines like:
ipt -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Thanx,
I tried with and without conntrack rules but no difference.
Can you please paste your /etc/chilli/up.sh file please for my reference..?
Looking forward to...
We don't use up.sh.
Can you try changing the default policy on FORWARD to DROP:
iptables -P FORWARD DROP
See if it makes any difference?
Try executing the below line and restart the process.
iptables -I POSTROUTING -t nat -o br-lan -j MASQUERADE
I've same issue with newest version... may i know how to fix the issue?
Coova-Chilli has a lot of bugs... I already spent one week to research and fix the issue...but no luck~ Anyone can help me or give me some suggestions?
... it may have bugs... but working for me.. perfectly!
welcome to the spending hours-days-weeks to try to get it working. I went through the same process.
you'll feel good when you get it working! keep going.. there is light at the end of the tunnel!
My project is multi-https-portals for different subnets. I tried to make it work everyday and spent more than one month ... I met a lot of bugs/problems and bypassed them. It can work without kernel module perfectly now. But I need the kernel module to control the routing and in/out bytes accounting. If I config kname, I typed username/password and auth by radius successfully. /proc/net/coova/chilli 's state become 1 I can't not access uam ip...telnet uam port become fail and no internet. if i change my ip to other ip,i can telnet uam port again.. seems like there is a function to block my traffic from lan interface to tunnel interface if radius auth success.
Hello ,
I have installed xt_coova in order to improve bandwidth issue with chilli on my openwrt router. I have followed all posts of issue#340 and setup chilli config file and iptables accordingly. I have two different IP ranges for DHCP (authorized packets) and tun interface (unauthorized packets).
When i start chilli, my xt_coova getting called properly with up.sh rules. I am getting coova login page also. When i enter correct username and password, chilli passes with UAM login successful message but on browser, i am not getting firefox detect page for success due to timeout and also internet connection is not enabled.
My cat /proc/net/coova/chilli says: mac=7C-5C-F8-3D-7E-8F src=192.168.29.3 state=1 bin=570 bout=0 pin=9 pout=0
Chilli_query list also says that chilli has authorized the user 7C-5C-F8-3D-7E-8F 192.168.29.3 pass 5dd2475300000001 1 613574zenexim 25/27554 0/0 0/0 2814/0 0 0 0%/0 0%/0 http://detectportal.firefox.com/suct
My tun0 is on 192.168.30.1/24 My DHCP interface is on 192.168.29.1/24
Can somebody help ?
Thanx,
Originally posted by @nvasa in https://github.com/coova/coova-chilli/issues/340#issuecomment-554889334