CoovaChilli Random Failures: Manual Restarts Required

Greetings Community,

We're encountering persistent issues with CoovaChilli on our custom Linux distro developed atop Yocto. CoovaChilli serves as our captive portal solution, facilitating user authentication through a FreeRADIUS server. Unfortunately, the service intermittently fails, causing the captive portal to not open upon users connecting to our Wi-Fi network. Even manually visiting the portal URL yields no results until we restart the service.

Despite extensive efforts, the root cause remains elusive. We've managed to gather some CoovaChilli logs during the occurrences:

Mar 28 05:39:26 ared-machine chilli[2253]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Mar 28 05:39:26 ared-machine chilli[2261]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Mar 28 05:39:26 ared-machine chilli[2267]: Bad argument `DROP'

Mar 28 05:39:26 ared-machine chilli[2267]: Try `iptables -h' or 'iptables --help' for more information.

Mar 28 05:39:26 ared-machine chilli[2269]: Bad argument `ACCEPT'

Mar 28 05:39:26 ared-machine chilli[2269]: Try `iptables -h' or 'iptables --help' for more information.

Mar 28 05:39:26 ared-machine chilli[2271]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Mar 28 05:39:26 ared-machine chilli[2272]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Mar 28 05:39:26 ared-machine chilli[2275]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Mar 28 05:39:35 ared-machine chilli[2139]: Network is unreachable: sendto() failed!

Apr 12 05:17:39 ared-machine chilli opt[2071646]: uamdomain aredgroup.com

Apr 12 05:17:39 ared-machine chilli opt [2071646]: PID 2071646 saving options to /var/run/chilli.2165.cfg.bin

Apr 12 05:17:39 ared-machine chilli[2071646]: Usage: chilli query [ -s ] [ -p «port> ] [ ]

Apr 12 05:17:39 ared-machine chilli 20716461:

socket = full path to UNIX domain socket (e.g. /var/run/chilli.sock)

Apr 12 05:17:39 ared-machine chilli 20716461:

port = TCP socket port to connect to. Default is 42424

Apr 12 05:17:39 ared-machine chilli 20716461:

Available Commands:

Apr 12 05:17:39 ared-machine chilli[2071646]:

list, Iistippool, Iistradqueue, listgarden, reload, dhcp-list, dhop-release, authorize, login, update, logout, logoff?

Apr 12 05:17:39 ared-machine chilli [2071646]:

Available Arguments:

Apr 12 05:17:39 ared-machine chilli [2071646]:

ip

type:

ip

41

- IP address of session to perform action oN

Apr 12 05:17:39

ared-machine chili [2071646]

mac

type: mac

6 1

MAC address of session to perform action

on

Apr 12 05:17:39

ared-machine chilli[2071646]:

sessionid

- type: char

171

Session-id of session to perform action on

Apr 12 05:17:39 ared-machine chili [2071646]:

username

- type: char [ 2561

- Username to use in RADIUS

'login' or authorization

Aor

05:17:39 ared-machine chilli 2071646]:

password

- type: char [ 256]

- Password to be used for 'login' command

Apr 12 05:17:39 ared-machine chilli[2071646]:

sessiontimeout - type: int

81 - Max session time (in seconds)

Apr 12 05:17:39 ared-machine chilli 20716461:

idlet imeout

- type: int

41 - Max idle time (in seconds)

Apr 12 05:17:39 ared-machine chilli [2071646]:

interiminterval - type: int

2] - Accounting interim interval

Apr 12 05:17:39 ared-machine chilli [2071646]:

maxoctets

- type: int

81

- Max input + output octets (bytes)

Apr 12 05:17:39 ared-machine chilli[2071646]:

maxinputoctets

- type: Int

8 I

- Max input octets (bytes)

Apr 12 05:17:39 ared-machine chilli[2071646]:

maxoutputoctets ‹value>

- type: int

81

- Max output octets (bytes)

Apr 12 05:17:39 ared-machine chilli 20716461:

maxbwup

type:

int

2 1

Max bandwidth up

Apr 12 05:17:39 ared-machine chilli 20716461:

maxbwdown

type:

int

Q1

Max bandwidth down

Apr 12 05:17:39

ared-machine chilli[2071646]:

splash

type: char [2048]

Set splash page

Apr 12 05:17:39

ared-machine chilli[2071646]:

url

- type: char [2048]

Set redirect url

Apr 12 05:17:39 ared-machine chilli[2071646]:

noacct

- type: flag [

01

- No accounting flag

Apr 12 05:17:39 ared-machine chilli 20716461:

data ‹value> - type: char

Apr 12 05:17:39 ared-machine chilli 20716461: The ip and/or sessionid is required.

Apr 22 04:55:42 ared-machine chilli[2131]: PID 2131 reloaded binary options file

Apr 22 04:55:42 ared-machine chilli[2131]: CoovaChilli 1.6. Copyright 2002-2005 Mondru AB. Licensed under GPL. Copyright 2006-2012 David Bird (Coova Technologies). Lic>

Apr 22 04:55:42 ared-machine chilli[2131]: TX queue length set to 100

Apr 22 04:55:42 ared-machine chilli[2131]: Network is unreachable: sendto() failed!

Apr 22 04:55:44 ared-machine chilli[2269]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

We're seeking insights from the community to help pinpoint the underlying cause of these random failures and identify effective solutions. If you've encountered similar challenges with CoovaChilli or have expertise in troubleshooting such issues, your guidance would be greatly appreciated.

Thank you for your assistance in resolving this vexing problem.

Ask your vendor.


It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

FYI - CoovaChilli has been effectively unmaintained since circa 2015 when the original developer moved on to other things.
It was designed to work with a now, long defunct version of iptables/xtables so will no longer work without much hacking.
There is an OpenWrt package but of course it is just a build from the source code and is therefore also broken, not least because OpenWrt no longer uses iptables by default.

Some "hotspot" vendor products using CoovaChilli have done some dubious hacking to keep it working, with mixed results - as you have found out.

As @frollic says, all you can do is contact your vendor, if they still exist.

First of all, this looks like some commercial system. Asking for help/consultation, free of charge, is a bit far fetched. Second, I did quite a few commercial hotspot systems in the past, based on official openwrt, in various versions, all of them also using coova-chilli. Most recent official openwrt switched from iptables to nftables, causing issues with coova. However, usage of nftables is not a MUST, at least regarding openwrt 21.x.xx. (Also) to avoid issues with coova. Anyway, in case of interest, you can send me a PM for further discussion. Most of all: Which hardware do you use, and which openwrt(-flavor) ?

The op said:

CoovaChilli is opensource software, and first line of log tells what YOU have to patch. What do you want from OpenWRT if you are not even using it?

Thank you for the response.

Thank you for your clarification. We considered CoovaChilli in a general context without focusing on the underlying OS. Our setup involves PC Engines APU 2 and Yocto. We appreciate your insight and will continue to address the issue within our specific configuration. Regards.

Thank you for the insights. We're using PC Engines APU 2 with a custom Yocto-based system, not OpenWRT. Your experience with CoovaChilli on OpenWRT is valuable. Would you have experience with our setup for further discussion? Thanks.

Thank you for the clarification. We understand the potential differences between our custom firmware and the official OpenWrt versions. We'll explore options for support within our specific firmware context. If we encounter issues common to generic OpenWrt, we'll reach out for further assistance. Thanks for your guidance.

you'll never be able to prove they're common.
as @bluewavenet pointed out, the application is dead since 9 years, people moved one, knowledge wise, so should you, solution wise.

Thank you for your perspective. We'll certainly consider exploring alternative solutions, especially those that are actively maintained. Could you recommend any latest tools that fulfill the functionality of CoovaChilli in spinning up captive portals and authenticating users against FreeRADIUS? Your insights would be appreciated. Thanks

openNDS is probably the go to solution, if you want something open source.

1 Like

Thanks for the suggestion. We'll check out openNDS and compare its features with our current setup for feasibility. Appreciate your help!

Why would you even want that these days?
Radius was developed in the 1980's when the very first, pre-Internet providers wanted a means of authenticating dial-up users.
Remote Authentication Dial-In User Service

Well, I know why you want it - because that is what you bought into.
Although I rather expect that you did not buy into it, but instead you have been tasked with fixing or upgrading some ancient legacy system.

Or perhaps this is an academic exercise set by an old dinosaur of a teacher :wink:

Good luck with it!

1 Like

Thank you for your response. While RADIUS technology indeed originated in the 1980s, our setup caters to modern needs within a specific context. Our system, centered around a PC Engines APU 3 device running a custom Yocto-based distro, provides internet access via a Wi-Fi captive portal.

We've integrated various components such as hostapd for Wi-Fi provisioning, a PHP captive portal hosted on a local lighttpd web server, and CoovaChilli for dynamically spinning up the captive portal upon user connection. Our architecture supports offline access to media files and content management through a remote dashboard utilizing Balena Engine for file syncing from Google Cloud.

User authentication is facilitated through token/voucher generation via a Vue.js-powered remote dashboard, with CoovaChilli handling the submission of vouchers to our remote FreeRADIUS server connected to our API DB. This setup allows us to provide seamless and secure internet access to users based on voucher durations.

Given our system's structure and functionality, do you have any suggestions for potential improvements or alternative approaches that could enhance our architecture? Your insights would be valuable as we strive to optimize our setup. Thank you for your input.

This is not correct. In short: It (still) works. When getting rid of firewall, and using plain iptables. We had an old proverb in software development: About software, which simply works, nobody talks ...

It was @bluewavenet's words, not mine, perhaps unmaintained would be a better term, after all.

OK, "unmaintained" is a better term. "Dubious hacking" is also not too far from reality. However, because of the knowledge of quite some "black magic" for proper setup of coova-chilli (by purpose, because being used in quite a few commercial hotspot systems ?) its importance decreases significantly. "The only real docs is the source code :-)"

1 Like

I think best course of action is that you formalize situation and pass -w flag to coovaspot upstream, as coova literally sets up one iptables rule and openwrt never had intense iptables rule modification activity during everyday run to warrant your error. Indeed your yocto mash does.

1 Like