[Chilli] CoovaChilli Kernel Mode issue

Wed Apr 9 09:14:43 UTC 2014

Hi Steffen,

We did tcpdumps on the Coova's tunnel interface and on clients. We found many duplicate acknowledgements and "TCP Previous segment lost" messages before the server sent reset packets to the client.

20:50:26.524474 IP 192.168.99.2.34415 > 192.168.99.1.3990: Flags [S], seq 2120304631, win 14600, options [mss 1460,sackOK,TS val 14568535 ecr 0,nop,wscale 3], length 0
20:50:26.524499 IP 192.168.99.1.3990 > 192.168.99.2.34415: Flags [S.], seq 3365942092, ack 2120304632, win 14480, options [mss 1460,sackOK,TS val 3557659 ecr 14568535,nop,wscale 3], length 0
20:50:26.529791 IP 192.168.99.2.34415 > 192.168.99.1.3990: Flags [.], ack 1, win 1825, options [nop,nop,TS val 14568535 ecr 3557659], length 0
20:50:26.530550 IP 192.168.99.2.34415 > 192.168.99.1.3990: Flags [.], ack 1, win 1825, options [nop,nop,TS val 14568535 ecr 3557659], length 0
20:50:26.531265 IP 192.168.99.2.34416 > 192.168.99.1.3990: Flags [S], seq 2564554410, win 14600, options [mss 1460,sackOK,TS val 14568536 ecr 0,nop,wscale 3], length 0
20:50:26.531286 IP 192.168.99.1.3990 > 192.168.99.2.34416: Flags [S.], seq 1593443429, ack 2564554411, win 14480, options [mss 1460,sackOK,TS val 3557661 ecr 14568536,nop,wscale 3], length 0
20:50:26.531548 IP 192.168.99.2.34416 > 192.168.99.1.3990: Flags [.], ack 933068581, win 1825, options [nop,nop,TS val 14568536 ecr 3557660], length 0
20:50:26.531563 IP 192.168.99.1.3990 > 192.168.99.2.34416: Flags [R], seq 2526512010, win 0, length 0
20:50:26.532146 IP 192.168.99.2.34416 > 192.168.99.1.3990: Flags [P.], seq 1:683, ack 933068581, win 1825, options [nop,nop,TS val 14568537 ecr 3557660], length 682
20:50:26.532158 IP 192.168.99.1.3990 > 192.168.99.2.34416: Flags [R], seq 2526512010, win 0, length 0

Regards,
Phyo Wai Soe

----- Original Message -----
From: "Steffen Dettmer" <steffen.dettmer at nomadrail.com>
To: "Phyo Wai Soe" <phyo.w.soe at frontiir.net>, "Tariq Ramadan" <tr23101 at yahoo.com>
Cc: chilli at coova.org
Sent: Wednesday, April 9, 2014 2:14:56 PM
Subject: AW: [Chilli] CoovaChilli Kernel Mode issue

Hi,

Duplication of packets related to the redirect? Normally I would assume they shouldn't matter, because the redirect is HTTP via TCP and TCP shouldn't have any issue with packet duplication.

What indications did you found for duplication?

Also I think I verified that the kernel module does not forward such unauthorized traffic, for the kernel each packet sent by Coova on the tun should be a new packet, so I don't think firewall state (conntrack or such) is a hot candidate, either...

Steffen

-----Ursprüngliche Nachricht-----
Von: Phyo Wai Soe [mailto:phyo.w.soe at frontiir.net] 
Gesendet: Dienstag, 8. April 2014 04:58
An: Tariq Ramadan
Cc: Steffen Dettmer; chilli at coova.org
Betreff: Re: [Chilli] CoovaChilli Kernel Mode issue

Hi Tariq,

We think that the issue arises from packet duplication between kernel and user space modules. The fact that so many of us are having the issue probably mean that the issue exists and packet routing rules need to be revised. I hope the next version of Coova addresses this.

Regards,
Phyo Wai Soe

----- Original Message -----
From: "Tariq Ramadan" <tr23101 at yahoo.com>
To: "Phyo Wai Soe" <phyo.w.soe at frontiir.net>, "Steffen Dettmer" <steffen.dettmer at nomadrail.com>
Cc: chilli at coova.org
Sent: Tuesday, April 8, 2014 12:53:14 AM
Subject: Re: [Chilli] CoovaChilli Kernel Mode issue

Hi,
I also have the similar problem which I wrote today: http://lists.coova.org/pipermail/chilli/2014-April/002657.html
I tried the patches on 3 december(http://lists.coova.org/pipermail/chilli/2013-December/002489.html), but it doesn't change. Have you solved your problem?

Thanks.

On Friday, December 6, 2013 1:20 PM, Phyo Wai Soe <phyo.w.soe at frontiir.net> wrote:

Hi Steffen,

Your reply does give me some comfort :) . I have tried almost all the things you suggested. When we analyzed traffics on tun0 and eth0 of clients and the server with Wireshark, we saw some fishy things that may or may not indicate issues. Other possible sources of failure we are looking at are the kernel version we are using (Ubuntu 12.04) and the fact that we are running them on virtual machines. Maybe all they are needing are the patches you suggested on 3 Dec :)

Thanks.

Regards,
Phyo Wai Soe

----- Original Message -----
From: "Steffen Dettmer" <steffen.dettmer at nomadrail.com>
To: "Phyo Wai Soe" <phyo.w.soe at frontiir.net>, chilli at coova.org
Sent: Wednesday, December 4, 2013 11:18:00 PM
Subject: RE: CoovaChilli Kernel Mode issue

Hi,

because it seems no one knew how to solve, I try to add my experiences, but unfortunately I can only say that I had a very similar situation and didn't solve it.

> Phyo Wai Soe, November 28, 2013 12:36 PM I saw your mails to the list 
> regarding the redir error message and hoped I could get some clues. So 
> far, I am still stuck :( In my case, when I see redir_read messages in 
> the server's syslog, it normally means that clients see "The 
> connection was reset" error in their browsers and can't go anywhere. 
> They don't even see the "redirecting" message with the animated circle 
> (www/wait.gif).

I did some performance tests with kernel mode Coova (but not using the original Coova Portal), but I also was not able to get the redirects working. To progress, I manually authorized test clients using chilli_query command line commands, as you did :)

> I tried different config settings. If I make HS_UAMLISTEN address in 
> the same range as HS_NETWORK, clients do see redirection/login pages 
> but that's all.

I think, following Davids annoucement mail, in main.conf "net"
should be e.g. in 10.1.1.0 and uamlisten e.g. 11.1.1.0. The up.sh script generates different iptables rules; I think in your case the traffic to the login page could even be passing by coova.

> I don't see any record in /proc/net/coova/chilli (which should happen 
> if the kernel module mode is on)

I think only authorized clients appear here.

> or issue authorize, log out, etc., commands on the server with 
> chilli_query. It's as if the commands don't have any effect on the 
> clients.

I simply manually called chilli_query on shell command line to authenticate my clients, then they appeared in the /proc file output. I think this is expected: Coova handles all non-authorized traffic. Sorry that I don't know why it is not working for the redirects.

> However, if I make HS_UAMLISTEN address to be on another network range 
> like David mentioned, clients get that connection reset error. But 
> /proc/net/coova/chilli is populated and if I manually authorize a 
> client, he/she can browse the web.

Do the counters of the -m coova firewall rules increase (e.g.
iptables-save -c)? If so, I think this proves the kernel module is working (it matches packets, which then are routed by the kernel). Maybe verify with "killall -STOP chilli", but I didn't try.

> It's possible that there is a config problem or the NAT between 
> UAMLISTEN and DHCPLISTEN has a issue. I am trying out all possible 
> things I can think of but so far, I am not getting it right.

The portal I used responded with a redirect - to the current URL.
I thought it could be cause by the fact, that the client network is within 10/8 as a "default" config may assume, but from 11/8, because Coova performs some SNAT (?) of unauthorized clients. I think you already tried, traced and verified that. Maybe it helps to use a browser debugger like Firebug and check "Network" to see what happens or even better tcpdump -w + Wireshark the traffic; maybe the redirect works, but not the portal as in my case?

Sorry that I couldn't help you, but at least you know you are not the only one who had such an issue :-)

Regards,
Steffen

_______________________________________________
Chilli mailing list
Chilli at coova.org
http://lists.coova.org/cgi-bin/mailman/listinfo/chilli