[Chilli] CoovaChilli Kernel Mode issue

Steffen Dettmer steffen.dettmer at nomadrail.com
Wed Apr 9 07:39:53 UTC 2014


Hi,

no, I didn't look any further, so far the performance gain seemed not big enough to satisfy the efforts. Coova still captures all traffic in user land, it is only the "sending" that is "moved" to kernel. I didn't see a way to configure around this (Linux raw captures get traffic regardless of firewall rules, also tried a few other things).
About the redirect, I think there is some missing bit, either in configuration, in Chilli or the used Portal; the latter could not know about the 10/8 vs. 11/8 NAT "trick" that is used in this setup. After checking HTTP traffic (to see what really happens) I think this (portal) is where I would start looking.

Steffen

Von: Tariq Ramadan [mailto:tr23101 at yahoo.com]
Gesendet: Montag, 7. April 2014 20:23
An: Phyo Wai Soe; Steffen Dettmer
Cc: chilli at coova.org
Betreff: 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<mailto: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<mailto:steffen.dettmer at nomadrail.com>>
To: "Phyo Wai Soe" <phyo.w.soe at frontiir.net<mailto:phyo.w.soe at frontiir.net>>, chilli at coova.org<mailto: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<mailto:Chilli at coova.org>
http://lists.coova.org/cgi-bin/mailman/listinfo/chilli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20140409/d1efcc51/attachment.html>


More information about the Chilli mailing list