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
dvs23
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: 6441 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 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 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%.
Issue is still present in build 33679 (device under test RT-AC-56U / DD-WRT v3.0-r33679 std (11/04/17)).Without OpenVPN client enabled in GUI the looping ebtables process is not present.
This seriously makes DDWRT currently unusable as GUI-configured OpenVPN client . This need to get sorted.
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:
/tmp/root/ebtables -L
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 know with Kongac Builds it has working ebtables. So it must BrainSlayer Builds that have these issues. Thanks quarksg for your solutions! _________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
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):
Code:
## script for replacing broken ebtables binary from jffs
#!/bin/sh
sleep 30
killall ebtables
mount --bind /jffs/tmp/ebtables /usr/sbin/ebtables
logger "ebtables binary replaced (workaround)"
Guys, what do you think is the best way to get this likely simple fix permanently included in the upcoming BrainSlayer builds? Can we do more that documenting it in Trac?
Last edited by JohnS@ on Sat Nov 11, 2017 12:32; edited 1 time in total