[Chilli] CoovaChilli Kernel Mode issue

Phyo Wai Soe phyo.w.soe at frontiir.net
Fri Nov 29 02:25:40 UTC 2013


Hi Xabier,

I am using the default rules (ie., up.sh writes the rules on CoovaChilli startup). With the kernel module mode on, the rules are as follows (eth0 is the WAN and eth1 is the DHCP interface):

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            coova: name: chilli side: dest 
ACCEPT     all  --  anywhere             anywhere            coova: name: chilli side: source

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
--------------------------------------
iptables -S

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o eth1 -m coova --name chilli --dest  -j ACCEPT
-A FORWARD -i eth1 -m coova --name chilli --source  -j ACCEPT
-------------------------------------
Thank you.

Regards,
Phyo Wai Soe

----- Original Message ----- 
From: "Xabier Oneca -- xOneca" <xoneca at gmail.com> 
To: "Phyo Wai Soe" <phyo.w.soe at frontiir.net>, chilli at coova.org 
Sent: Friday, November 29, 2013 6:06:25 AM 
Subject: Re: [Chilli] CoovaChilli Kernel Mode issue 


Hello Phyo, 
> I am following these instructions from David on how to enable the kernel module. http://lists.coova.org/pipermail/chilli/2010-April/001239.html 
> 
> According to him, "Chilli is then also configured with 'uamlisten' of 11.0.0.1 and 
> this is the IP address that gets assigned to tun0 (so note that 
> dhcplisten and uamlisten are different!). The high level concept is that 
> subscribers get a 10.1.0.0/24 IP address which is routed (when 
> authenticated) through the kernel." 
> 
> So, I guess my setup is ok. 
Yes, you're right. Sorry! I didn't know about kernel-module-specific configuration quirks... 

> Btw, when I looked at the syslogs, I saw the following lines when the clients got the resetting issue. 
> 
> redir.c: 2020: 104 (Connection reset by peer) redir_read(0) failed! 
> 
> Doing tcpdump on a client (10.99.0.30) when the issue occurred gave me the followings. 
> ======================== 
> 16:54:09.921330 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 
> 192.168.99.1.3990 > 10.99.0.30.57235: Flags [R], cksum 0xcb11 (correct), seq 2598775956, win 0, length 0 
> 16:54:09.922202 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 
> 10.99.0.30.57235 > 192.168.99.1.3990: Flags [R], cksum 0xb372 (correct), seq 524533718, win 0, length 0 
> 16:54:09.922646 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 
> 10.99.0.30.57235 > 192.168.99.1.3990: Flags [R], cksum 0xb372 (correct), seq 524533718, win 0, length 0 
> =============== 
> I think it probably indicates that the server ( 192.168.99.1:3990 ) is resetting the connections even before showing the redirection page. 
Maybe it has to do with your iptables rules. What rules are you applying? Cheers, 

Xabier Oneca_,,_ 


More information about the Chilli mailing list