is using one complete core. The only Multicast related thing I remembered was enabling Security->Firewall->Block WAN Requests->"Filter Multicast" (checkbox enabled)
When I disabled this the process was not restarted after a kill, so it no longer consumes all the power
Is it a bug in DD-WRT or could there be anything else that's wrong with my router? I don't really need it, but in case it's a bug I thought I should tell someone
Thanks for such a great and free router firmware
This has been happening on my R7000 too. I've been associating it with OpenVPN, since the tap1 is involved. I assumed it has to do with NAT protection. I've had to kill the ebtables to get the VPN to work anywhere near line speeds.
Joined: 16 Nov 2015 Posts: 3449 Location: UK, London, just across the river..
Posted: Sun Apr 02, 2017 7:01 Post subject:
hmm, i guess VPN is using high CPU power as its a very CPU aggressive process, also it depends what VPN encryption is used, high encryption lowers the speed and rises the CPU use.. _________________ Atheros
TP-Link WR740Nv1 ------DD-WRT 42514 BS WAP/Switch
TP-Link WR740Nv4 ------DD-WRT 42557 BS AP,NAT
TP-Link WR1043NDv2 ----DD-WRT 42287 BS AP,NAT,AD Block,AP Isolation,Firewall,Local DNS,Forced DNS,DoT,VPN
TP-Link WR1043NDv2 ----DD-WRT 42602 BS AP,NAT,AD Block,Firewall,Local DNS,Forced DNS,DoT,VPN
TP-Link WR1043NDv2 ----Gargoyle OS 1.12.0 AP,NAT,QoS,Quotas
Netgear R7800 -------DD-WRT 42803 BS AP,NAT,AD-Block,AP&Net Isolation,VLAN's,Firewall,Local DNS,DoT
Netgear R7000 -------DD-WRT 42803 BS AP,Wi-Fi OFF,NAT,AD-Block,Firewall,Local DNS,Forced DNS,DoT,VPN
Stubby for DNS over TLS I DNSCrypt v2 via Entware by mac913
This is definitely NOT the normal part of the VPN causing high usage. If I leave the ebtables processes running (sometimes one on each cpu @ 100%) the VPN maxes out at 15 mbit/s because the router doesn't have enough overhead to support the VPN. If I kill any ebtables processes not only does the VPN stay running, but it also jumps to 40+ mbit/s. The rule that ebtables is trying to run is part of the nat <-> tun1 drop for nat protection. This isn't the root of the problem however. If you attempt to interact with ebtables (e.g., CLI) at all it will peg a cpu and hang.
Edit: When speed testing with VPN on, ebtables not running the cpu usage is ~15%.
I've attached the ebtables binary for ARM CPU routers. This binary will likely only work for DD-WRT firmware running the Linux 4.4.x kernel.
I've also encountered the situation where ebtables will hang when it is executed on my DLink DIR-880L running r30342, so this issue has been there for quite a while. To investigate the issue, I downloaded the DD-WRT firmware and compiled a copy of the ebtables executables and to my surprise, my compiled copy of ebtables runs without any problem. So I suspect it could be the developers build bot may have messed up the compilation when compiling for multiple targets.
The steps below should allow you to try out the attached ebtables executable:
1. Upload the attached 'ebtables.gz' file to your router using 'scp' (for Unix based OS) or WinSCP (using Windows)
2. Uncompress the compressed 'ebtables.gz' file and make it executable:
(assuming that you have uploaded the file to the '/tmp/root' directory in your router:
3. Test to ensure that the uploaded 'ebtables' is working:
You should see some output as shown below:
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
4. If Step 3. is successful it means the 'ebtables' binary is working for your router. Proceed to override your router's existing binary with the uploaded one with the command below:
mount --bind /tmp/root/ebtables /usr/sbin/ebtables
That should do it. Do note tho that the above will not survive a router restart as the ebtables binary is stored in the router's RAM. A restart will wipe it off. To make it persistent across router reboots, you need to upload the ebtables to a USB thumb drive or the JFFS partition in your router and add the command in Step 4. to your router's startup script, adjusting the path to the location of the uploaded ebtables binary.
Hope the above Step is clear enough for those who would like to try.
I've attached the ebtables binary for ARM CPU routers. [...] allow you to try out the attached ebtables executable [...] Do note tho that the above will not survive a router restart [...] Hope the above Step is clear enough for those who would like to try.
quarkysg: THANK YOU!
egc, mwchang: Thanks for your inputs as well.
I can confirm that replacing the ebtables binary with quarkysg's properly compiled one makes OpenVPN client-mode (TAP) work in the new releases (I used 33679).
For the moment I've used the following crude startup script (prerequisite is that you have jffs enabled and put quarkysg's binary to /jffs/tmp/ - follow his instructions and/or adapt paths according to your setup):
## script for replacing broken ebtables binary from jffs
mount --bind /jffs/tmp/ebtables /usr/sbin/ebtables
logger "ebtables binary replaced (workaround)"