[Chilli] CoovaChilli Kernel Mode issue

[Phyo Wai Soe]

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