[Chilli] CoovaChilli Kernel Mode issue

Steffen Dettmer steffen.dettmer at nomadrail.com
Wed Apr 9 07:44:56 UTC 2014


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


More information about the Chilli mailing list