[CoovaChilli] Documentation about xt_coova/ipt-coova/nfcoova

Brian Andrews nzamps at gmail.com
Tue Jun 7 10:55:16 BST 2016


Not sure why connections fail to 3990 but you can fix logouts with a rule like:

iptables -I INPUT -i eth0.1 -d 11.1.0.1 -p tcp --dport 3990 -m coova --name chilli -j ACCEPT

-
brian
 

> On 7/06/2016, at 8:16 PM, Pierre Parent <pparent at comminter.com> wrote:
> 
> Hi,
> 
> Sorry concerning the first problem, it's my fault, I had forgotten the --dest 
> option. This iptables works fine.
> iptables -I FORWARD -o eth0.1 -m coova --name chilli --dest  -j ACCEPT
> Sorry to have bothered with this inexistent problem.
> 
> I still have the identification problem: connections very often fails when 
> accessing 11.1.0.1:3990.
> 
> Thanks a lot,
> Pierre.
> 
> Le lundi 6 juin 2016, 17:55:01 Pierre Parent a écrit :
>> Hi,
>> 
>> Thanks a lot for your message.
>> 
>> It kind of works with some iptables, I succeed in getting 100Mbps throughput
>> (instead of 25Mpbs before). But I had to change the iptables described in
>> the link with:
>> 
>> iptables -I FORWARD -i eth0.1 -m coova --name chilli -j ACCEPT
>> iptables -I FORWARD -o eth0.1  -j ACCEPT
>> iptables -I FORWARD -o tun0 -j ACCEPT
>> iptables -I FORWARD -i tun0 -j ACCEPT
>> iptables -A FORWARD -j DROP
>> 
>> iptables -I INPUT -d 11.1.0.1 -j ACCEPT
>> 
>> Notably I had to allow any incoming packet for eth0.1 (lan), without
>> filtering with xt_coova. When Filtering with xt_coova for incoming packet
>> for eth0.1 the rule was never matched, not sure why. I don't know whether
>> using these iptables can be problematic or not. If the user cannot send any
>> packet, routing incoming packets should not allow him to do anything. But
>> this does not seem very normal either.
>> 
>> I still have a big problem, during the authentication process, the TCP
>> connections very often fails, most often when connecting to 11.1.0.1:3990,
>> but also sometimes when connecting to the distant server specified in
>> uamhomepage or at some other point of the identification process. It
>> generally requires 1 to 5 attempts to actually access 11.1.0.1:3900.
>> 
>> I made a packet capture with Wireshark, I see that some packages always flow
>> in both ways (from and to 11.1.0.1), but I see a lot of [TCP previous
>> segment not captured] [TCP Retransmission] [TCP Out-of-Order] [TCP Dup
>> ACK].
>> 
>> Do you have any information about this problem? Also, I have a quick
>> question; is xt_coova supposed to be stable or is it still somewhat
>> experimental?
>> 
>> Thanks in advance!
>> 
>> Pierre.
>> 
>> Ps:
>> I use the version currently used in openwrt: commit
>> b93de20a288c01c2ba28e96e31ad6da01627f45f
>> 
>> Here is my /etc/chilli.conf
>> 
>> radiusserver1   "xxxxxxxx"
>> radiusserver2   "xxxxxxxx"
>> radiussecret    "xxxxxxxx"
>> radiusauthport  1812
>> radiusacctport  1813
>> 
>> # UAM
>> uamserver       "http://xxxxxxxxxx"
>> uamport         3990
>> uamhomepage     http://xxxxxxxxxx/
>> uamlogoutip     1.1.1.1
>> 
>> 
>> net 10.1.0.0/16
>> dynip 10.1.0.0/24
>> statip 10.1.1.0/24
>> 
>> uamlisten 11.1.0.1
>> dhcplisten 10.1.0.1
>> dhcpstart 10
>> uamaliasname chilli
>> ipup=
>> ipdown=
>> 
>> dhcpif eth0.1
>> uamdomain coova.org
>> cmdsock /var/run/chilli.sock
>> kname chilli
>> 
>> uamsecret "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
>> 
>> dns1            "10.1.0.1"
>> 
>> uamdomain
>> www.paypal.com,www.sandbox.paypal.com,www.paypalobjects.com,paypalobjects.co
>> m,paypal.112.2o7.net,developer.paypal.com,evsecure-
>> ocsp.verisign.com,evsecure-crl.verisign.com,102.112.2o7.n
>> uamallowed      0.0.0.0/0:110
>> uamallowed      0.0.0.0/0:143
>> uamallowed      0.0.0.0/0:587
>> uamallowed      0.0.0.0/0:993
>> uamallowed      0.0.0.0/0:995
>> 
>> radiusnasid     xxxxxxxxxxxxxxx
>> nasmac xxxxxxxxxxxxxxxxxxx
>> 
>> redirssl
>> sslkeyfile      /etc/chilli/server.key
>> sslcertfile     /etc/chilli/server.crt
>> 
>> Le mercredi 1 juin 2016, 09:57:35 Brian Andrews a écrit :
>>> Hi Pierre
>>> 
>>> You need a very specific configuration to get kmod-coova/xt_coova to work.
>>> 
>>> You need specific firewall rules and you need to change your ip setup. See
>>> David’s original post here:
>>> 
>>> https://coova.github.io/mail-archive/chilli/2010-April/001239.html
>>> 
>>> There are also some more clues in this thread:
>>> 
>>> https://github.com/coova/coova-chilli/issues/61#issuecomment-139478433
>>> 
>>> -
>>> brian
>>> 
>>>> On 1/06/2016, at 1:42 AM, Pierre Parent <pparent at comminter.com> wrote:
>>>> 
>>>> Hi,
>>>> I'm lacking documentation on how to have chili working with xt_coova.
>>>> I compiled it (in openwrt) with --with-nfcoova option, I have the
>>>> xt_coova
>>>> linux module running, and I don't observe any improvement on
>>>> performances,
>>>> or CPU usage.
>>>> Also lsmod shows that the module xt_coova is not called:
>>>> [...]
>>>> xt_connlimit 3296 0
>>>> xt_connmark 960 3
>>>> xt_conntrack 2064 14
>>>> xt_coova 5312 0
>>>> xt_dscp 928 0
>>>> xt_ecn 1216 0
>>>> xt_helper 800 0
>>>> xt_hl 720 0
>>>> xt_id 400 0
>>>> [...]
>>>> I guess, I must be missing something, but I don't find any documentation
>>>> on how to setup xt-coova. Is there a special option to set in the config
>>>> file, or special iptables to setup?
>>>> Thanks in advance!
>>>> 
>>>> Pierre.
>>>> 
>>>> _______________________________________________
>>>> CoovaChilli mailing list
>>>> CoovaChilli at brightonchilli.org.uk
>>>> https://www.brightonchilli.org.uk/mailman/listinfo/coovachilli
>>> 
>>> _______________________________________________
>>> CoovaChilli mailing list
>>> CoovaChilli at brightonchilli.org.uk
>>> https://www.brightonchilli.org.uk/mailman/listinfo/coovachilli
>> 
>> _______________________________________________
>> CoovaChilli mailing list
>> CoovaChilli at brightonchilli.org.uk
>> https://www.brightonchilli.org.uk/mailman/listinfo/coovachilli
> 
> 
> _______________________________________________
> CoovaChilli mailing list
> CoovaChilli at brightonchilli.org.uk
> https://www.brightonchilli.org.uk/mailman/listinfo/coovachilli



More information about the CoovaChilli mailing list