coova-chilli: xt_coova module doesn't work on OpenWRT 23.05 #23092
Comments
|
I'm not the maintainer for coova-chilli and in fact I'm developing a replacement: https://github.com/f00b4r0/uspot (which is now packaged in OpenWrt 23.05 and works with firewall4/nftables). HTH |
|
It will work with iptables-legacy only. |
|
Could I ask you to attach |
|
nft-conntrack - ipt-conntrack-extra |
|
Hi @brada4 ! I'm currently on a custom build, but these are the related packages installed: |
|
Gradually remove nft modules confirming with |
|
(you might need to block modules in modules.d if dependencies do not permit uninstall) |
|
@f00b4r0: Interesting! |
|
Any solution for this? I'm having the same problem on snapshot, including remove firewall4 and installing firewall and iptables-legacy instead. |
|
The dependency on x-tables kmod is a compile time option. Simpler to install but slower in day to day operation would be to build coova-chili without kmod and make kmod package an empty boilerplate. Then it will work with either of 2 iptables. It adds individual NAT rules per client MAC. |
|
Compilation of what package are we talking about here? Cos I'm recompiling coova-chilli and kmod-ipt-coova from sdk, and it does not seem to work. The problem is that without xt_coova module it can create bandwith bottleneck because, the CPU of some devices are not powerfull enough to do the paquet analysis from userland. |
|
You need to deselect kmod thewn coova will not catch option and built in clean iptables mode. |
|
Yes, sure it can operate without kmod. If you remove "kname chilli" from the config file it will not use the module, and will work perfectly without the module anyway (without having to recompile). But if the module is not used it is way more CPU consuming right? And on embedded hardware with low-spec CPU, the CPU charge can be a bottleneck no? ( At least it was the case on previous versions, I don't know if things changed on newer coova-chilli versions ). |
|
It uses iptables command to insert rules that can be offloaded to flowtables (or xt offload), it may not be that slow in the end. |
|
Well I will do some testing on the last version to check that out. But I'm sure that on older version on a MT7620 CPU you would not get a throughput higher that 20Mbits/s through coova if you did not use the kmod-ipt-coova (and this using 100% cpu). |
|
Watch out - there is config option - if module is built even empty it adds module requirement to main executable. You need to rip out that line |
|
But where did you see that "It uses iptables command to insert rules that can be offloaded to flowtables (or xt offload)"? I've never seen chilli process automatically inserting iptables rules when a client get authenticated.... And I just tested a version compiled without xt-coova, and I don't see iptables rules being changed while the program is runing, and client gets authenticated. But it makes me think that maybe it could be done quite easily to add a per client firewall allowance within the conup.sh and condown.sh scripts. |
|
I've done some tests and I can get something somewhat working and not consuming much CPU by inserting per customer iptables from conup.sh script ( in order to replace the missing rules from kmod ):
And deleting it from condown. But it's really a hack and I'm not sure about the reliability of this. |
|
Good idea. You could edit set (ipset or nftables set) instead. Reverse forward is not needed, conntrack takes care of it. |
|
Thing is I'm trying to investigate why the libxt_coova.so refuses to load, because from what I understand now, there is no actual reason for this to happen. Because other match modules succeed in loading without problem with last version of iptables-legacy. I guess there might be something to adapt in here: https://github.com/coova/coova-chilli/blob/master/src/linux/libxt_coova.c |
|
iptables v1.8.8 (nf_tables) -> this emulates most common -legacy modules and emits native nft rules. You need real legacy iptables to interact with other modules. |
|
Yes but I do have real legacy itpables and it does not work iptables v1.8.8 (legacy): Couldn't load match `coova':No such file or directory If the only thing to do was to install iptables-zz-legacy, it would be fine. Thing is that I guess there are plenty of existing captive portals based on coova, that you just would like to see working, without needing to go into a thousand of tedious worries and complications, of changing underlying technology. |
|
You can load it from these tables https://github.com/coova/coova-chilli/blob/7d18bd6b24fd20a4d8cde2a2f9b34a214327f07c/src/linux/xt_coova.c#L598 |
|
|
Is it published in /proc/net/ip_tables_matches? |
|
The userspace libxt_coova library is not even packaged or installed. |
|
I'm facing the same issue as @pparent76 . The xt_coova module doesn't work even if you use iptables-zz-legacy. The module loads (apparently) ok, you can see the matches published at /proc/net/ip_tables_matches , but I get this error when trying to use the -m coova match from iptables.
I have already tried removing the nft* suggested packages, unsuccessfully. |
|
It is certainly a packaging bug that /usr/lib/iptables/libxt_coova.so is not installed. Anyone may recall when? |
|
But why do you say that /usr/lib/iptables/libxt_coova.so is not installed? For me it certainly is, the file is there that's why I find it strange that it does not work! ( Well I recompile coova with sdk to change some build time option, but I'm not sure if has influence ) |
|
|
Maybe rename _init to libxt_coova_init ? |
|
Yes that's what I'm currently trying. |
|
It works!! |
|
fork repo |
|
Yes, I was going to do that! Thank you so much for the help by the way! |
|
yw, thanks for brilliant research. |
|
Fixes: 55297e4 |
Thank's a lot! Here is the pull request: #23386 ( Hope that I've respected approximately the guidelines of the project to make the PR ) |
…enwrt#23092 ) Signed-off-by: Pierre Parent <[email protected]>
…3092 ) Signed-off-by: Pierre Parent <[email protected]>
d1e721720 boinc: update to 7.24.3 f9e16375f git: update to 2.43.2 24832d99c fswebcam: update to 20200725 f919d4192 croc: update to 9.6.12 a9a1e7c3a clamav: update to 1.3.0 c623291b3 rtl-sdr: update to v2.0.1 0bb9240f6 rtl_433: update to 23.11 61ba390b6 coova-chilli: fix libxt-coova not loading properly from iptables ( openwrt/packages#23092 ) 46ed50946 screen: update to 4.9.1 bb574d7b6 hyperscan: symlinks redundant ABI shared objects 3e34186c1 openvpn: update to 2.6.9 b6e8be238 micropython: disable mold 32bed2e89 tesseract: update to 5.3.4 029c1c528 imagemagick: add missing libzip dependency 374175924 sysstat: add missing xz-utils dependency 4d8bb07b7 lighttpd: update to lighttpd 1.4.74 release hash
|
Thanks for you work, @pparent76 and @brada4 ! I think we can close this issue now. |
|
@neheb patch should be backported to stable branches as in OP? |
|
@brada4 Hi, I am trying to run coovachilli with and without xt_coova on openwrt 23.05 i tried your procedure to unload nft modules but still its not redirecting to splash page. Though iptables rules looks fine. Please suggest what am i missing. this is the output of the lsmod: cfg80211 293611 5 mt76x2_common,mt76x02_lib,mt7603e,mt76,mac80211 and when i run nft list ruleset i get this: } Please suggest what I am missing in this? @pparent76 please help if you are manage to run coovachilli with xtcoova in 23.05. Many thanks |
|
Opt1 fw4+iptables-nft+kmod_nft (inactive ipt kmods are used by iptables-nft) fw4+iptables-zz -> no go. |
|
Thank you for your reply @brada4. For Opt1 do we have to change anything in coovachilli code or in up.sh or down.sh script for iptable rules? Also we donot need any kmod-ipt for this option? For opt3 can we compile 23.05 without fw4 and only with fw3 + iptables-zz+kmod-ipt? If yes can you please provide guide because i saw fw4 is by default in 23.05 Thanks once again |
|
Opt1: ipt modules will be installed as a dependecy of iptables-nft |
|
Hi @brada4 Thank you for your response. I tried opt1 with fw4 and iptables-nft keeping ipt and nft modules in there but it is not redirecting user to page on connect with coovachilli. I have just used fw4, iprables-nft and kmod_nft and ipt and did not remove anything and run coovachilli as it is without any change. Am i missing something? Also for opt3 i checked using makemenuconfig i cannot remove firewall4. How to add firewall3 and remove firewall4 during image builder a little guide will be helpful. Thank you. Thanks once again. |
|
Check |
|
Hi @brada4 , thank you your reply and sorry to bother you but i just need a way as i saw discussion here that it will work. iptables --version: iptables--save: *filter nft list ruleset has this iptables-nft based rules. (i am currently testing it without xt_coova for it to work atleast) (comment):Warning: table ip filter is managed by iptables-nft, do not touch! } Please guide if you see any issue in here. Thanks |
|
Strange xt target tcpmss, shoould use native tcpmss |
|
Hi @brada4, thanks for reply. I am now using xt coova: *mangle this is nft list rule set : (comment): Warning: table ip filter is managed by iptables-nft, do not touch! } This tcpmss now removed from mangle but still not working not redirecting to uamserver |
|
Please go to forums, and learn about formatting buttons |
|
Hi @raheelhirani35 , Did you figure how to make coova redirect using fw4 and xt_coova? Please let me know if you having any working solution. Thanks |
Maintainer: @f00b4r0 (?)
Environment: ipq807x, Xiaomi AX36000, OpenWrt 23.05
Description: After nftables being used as default firewall framework for OpenWRT, I can't use the xt_coova module. The module is built without errors, but the related libxt library (libxt_coova.so), doesn't work as expected.
If you try to load any iptables rule containing a coova match, it fails with the following error:
Also, if you try to print the help message, it also fails:
I already checked that xt_coova.ko module is loaded and I can see the coova entry on /proc/net/ip_tables_matches
Any hints?
Thanks!
P.D: related discussion on forum: https://forum.openwrt.org/t/coova-chilli-on-openwrt-22-03-nftables/136941/12
The text was updated successfully, but these errors were encountered: