Open keulu opened 7 years ago
Interesting, you shouldn't see your download limited at all with xt_coova - it is meant to bypass chilli for authenticated users!
I think one problem is due to your use of a bridge, which incidentally I wouldn't recommend unless you use the 'usetap' option. We use the conup/condown scripts to insert tc and iptables rules to enforce rate limits.
Also, I think the issue is you are not using 2 ip ranges for unauthenticated and authenticated users. With xt_coova you have uamlisten on one range and dynip on the other and xt_coova does a DNAT between the two.
e.g. you could have:
192.168.181.0/24 for unauthenticated 192.168.180.0/24 for authenticated
option uamlisten '192.168.181.1'
option net '192.168.180.0/24'
option dynip '192.168.180.0/24'
and your firewall rules should match the auth range only for xt_coova e.g.
iptables -A FORWARD -d 192.168.180.0/24 -i br-if_pub -m coova --name chillipub --dest -j ACCEPT
iptables -A FORWARD -s 192.168.180.0/24 -o br-if_pub -m coova --name chillipub --source -j ACCEPT
iptables -A FORWARD -d 192.168.181.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.181.0/24 -j ACCEPT
Your INPUT rules look like they need some work - you normally have policy DROP and only allow the ports you need e.g. uamport would be:
iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -j ACCEPT
For more see: http://coova.github.io/mail-archive/chilli/2010-April/001239.html
TBH I'm quite surprised your setup works at all - do users get a splash page ok and can login ? Do you see packet counts when you do:
cat /proc/net/coova/chillipub
You might need to change things around quite a bit to get it to work how it was designed!
Cheers Brian
Hi brian, thanks for your amazing explanation and quick answer
I made a mistake for my iptables. INPUT have a DROP POLICY (my bad...) i didn't wrote all my rules because I have huge rules.
SO if i understand well, limitted download shouldn't work... and i need to limit traffic with TC.
Ok i will try this today. I keep you informed.
well well well...
After a long brain torture, i didn't make it work as desired...
with my original config cat /proc/net/coova/chillipub give something like that when i'm connected
root@OpenWRT:~# cat /proc/net/coova/chillipub mac=CC-25-EF-31-3B-75 src=192.168.180.3 state=1 bin=34517448 bout=0 pin=1856 pout=0 root@OpenWRT:~# cat /proc/net/coova/chillipub mac=CC-25-EF-31-3B-75 src=192.168.180.3 state=1 bin=59539525 bout=0 pin=3265 pout=0 root@OpenWRT:~# cat /proc/net/coova/chillipub mac=CC-25-EF-31-3B-75 src=192.168.180.3 state=1 bin=65916093 bout=0 pin=3638 pout=0
no unauthentified users is here. only authentified.
When i reset all my Forward rules and try yours, i didn't match any rules, can't get my portal or splash and /proc/net/coova/chillipub don't exist or stay empty
in your example, you said
192.168.181.0/24 for unauthenticated 192.168.180.0/24 for authenticated
option uamlisten '192.168.181.1' option net '192.168.180.0/24' option dynip '192.168.180.0/24'
when coova detect my device, he give me a 192.168.180.x address.
Well i think i will reset my work and rebuild from scratch all my confs this Week End.
Ty again
Yep, users should get a 192.168.180.x address, the 181.x address is only used by xt_coova (it NATs to it when the user is not authenticated).
I'd try to test without a bridge - e.g. use ethX if available as a bridge can confuse things. Ensure ethX has ip 192.168.180.1/24 (may need to add manually) and the tun or tap (tap for bridge) has 192.168.181.1/24 and you have added all of the INPUT rules for the ports you need and any FORWARD rules for external IPs.
Hope this helps.
hi nzamp,
I've almost done all my new conf but one problem remain.
When i'm not logged, my splash page, portal and all uammallowed/domains works fine. when i'm logged, i can go to the internet. OK great. (without port restriction for now) (/proc/net/coova/chillipub exist and is well powered with bin, bout, pin, pout for my mac)
When i'm not connected, call 192.168.181.1:3990/json/status make an error. the connection was reset. When i click on the connect button, -> connection was reset when i call 192.168.181.1:3990/login?username=xxxx&response=xxxxxxxxxxx&userurl=xxxxxxx -> connection was reset (same for logoff when i'm connected, but it's logout my user with error)
When i'm connected, call 192.168.181.1:3990/json/status work. logoff work too but, don't redirect me to my portal
here are my confs :
cat /etc/config/network
config interface 'loopback'
option proto 'static'
option ifname 'lo'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
option ipv6 '0'
config interface 'coova'
option ifname 'tun11'
option proto 'none'
option defaultroute '0'
option peerdns '0'
option auto '1'
option force_link '1'
option delegate '0'
option ipv6 '0'
config interface 'wan'
option proto 'dhcp'
option ifname 'eth0'
option dns '8.8.8.8 8.8.4.4'
option ipv6 '0'
config interface 'lan'
option ifname 'eth1'
option proto 'static'
option ipaddr '192.168.180.1'
option netmask '255.255.255.0'
option defaultroute '0'
option peerdns '0'
option delegate '0'
option ipv6 '0'
option type 'bridge'
ifconfig
br-lan Link encap:Ethernet HWaddr C0:56:27:B7:FA:0D
inet addr:192.168.180.1 Bcast:192.168.180.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2406 errors:0 dropped:0 overruns:0 frame:0
TX packets:2316 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:351856 (343.6 KiB) TX bytes:681138 (665.1 KiB)
eth0 Link encap:Ethernet HWaddr C2:56:27:B7:FA:0D
inet addr:192.168.6.62 Bcast:192.168.6.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14872 errors:0 dropped:300 overruns:0 frame:0
TX packets:9345 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:2748698 (2.6 MiB) TX bytes:3288096 (3.1 MiB)
Interrupt:194
eth1 Link encap:Ethernet HWaddr C0:56:27:B7:FA:0D
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2406 errors:0 dropped:0 overruns:0 frame:0
TX packets:2338 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:385540 (376.5 KiB) TX bytes:682150 (666.1 KiB)
Interrupt:195
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:616 errors:0 dropped:0 overruns:0 frame:0
TX packets:616 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:42040 (41.0 KiB) TX bytes:42040 (41.0 KiB)
tun11 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.181.1 P-t-P:192.168.181.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:1956 errors:0 dropped:0 overruns:0 frame:0
TX packets:1563 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:290155 (283.3 KiB) TX bytes:496918 (485.2 KiB)
wlan0 Link encap:Ethernet HWaddr 00:25:9C:13:C8:E7
inet6 addr: fe80::225:9cff:fe13:c8e7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:366 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:25568 (24.9 KiB)
wlan1 Link encap:Ethernet HWaddr 00:25:9C:13:C8:E6
inet6 addr: fe80::225:9cff:fe13:c8e6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:368 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:25720 (25.1 KiB)
br-lan is a bridge over eth1, wlan0 and wlan1 but it do exactly the same proglem if i target eth1 and not br-lan
cat /etc/config/chilli
config chilli 'public'
option radiusnasid 'testacopub'
option radiussecret 'xxxxxx'
option radiusserver1 'xxxxxx'
option radiusserver2 'xxxxxx'
option radiusauthport '1812'
option radiusacctport '1813'
option uamserver 'http://xxxxxx'
option uamhomepage 'http://xxxxxx'
option uamsecret 'xxxxxx'
option uamport '3990'
option uamallowed 'xxxxx'
option uamdomain 'xxx,yyy,zzz'
option uamanydns '1'
option uamaliasip '1.0.0.1'
option uamaliasname 'login'
option uamlogoutip '1.1.1.1'
option nouamsuccess '1'
option coaport '3799'
option tundev 'tun11'
option dns1 '8.8.8.8'
option dns2 '8.8.4.4'
option domain 'iwibox.net'
option interval '3600'
option locationname 'test'
option uamlisten '192.168.181.1'
option net '192.168.180.0/24'
option dhcplisten '192.168.180.1'
option dhcpstart '10'
option dhcpif 'br-lan'
option kname 'chillipub'
my simple firewall rules
iptables -t filter -F
iptables -t filter -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p icmp -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8022 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth0 -d 192.168.180.0/24 -j DROP
iptables -A INPUT -i eth0 -d 192.168.181.0/24 -j DROP
iptables -A INPUT -j DROP
iptables -A FORWARD -d 192.168.180.0/24 -m coova --name chillipub --dest -j ACCEPT
iptables -A FORWARD -s 192.168.180.0/24 -m coova --name chillipub -j ACCEPT
iptables -A FORWARD -d 192.168.181.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.181.0/24 -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "IPTables-FORWARD-Dropped: " --log-level 4
iptables -A FORWARD -j DROP
iptables LOG :
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.587064] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=63 TOS=0x00 PREC=0x00 TTL=63 ID=11788 DF PROTO=UDP SPT=48102 DPT=53 LEN=43
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.587126] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6231 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.587160] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=63 TOS=0x00 PREC=0x00 TTL=63 ID=11789 DF PROTO=UDP SPT=48102 DPT=53 LEN=43
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.591260] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=11790 DF PROTO=UDP SPT=49571 DPT=53 LEN=47
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.591302] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=11791 DF PROTO=UDP SPT=49571 DPT=53 LEN=47
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.591342] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=61 TOS=0x00 PREC=0x00 TTL=63 ID=11792 DF PROTO=UDP SPT=38401 DPT=53 LEN=41
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.591370] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=8.8.8.8 LEN=61 TOS=0x00 PREC=0x00 TTL=63 ID=11793 DF PROTO=UDP SPT=38401 DPT=53 LEN=41
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.612939] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6232 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=229 RES=0x00 ACK URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.613268] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=874 TOS=0x00 PREC=0x00 TTL=63 ID=6233 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=229 RES=0x00 ACK PSH URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.674102] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6234 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=251 RES=0x00 ACK URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.675123] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6235 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=274 RES=0x00 ACK URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.676703] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6236 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=296 RES=0x00 ACK URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.677907] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6237 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=319 RES=0x00 ACK URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.679175] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6238 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=342 RES=0x00 ACK URGP=0
Thu Mar 9 12:14:00 2017 kern.warn kernel: [ 104.680923] IPTables-FORWARD-Dropped: IN=br-lan OUT=eth0 MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.11 DST=5.39.98.229 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=6239 DF PROTO=TCP SPT=51722 DPT=80 WINDOW=364 RES=0x00 ACK URGP=0
[...]
iptables DROP all traffic between ETH0 and br-lan thats ok for me, but, why i'm not enter in thoses rules ? 'cause my SRC in LOG is 192.168.180.11 instead of 192.168.181.11 ?
i missed something ?
thx @nzamps
other strange thing, if i add
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
i can connect and disconnect from coova (but all internet web site is active) (yeah i know that's normal if i forward all from lan to wan, but logoff/status work and redirect me well...)
strange or absolutly normal ?
For logout try:
iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -m coova--name chilli --source -j ACCEPT
not better.
it's like if during nat or unnat, something doing wrong.
when i try to connect, with an new and fresh challenge (after a redir), i'm well redirected to 192.168.181.1:3990/logon (that my web redir) send request to radius got radius response (login ok) got error : the connection was reset refresh (okay, your are connected)
when i try to connect, with an old challenge, i'm well redirected to 192.168.181.1:3990/logon (that my web redir) send request to radius got radius response (login fail) got error : the connection was reset refresh got error : the connection was reset refresh got error : the connection was reset [...]
when i'm connected, call 192.168.181.1:3990/logoff log me out, but don't redirect me.
when i'm not connected, call 192.168.181.1:3990/json/status fail : the connection was reset (work when i'm connected)
i'm really disappointed :cry:
nobody have a working example ?
Works ok for us but we use external web portals...you could look at that as an option.
i use external portal too
found something strange maybe.
when i try to connect, i saw this in coova log
coova-chilli[670]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=60
coova-chilli[670]: function dhcp_receive_ip()
coova-chilli[670]: Address found
coova-chilli[670]: Resetting connection on port 51352->443
**coova-chilli[670]: dropping packet; not nat'ed**
coova-chilli[670]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=74
coova-chilli[670]: function dhcp_receive_ip()
coova-chilli[670]: Address found
coova-chilli[670]: Resetting connection on port 35067->3990
**coova-chilli[670]: dropping packet; not nat'ed**
coova-chilli[670]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=74
coova-chilli[670]: function dhcp_receive_ip()
coova-chilli[670]: Address found
coova-chilli[670]: Resetting connection on port 35068->3990
**coova-chilli[670]: dropping packet; not nat'ed**
dropping packet; not nat'ed
Here is an other debug.
Start chilli -> ask for json/status not logged / connection was reset -> stop chilli
root@nouvelle-ac-o-test:~# /etc/init.d/chilli start
root@nouvelle-ac-o-test:~# chilli[3847]: (Re)processing options [/var/run/chilli.3847.cfg.bin]
chilli[3849]: running chilli_opt on /var/run/chilli.3847.cfg.bin
chilli[3847]: PID 3847 rereading binary file /var/run/chilli.3847.cfg.bin
chilli[3847]: PID 3847 reloaded binary options file
chilli[3847]: CoovaChilli 1.4. Copyright 2002-2005 Mondru AB. Licensed under GPL. Copyright 2006-2012 David Bird (Coova Technologies). Licensed under GPL. See http://coova.github.io/ for details.
chilli[3847]: chilli_main(7416): clock realtime sec 1489506317 nsec 346554286
chilli[3847]: chilli_main(7422): clock monotonic sec 8419 nsec 871593531
chilli[3847]: TX queue length set to 100
chilli[3847]: Hashlog 8 244 256
chilli[3847]: Net SNDBUF 163840
chilli[3847]: Net RCVBUF 163840
chilli[3847]: device eth1 ifindex 3
chilli[3847]: lo address family: 17 (AF_PACKET)
chilli[3847]: eth0 address family: 17 (AF_PACKET)
chilli[3847]: eth1 address family: 17 (AF_PACKET)
chilli[3847]: ifb0 address family: 17 (AF_PACKET)
chilli[3847]: ifb1 address family: 17 (AF_PACKET)
chilli[3847]: wlan1 address family: 17 (AF_PACKET)
chilli[3847]: wlan0 address family: 17 (AF_PACKET)
chilli[3847]: lo address family: 2 (AF_INET)
chilli[3847]: eth0 address family: 2 (AF_INET)
chilli[3847]: eth1 address family: 2 (AF_INET)
chilli[3847]: tun0 address family: 2 (AF_INET)
chilli[3847]: tun11 address family: 2 (AF_INET)
chilli[3847]: dhcp_hashinit(490): hash table size 64 (56)
chilli[3847]: dhcp_sendGARP(338): GARP: Replying to broadcast
chilli[3847]: dhcp_send() len=42
chilli[3847]: dhcp_new(1191): dhcpif (eth1) IPv6 address ::
chilli[3847]: RADIUS client 0.0.0.0:3799
chilli[3847]: chilli_main(7577): Waiting for client request...
chilli[3847]: qnext=0
chilli[3847]: qnext=0
chilli[3847]: RADIUS queue-in id=0 idx=0
chilli[3847]: sending radius packet (code=4, id=0, len=117)
next 1, first 0, last 0
n= 0 id= 0 state= 1 next= -1 prev= -1 1489506327 396387 0
chilli[3847]: RADIUS id=0 sent to 5.39.98.227:1813
chilli[3847]: kmod wrote 2 /
chilli[3847]: net select count: 1
chilli[3847]: net select count: 2
chilli[3847]: net select count: 3
chilli[3847]: net select count: 4
chilli[3847]: net select count: 5
chilli[3847]: net select count: 6
chilli[3847]: i=0 sz=1
chilli[3847]: i=0 sz=2
chilli[3847]: i=1 sz=2
chilli[3847]: i=0 sz=3
chilli[3847]: i=1 sz=3
chilli[3847]: i=2 sz=3
chilli[3847]: i=0 sz=4
chilli[3847]: i=1 sz=4
chilli[3847]: i=2 sz=4
chilli[3847]: i=3 sz=4
System Interfaces
0) lo (1) ip=127.0.0.1 net=127.0.0.0 mask=255.0.0.0 mac=00-00-00-00-00-00 mtu=65536
1) eth0 (2) ip=192.168.6.62 net=192.168.6.0 mask=255.255.255.0 bcase=192.168.6.255 mac=C2-56-27-B7-FA-0d mtu=1500
2) eth1 (3) ip=192.168.180.1 net=192.168.180.0 mask=255.255.255.0 bcase=192.168.180.255 mac=C0-56-27-B7-FA-0d mtu=1500
4) tun11 (27) ip=192.168.181.1 net=192.168.181.0 mask=255.255.255.0 peer=192.168.181.1 mac=00-00-00-00-00-00 mtu=1500
System Routes
0) dst=0.0.0.0 mask=0.0.0.0 gw=192.168.6.1 dev=eth0 (2)
4) dst=192.168.6.0 mask=255.255.255.0 dev=eth0 (2)
5) dst=192.168.6.1 mask=255.255.255.255 dev=eth0 (2)
6) dst=192.168.180.0 mask=255.255.255.0 dev=eth1 (3)
7) dst=192.168.181.0 mask=255.255.255.0 dev=tun11 (27)
chilli[3847]: Default Route 192.168.6.1
chilli[3847]: Route Interface eth0
chilli[3847]: MAC 4c:9e:ff:7b:02:02
chilli[3847]: net select count: 7
chilli[3847]: net select count: 8
chilli[3847]: radius_timeout(0) 1489506317 398291
next 1, first 0, last 0
n= 0 id= 0 state= 1 next= -1 prev= -1 1489506327 396387 0
chilli[3847]: radius_timeout
next 1, first 0, last 0
n= 0 id= 0 state= 1 next= -1 prev= -1 1489506327 396387 0
chilli[3847]: dhcp_sendCHILLI(170): CHILLI: peer 0 sending 16 bytes
chilli[3847]: dhcp_send() len=30
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=64-00-6A-6E-00-13 dst=C2-56-27-B7-FA-0D prot=0800 2048 len=66
chilli[3847]: dhcp_receive_ip(3739): function
chilli[3847]: dhcp_receive_ip(3775): Address not found (192.168.180.11)
chilli[3847]: dhcp_newconn(745): DHCP newconn: 00-13-77-4C-F9-CB
chilli[3847]: cb_dhcp_connect(5222): New DHCP request from MAC=00-13-77-4C-F9-CB
chilli[3847]: chilli_connect(5183): New Chilli Connection
chilli[3847]: cb_dhcp_request(4981): DHCP request for IP address 192.168.180.11
chilli[3847]: newip(876): newip 192.168.180.11
chilli[3847]: Requesting new static ip: 192.168.180.11
chilli[3847]: Static IP address not allowed
chilli[3847]: Requesting new dynamic ip: 192.168.180.11
chilli[3847]: cb_dhcp_request(5110): Client MAC=00-13-77-4C-F9-CB assigned IP 192.168.180.11
chilli[3847]: dhcp_receive_ip(4218): dropping packet; unhandled auth state 0
chilli[3847]: radius_timeout(-1) 1489506317 991320
next 1, first -1, last -1
chilli[3847]: radius_timeout
next 1, first -1, last -1
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=C0-56-27-B7-FA-0D dst=00-13-77-4C-F9-CB prot=0800 2048 len=74
chilli[3847]: dhcp_receive_ip(3739): function
chilli[3847]: dhcp_receive_ip(3775): Address not found (192.168.181.1)
chilli[3847]: dhcp_newconn(745): DHCP newconn: C0-56-27-B7-FA-0D
chilli[3847]: cb_dhcp_connect(5222): New DHCP request from MAC=C0-56-27-B7-FA-0D
chilli[3847]: chilli_connect(5183): New Chilli Connection
chilli[3847]: dhcp_receive_ip(3931): Not for our MAC or broadcast: 00-13-77-4C-F9-CB
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
chilli[3847]: dhcp_receive_ip(3739): function
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: tun_encaps(tun11) len=52
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=391
chilli[3847]: dhcp_receive_ip(3739): function
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: tun_encaps(tun11) len=377
chilli[3847]: tun_decaps(idx=0, len=40)
chilli[3847]: cb_tun_ind(2709): sending to : 192.168.180.11
chilli[3847]: dhcp_data_req(5650): adding 14 to IP frame length 54
chilli[3847]: dhcp_send() len=54
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=C0-56-27-B7-FA-0D dst=00-13-77-4C-F9-CB prot=0800 2048 len=66
chilli[3847]: dhcp_receive_ip(3739): function
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: dhcp_receive_ip(3931): Not for our MAC or broadcast: 00-13-77-4C-F9-CB
chilli[3847]: tun_decaps(idx=0, len=40)
chilli[3847]: cb_tun_ind(2709): sending to : 192.168.180.11
chilli[3847]: dhcp_data_req(5650): adding 14 to IP frame length 54
chilli[3847]: dhcp_send() len=54
chilli[3890]: redir_main(3415): Calling redir_getstate()
**chilli[3890]: redir_main(3463): Receiving HTTP Request
chilli[3890]: redir_getreq(2150): The path: json/status
chilli[3890]: redir_getreq(2166): The (json format) path: status
chilli[3890]: redir_getreq(2230): Host: 192.168.181.1:3990
chilli[3890]: redir_getreq(2251): User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
chilli[3890]: redir_getreq(2263): Accept-Language: en-US,en;q=0.5
chilli[3890]: redir_getreq(2214): end of http-request
chilli[3890]: redir_main(3535): Processing HTTP Request
chilli[3890]: redir_main(3887): Processing received request
chilli[3890]: redir_main(4132): ---->>> resetting challenge: c24b86aba5372d8425f17d4ba43128dc
chilli[3890]: redir_getparam(1915): getparam(&callback=)
chilli[3890]: redir_json_reply(1415): sending json: {"version":"1.0","clientState":0,"nasid":"testacopub","challenge":"c24b86aba5372d8425f17d4ba43128dc","location":{"name":"testacopub|bureaurdc"},"redir":{"originalURL":"","redirectionURL":"","logoutURL":"http://192.168.181.1:3990/logoff","ipAddress":"192.168.180.11","macAddress":"00-13-77-4C-F9-CB"}}
chilli[3890]: redir_write(1477): redir_write(566)**
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=C0-56-27-B7-FA-0D dst=00-13-77-4C-F9-CB prot=0800 2048 len=632
chilli[3847]: dhcp_receive_ip(3739): function
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: dhcp_receive_ip(3931): Not for our MAC or broadcast: 00-13-77-4C-F9-CB
chilli[3847]: dhcp_decaps_cb(5279): dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=60
chilli[3847]: dhcp_receive_ip(3739): function
chilli[3847]: dhcp_receive_ip(3764): Address found
chilli[3847]: tun_encaps(tun11) len=40
chilli[3890]: _redir_close_exit(3208): close_exit
chilli[3847]: chilli_handle_signal(386): caught 17 via selfpipe
chilli[3847]: _sigchld(316): child 3890 terminated
chilli[3847]: child_remove_pid(138): Freed child process 3890 [[redir]]
root@nouvelle-ac-o-test:~# /etc/init.d/chilli stop
chilli[3847]: radius_timeout(-1) 1489506319 1889
next 1, first -1, last -1
chilli[3847]: radius_timeout
next 1, first -1, last -1
chilli[3847]: chilli_handle_signal(386): caught 15 via selfpipe
chilli[3847]: _sigterm(342): SIGTERM: shutdown
chilli[3847]: CoovaChilli shutting down
chilli[3847]: qnext=1
chilli[3847]: qnext=1
chilli[3847]: RADIUS queue-in id=1 idx=1
chilli[3847]: sending radius packet (code=4, id=1, len=123)
next 2, first 1, last 1
n= 1 id= 1 state= 1 next= -1 prev= -1 1489506329 510388 0
chilli[3847]: RADIUS id=1 sent to 5.39.98.227:1813
chilli[3847]: child_killall(286): pid 3847 killed 3847
root@nouvelle-ac-o-test:~# chilli[3847]: cmdsock_shutdown(109): Shutting down cmdsocket
chilli[3847]: Removing /var/run/chilli.3847.cfg.bin
chilli[3847]: remove(/var/run/chilli.3847.cfg.bin) failed
Chilli send me the json, but i don't get it.
this is my compilation option.
maybe something is missing or not compatible with xt_coova ?
Compiled with
ENABLE_DEBUG2
ENABLE_ACCOUNTING_ONOFF
ENABLE_APSESSIONID
ENABLE_ACCEPTLANGUAGE
ENABLE_AUTHEDALLOWED
ENABLE_BINSTATFILE
ENABLE_CHILLIQUERY
ENABLE_CHILLIPROXY
ENABLE_COA
ENABLE_RADPROXY
ENABLE_CLUSTER
ENABLE_DHCPRADIUS
ENABLE_UAMDOMAINFILE
ENABLE_EWTAPI
ENABLE_GARDENACCOUNTING
ENABLE_IEEE8021Q
ENABLE_IEEE8023
ENABLE_IPV6
ENABLE_JSON
ENABLE_LARGELIMITS
ENABLE_LAYER3
ENABLE_LEAKYBUCKET
ENABLE_MULTILAN
ENABLE_MULTIROUTE
ENABLE_SESSIONID
ENABLE_SESSIONSTATE
ENABLE_STATFILE
ENABLE_TAP
ENABLE_TCPRESET
ENABLE_UAMANYIP
ENABLE_UAMDOMAINFILE
ENABLE_UAMUIPORT
ENABLE_USERAGENT
ENABLE_WPAD
HAVE_NETFILTER_COOVA
HAVE_OPENSSL
USING_IPC_MSG
You could try without ENABLE_TCPRESET
TCP RESET is active by default in the last version, you could not disable it !
You have to change the configure.in
file to add the ability to disable the service.
already tried and it result that le log message 'Resetting connection' disapear.
coova-chilli[670]: Resetting connection on port 35067->3990
coova-chilli[670]: dropping packet; not nat'ed
but the log about 'dropping packet; not nat'ed' persist
but now, we didn't have connection reset (with better firewall rules) but the redirection after login or after logout don't work (in fact, it's work but we have to wait approx 1 minute for being redirected). (maybe when coova unnat or nat one ip (180.10) to another (181.10) or found an other route for packet ?)
We found this topic : https://www.brightonchilli.org.uk/pipermail/coovachilli/2016-June/000011.html and it seems that Pierre had this problem.
it works, but not at the first redir.
@gbaligh we use coova 1.3.2
Mon Mar 20 17:28:56 2017 daemon.info coova-chilli[4803]: Successful UAM login from username=2945522 IP=192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: UPPROT - GETIP
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: kmod wrote 16 +192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: qnext=210
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: qnext=210
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: RADIUS queue-in id=210 idx=210
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: sending radius packet (code=4, id=210, len=234)
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: RADIUS id=210 sent to 5.39.98.227:1813
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Calling connection up script: /iwibox/conup.sh
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: tun_decaps(idx=0, len=52)
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: sending to : 192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: adding 14 to IP frame length 66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_send() len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: caught 17 via selfpipe
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: child 8512 terminated
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Freed child process 8512 [[redir]]
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.237472] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7168 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK URGP=0
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.237674] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7169 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK FIN URGP=0
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.242233] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7170 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK URGP=0
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: tun_decaps(idx=0, len=52)
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: sending to : 192.168.180.10
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: adding 14 to IP frame length 66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_send() len=66
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=1035
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: dhcp_decaps: src=00-13-77-4C-F9-CB dst=C0-56-27-B7-FA-0D prot=0800 2048 len=78
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: function dhcp_receive_ip()
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Address found
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: caught 17 via selfpipe
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: child 8513 terminated
Mon Mar 20 17:28:56 2017 daemon.debug coova-chilli[4803]: Freed child process 8513 [/iwibox/conup.sh]
Mon Mar 20 17:28:56 2017 kern.warn kernel: [29033.246412] IPTables-INPUT-Dropped: IN=eth1 OUT= MAC=c0:56:27:b7:fa:0d:00:13:77:4c:f9:cb:08:00 SRC=192.168.180.10 DST=192.168.181.1 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=7171 DF PROTO=TCP SPT=35157 DPT=3990 WINDOW=251 RES=0x00 ACK URGP=0
I missing something ?
login successfull, write for kmod, call connup.sh after login (do nothing at this point), DROP 3990 on input (why ?) close connup.sh
why coova drop 3990 on input ? i have this rule
ACCEPT tcp -- eth1 * 192.168.180.0/24 192.168.181.1 tcp dpt:3990 coova: name: chillipub side: source
if i had the same rule without kmod, connection reset
Just comparing with mine: you could take off the "-s 192.168.180.0/24" from that rule and you still need a rule for 3990 for unauthenticated users like: "iptables -A INPUT -d 192.168.181.1/32 -p tcp -m tcp --dport 3990 -j ACCEPT" if you haven't got one...maybe you could list how your rules as they are now?
here is all our rules.
everything work fine, except redirection after login and after logout.
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8022 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -i eth1 -p tcp -m tcp --dport 3990 -m coova--name chillipub --source -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "IPTables-INPUT-Dropped: "
iptables -A INPUT -j DROP
iptables -A FORWARD -i eth1 -o eth0 -m coova--name chillipub --source -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m coova--name chillipub --dest -j ACCEPT
iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "IPTables-FORWARD-Dropped: "
iptables -A FORWARD -j DROP
any idea Brian ? maybe i made a bad openwrt compilation. Package missing or something ?
Most likely the iptables rules and how your external portal works. Our rules are a little bit different - we use multiple iptables tables with more than one chilli instance so it's not as simple to compare but essentially we don't have rules like:
iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT
Our equivalent would be:
iptables -A FORWARD -d 192.168.181.0/24 -j ACCEPT iptables -A FORWARD -s 192.168.181.0/24 -j ACCEPT
We also have a rule:
iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Otherwise it takes a lot of testing and trial and error...maybe you could try a different external portal and see if it behaves differently?
- brian
I'm in the same situation, with xt_coova on OpenWRT. Everything works fine, except during redirection after a login or logout action. I have to refresh several time the logoff on logon url to be redirected to captive portal (unless i have "Unable to connect" from the browser). I don't believe it to be an iptables issue, but perhaps I'm wrong ... because, i don't see any log blocking any request.
I'm working with Coovachilli 1.3.2 on linksys WRT-1200AC and OpenWRT Chaos Calmer. If anyone have a clue, it could be awesome !
Hi all, I came a bit late but I really want to resume this conversation. As this discussion says that xt_coova kernel module will speed things up for authenticated users. I am having problems running it correctly. I have configured the exact same settings as mentioned above and applied the iptable rules as mentioned in this topic but none have helped me so far. I am using coova 1.4.7 with external captive portal. I have checked that xt_coova is properly loaded into the kernel. need guidance. Thanks in advance!
Can you dump in here your setup like @keulu did above - chilli config, ifconfig, iptables rules etc and I'll have a look
I have run a test using our multiple iptables table setup and the same rules without the extra tables and I did notice the issue when NOT using them. Seems there needs to be a short delay between login and the correct iptables rules being hit.
If someone (@keulu ?) can try the above rules but with a couple of changes:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8022 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -d 192.168.181.1/32 -i eth1 -p tcp -m tcp --dport 3990 -m coova --name chillipub -j ACCEPT
iptables -N INPUT_tun11
iptables -A INPUT_tun11 -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT_tun11 -j RETURN
iptables -A INPUT -j LOG --log-prefix "IPTables-INPUT-Dropped: "
iptables -A INPUT -j DROP
iptables -A FORWARD -i eth1 -o eth0 -m coova --name chillipub -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m coova --name chillipub --dest -j ACCEPT
iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix "IPTables-FORWARD-Dropped: "
iptables -A FORWARD -j DROP
Note: I have moved an INPUT rule to its own iptables table:
deleted
iptables -A INPUT -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT)
added
iptables -N INPUT_tun11
iptables -A INPUT_tun11 -d 192.168.181.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT_tun11 -j RETURN
See if it helps and I can think of a better solution.
Can you dump in here your setup like @keulu did above - chilli config, ifconfig, iptables rules etc and I'll have a look
Hi, Thank you very much for your kind consideration. With the help given here I have achieved what I wanted and I am getting like wired speeds and coova chilli running merely at 20%. What failing me was the FORWARD rule in defaults section of openwrt firewall. when I changed it from REJECT to DROP it started to work!
But there is one really odd thing I am facing may be this has to do with my configurations. I am using an external portal. The portal is opening fine but when I signin after authentication I get redirected to 11.1.0.1(my UAMLISTEN IP)
This is the url I am getting and the connection is reset. However the internet is working fine!
here is my configuration:
cmdsocket /var/run/chilli.br-lan2.sock unixipc chilli.br-lan2.ipc pidfile /var/run/chilli.br-lan2.pid net 10.1.0.0/255.255.0.0 uamlisten 11.1.0.1 uamport 3990 dhcpif br-lan2 uamallowed "www.coova.org,externalco.com11.1.0.1 omitted uamanydns lease "3600" kname "chilli" dhcplisten "10.1.0.1" dynip 10.1.0.0/255.255.255.0 statip 10.1.1.0/255.255.255.0 dhcpstart "10" domain "lan" dns1 "8.8.8.8" dns2 "8.8.4.4" wwwdir /etc/chilli/www wwwbin /etc/chilli/wwwsh uamuiport 4990 uamdomain omitted locationname "My HotSpot" radiuslocationname "My_HotSpot" radiuslocationid "isocc=,cc=,ac=,network=Coova,"
iptable rules are that of /etc/chilli/up.sh. no custom rules added.
Rather than using up.sh for iptables you should try a variation of the rules mentioned above/earlier. The rules in up.sh are not complete for xt_coova use.
Rather than using up.sh for iptables you should try a variation of the rules mentioned above/earlier. The rules in up.sh are not complete for xt_coova use.
ok. I am going to disable the up.sh script and use the above mentioned rules. should I include some of these rules in conup.sh?
Not in conup.sh - that is run when a session is authorized. You could backup up.sh and put all the rules into that instead of the script code in there now.
Hi @nzamps I have been out for quite some time.
I have tested these rules at first they didn't seem to work and I didn't get any redirection... but then I changed the
iptables -A FORWARD -i eth1 -o eth0 -m coova --name chillipub -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m coova --name chillipub --dest -j ACCEPT
iptables -A FORWARD -i tun11 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun11 -j ACCEPT
and removed the -o argument and the redirection worked. but the problem of connection reset is still there... so far as in the above conversation I have tested a few things:
-disabled the TCPRESET -compiled coova chilli with JSON
I am always stuck at this page with the error: the connection is reset/ http://11.1.0.1:3990/logon?username=971506961351&password=04ec1c1ade97a875&userurl=http%3A//www.xxxxxx.xxx/cp/success/1/40577/%3Fredirect_url%3Dhttps%3A//www.facebook.com/events/1651381694952629/&redir=http%3A//www.xxxxxxxxx.xxx/cp/success/1/40577/%3Fredirect_url%3Dhttps%3A//www.facebook.com/events/1651381694952629/&WISPrVersion=2.0
there is also one more thing
when I type http://11.1.0.1:3990/ the page it shows is that too many redirects...
Really appreciate any help...
Have you tried the multiple chains idea above?
iptables -N INPUT_tun11
iptables -A INPUT_tun11 -d 11.1.0.1/32 -i tun11 -p tcp -m tcp --dport 3990 -j ACCEPT
iptables -A INPUT_tun11 -j RETURN
iptables -A INPUT -i tun11 -j INPUT_tun11
In my previous message I missed that last rule to force the chain jump.
No... :(
No improvement. I think it is related to something else. because you see when this happens i.e. after I get the splash page correctly and get authenticated with ACCESS-ACCEPT packet the TCP RESET happens, I click on the url bar and just highlight the url and press enter... but this time the same url opens. and redirects to the Url defined in USRURL parameter... I dont think it is related to iptable rules... its more related to some sort of delay or something.
has it got to do anything with chilliController.js and some other files in the www folder?
appreciate your help man!
Could possibly be conntrack messing up the tcp session when chilli stops DNAT'ing the packets after STATE is set to 1 (auth).
If you have access to the iptables extension xt_CT can you maybe experiment with disabling conntrack for the uamport:
iptables -t raw -A PREROUTING -p tcp --dport 3990 -j CT --notrack
I tried the above command. first I didn't have the module raw not loaded. but then i compiled and the command ran. but then I didnt' even get the first redirection. there was no splash page with this.
Hmmm that's a shame...worked ok for me. Have you ever tried a tap instead of a tun interface? We always use tap (--usetap) and I wonder if the behaviour changes in any way ?
Hmmm that's a shame...worked ok for me. Have you ever tried a tap instead of a tun interface? We always use tap (--usetap) and I wonder if the behaviour changes in any way ?
I am using bridged interface like br-lan2 and I have used tap as you suggested. using this option with kname=chilli is not working and I dont get the splash page. but when I drop kname and use it without kernel module it works. in this case the iptable rules are from up.sh
would it be possible if I open my device and you can connect and see for yourself where I am doing wrong? I add all your rules (modified to my own interface and ip address maping) in up.sh
really banging my head off the wall on this one... :(
I am having the following logs
chilli[2889]: chilli_connect(5183): New Chilli Connection
chilli[2889]: cb_dhcp_request(4981): DHCP request for IP address 10.1.0.11
chilli[2889]: newip(876): newip 10.1.0.11
chilli[2889]: Requesting new static ip: 10.1.0.11
chilli[2889]: Static out of range (10.1.0.11)
chilli[2889]: Requesting new dynamic ip: 10.1.0.11
chilli[2889]: cb_dhcp_request(5110): Client MAC=A4-4E-31-5B-F1-F4 assigned IP 10.1.0.11
chilli[2889]: dhcp_set_addrs(3667): ARP Entry: 10.1.0.11 -> A4-4E-31-5B-F1-F4
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: www.googleapis.com
chilli[2889]: dhcp_receive_ip(4218): dropping packet; unhandled auth state 0
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: clientservices.googleapis.com
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: clientservices.googleapis.com
chilli[2889]: Received RADIUS packet id=0
chilli[2889]: Freeing RADIUS packet
chilli[2889]: RADIUS queue-out id=0 idx=0
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dns_copy_res(201): It was a dns record type: 1 class: 1
chilli[2889]: dns_copy_res(209): DNS: github.com
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dhcp_receive_ip(4104): Broadcasted UDP to port 137
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dhcp_receive_ip(4104): Broadcasted UDP to port 137
chilli[2889]: dhcp_receive_ip(3764): Address found
chilli[2889]: dhcp_receive_ip(4104): Broadcasted UDP to port 137
chilli[2889]: cb_tun_ind(2565): arp: ifidx=0 src=52-54-91-29-83-43 dst=FF-FF-FF-FF-FF-FF prot=0806 (asking for 11.1.0.11)
chilli[2889]: cb_tun_ind(2577): ARP for unknown IP 11.1.0.11
iptables v1.6.2: unknown option "--cstate"
I am using the following rules:
iptables -t raw -A PREROUTING -p tcp --dport 3990 -j CT --notrack
iptables -A INPUT -m conntrack --cstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -d 11.1.0.1/24 -i br-lan -p tcp -m tcp --dport 3990 -m coova --name chilli -j ACCEPT
iptables -A INPUT -d 11.1.0.1/24 -i br-lan -p tcp --dport 3990 -j ACCEPT
iptables -A INPUT -d 11.1.0.1/32 -i tap0 -p tcp -m tcp --dport 3990 -j ACCEPT
ipt -A FORWARD -i $DHCPIF -m coova --name $KNAME -j ACCEPT
ipt -A FORWARD -o $DHCPIF -m coova --name $KNAME --dest -j ACCEPT
ipt -A FORWARD -i $TUNTAP -j ACCEPT
ipt -A FORWARD -o $TUNTAP -j ACCEPT
I am not getting the splash page at all with tap :(
Ahhh bridged - we never had any real success with bridged interfaces and xt_coova. We run our chilli instances on separate devices ("controllers") without WiFi etc. Are you able to try a tap interface without a bridge - like just on eth1 and see ?
so are you saying that with bridge it is not possible?
No, just saying we had issues with iptables and bridging so we don't set it up that way. I'm trying to work out the differences from ours to try to isolate the problem.
Hi man. I got it working with your iptable rules. there was a bit of mistake i was making. your rules work just fine! One thing I still am unable to do is bandwidth control. my RADIUS is sending bandwidth limit to each user but with xt_coova I am unable to get the bandwidth from RADIUS in conup or condown script. I am able to get the called station id. but not the bandwidth.Below are the attribues I called in the conup script WISPR_BANDWIDTH_MAX_DOWN= COOVACHILLI_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_COOVACHILLI_BANDWIDTH_MAX_DOWN=
Please help
I think your Radius parameter to return is RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN and you access this from scripts as WISPR_BANDWIDTH_MAX_DOWN. Check you are using these.
but in radius I am sending as WISPr-Bandwidth-Max-Down as well as CoovaChilli-Bandwidth-Max-Down. both are working without xt-coova I have checked. but with xt-coova I am not getting these parameters in conup. should I change the radius parameter to RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN and see?
yep send RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN
ok. but I dont think this is defined anywhere in freeradius is it?
Not sure but you could test it by setting defbandwidthmaxdown in the chilli.conf. This should return in the script as WISPR_BANDWIDTH_MAX_DOWN (defbandwidthmaxdown sets the same var as RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN).
@nzamps bro I did set defbandwidthmaxdown in chilli.conf and the variable WISPR_.. is 0 while RADIUS_ATTR.. is null. its just empty
Hang on, what's in your Radius packet - if RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN is being sent as null then defbandwidthmaxdown will be overridden with 0.
Hang on, what's in your Radius packet - if RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN is being sent as null then defbandwidthmaxdown will be overridden with 0.
nothing is working. i am unable to get anything as it is still showed as 0
Before grabbing into this "Can of Worms", called xt_coova: Besides bandwidth_limit not working, how about download_limit ? I suspect, not working, too, correct ?
Hi man. I got it working with your iptable rules. there was a bit of mistake i was making. your rules work just fine! One thing I still am unable to do is bandwidth control. my RADIUS is sending bandwidth limit to each user but with xt_coova I am unable to get the bandwidth from RADIUS in conup or condown script. I am able to get the called station id. but not the bandwidth.Below are the attribues I called in the conup script WISPR_BANDWIDTH_MAX_DOWN= COOVACHILLI_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_WISPR_BANDWIDTH_MAX_DOWN= RADIUS_ATTR_COOVACHILLI_BANDWIDTH_MAX_DOWN=
Please help
Hey,
Could you please give me a hand with the IP rules? I am totally stuck!
Hi guys,
1 week ago, i noticed that my users connected behind coova are not limitted on upload on my router with openWRT 15.05.1 and coova 1.3.2
this is my device in chilli_query list
CC-25-EF-31-3B-75 192.168.180.2 pass 58ac194800000003 1 2945522 8/31536000 2/900 2010420/0 0/0 0 1 **0%/262144 0%/1048576** http://captive.apple.com/hotspot-detect.html vlan=(null)
My limits are set correctly. When i download someting, i see log about leaky bucket for download, and my limit is well apllied. (Leaky bucket dropping download overflow to CC-25-EF-31-3B-75). it's applied because i see 99%/1048576 great !
But... (and that make me crazy) i can't limit my upload.
this are my confs
`
/etc/config/chilli
config chilli 'public' option radiusnasid 'testacopub' option radiuslisten '10.1.210.254' option radiussecret '**' option radiusserver1 '**' option radiusserver2 '**' option radiusauthport '1812' option radiusacctport '1813' option uamserver 'http://testacopub.***.net' option uamhomepage 'http://splash.***.net' option uamsecret '**' option uamlisten '192.168.180.1' option uamport '3990' option uamanydns '1' option uamaliasip '1.0.0.1' option uamaliasname 'login' option uamlogoutip '1.1.1.1' option nouamsuccess '1' option coaport '3799' option coanoipcheck '1' option tundev 'tun11' option net '192.168.180.0/22' option lease '7200' option dhcpif 'br-if_pub' option dns1 '8.8.8.8' option dns2 '8.8.4.4' option domain '**' option kname 'chillipub' option swapoctets '1' option interval '3600' option ipup '/iwibox/coova/ipup.sh' option ipdown '/iwibox/coova/ipdown.sh' option conup '/iwibox/coova/conup.sh' option condown '/iwibox/coova/condown.sh' option locationname '***' option maxclients '1024' option nowispr1 '1' option nowispr2 '1' option noc2c '1' option rfc7710uri 'http://192.168.180.1:3990/prelogin' option dnslog '/var/log/coova_dns_pub.txt' `
`
INPUT and OUPUT POLICY is ACCEPT by default
Chain FORWARD (policy DROP 1444 packets, 134K bytes) target prot opt in out source destination
ACCEPT all -- tun11 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- tun11 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- br-if_pub 0.0.0.0/0 0.0.0.0/0 coova: name: chillipub side: dest ACCEPT all -- br-if_pub 0.0.0.0/0 0.0.0.0/0 coova: name: chillipub side: source `
I also tried to disable TSO GRO and GSO on my interfaces, but nothing change...
does anyone have an idea, What i'm missing ?
@nzamps I saw that you a pretty active about xt_coova. do you know what my problem is ?