I'd look into trying to figure out what might be causing the problems. conntrack-tools and/or tcpdump would be my first steps. If you understand stream forwarding over ssh, I'd run wireshark on a "desktop" fed by the stream captured with tcpdump on your router. wireshark's ability to highlight malformed packets and unexpected packet sequences could be valuable.
Yeah, that was my idea. downgrade to 1.3.0 or 1.3.1. Thx for confirm that you don't have problems.
I don't think so... on wrt1200ac maybe, but we have X86 supermicro 8 cores 8Gb Ram and we have this problem too.
yeah, i tried with netstat, tcpdump, or conntrack. i already use conntrack but only for people "connected to internet" not for people blocked behind captive portal and i didn't see revelant problem.
I saw cloud shark package for openwrt. i already tried it in the past but when you have 400 peoples, analyze their traffic will be complicated :).
What do you mean ? could you explain a little ? thx
You might even downgrade to 1.3.0 or the last version originating by David, unless you need one of the newer features. As it is a piece of software, which dynamically grew up (read: was patched over the years), I am a bit skeptical about the newer maintainers, getting the patches correct in all places.
Less code, less probability for bugs
A managed switch can usually mirror traffic from certain ports to a monitoring port. If you want to see what traffic is causing this you can use this technique to packet capture on a desktop machine all the traffic coming to your chili install.
Update on "dropping malformed DNS": I checked my logs of multiple routers, and also found this error a few times. Which is strange, as a local dnsmasq is used, connected via openVPN to private DNS-server. However, it looks like a bad quality of WAN (3g/4g) seems to generate more of these errors. Using coova-chilli 1.3.1-svn
"malformed DNS": I checked one log in more detail, regarding this issue. And I found, that chilli generates this warning immediately after same user-MAC receives an IP via chillis dhcp:
88-79-7E-xx-xx-xx, which should be a Motorola device.
So I suspect, that in my case, this issue is related to the users device DNS request, not chillis upstream DNS handling. A vpn-tunnel via DNS comes to my mind ...
Sun Aug 19 20:54:52 2018 local6.notice coova-chilli[2067]: chilli.c: 5027: Client MAC=88-79-7E-xx-xx-xx assigned IP 10.1.0.41
Sun Aug 19 20:54:59 2018 local6.warn coova-chilli[2067]: dhcp.c: 1787: dropping malformed DNS
Sun Aug 19 20:55:04 2018 local6.warn coova-chilli[2067]: dhcp.c: 1787: dropping malformed DNS
Sun Aug 19 21:06:09 2018 local6.info coova-chilli[2067]: chilli.c: 5522: DHCP Released MAC=88-79-7E-xx-xx-xx IP=10.1.0.41
I used to use coovachilli also also had issues with the more recent version on github, so ended up with the older 1.3.0 which worked mostly without issue but throughput is limited due to the way chili routes traffic through a tun/tap interface - it's a bit of a problem when the customers (hotels) are on fibre > 100mbits and allow their guests to stream Netflix etc... So I settled for wifidog instead as it uses layer 3 with iptables, I modified it over time with similar features to chilli like Mac auth and DHCP.