Possible bug on Asus RT-AC87U with ebtables

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3
Author Message
quarkysg
DD-WRT User


Joined: 03 May 2015
Posts: 323

PostPosted: Sun Nov 19, 2017 22:32    Post subject: Reply with quote
ibrewster wrote:
egc wrote:
Hmm very strange it is not working for you, your router must be enchanted Smile


That must be it! Smile My router is cursed! Very Happy Razz

...or maybe I have a different router than you (your signature indicates Netgears and Linksys, I have an Asus), or perhaps a different configuration (jffs enabled vs disabled? Maybe it's trying to write a log file or something and that's what's giving me the permission denied?), or a different build of dd-wrt (mine came from the Asus RT-AC68U folder, your's was almost certainly not from there, unless you also have a 68U), or any number of obscure differences that would be hard to spot.

If I've learned one thing from my years of experience as a sys admin and software developer, it's that just because something works for me doesn't mean that it will work for anyone else Smile


I suppose you did not change or rebuilt the firmware image before flashing it into your RT_AC68U?

Can you try uncompressing the ebtables.gz file in your Mac and check the file type using the ‘file’ command? If it shows ARM executable, try to copy the uncompressed ebtables file from your Mac to your router and try again. Be sure to make the file executable again before you try.

If it’s the same problem again, it could be permission issue with the shared libraries used by ebtables. Easiest solution for you, like what @egc suggested, is to try Kong’s build.
Sponsor
ibrewster
DD-WRT Novice


Joined: 04 Oct 2010
Posts: 28
Location: Fairbanks, AK

PostPosted: Mon Nov 20, 2017 0:50    Post subject: Reply with quote
egc wrote:
Your Asus router has almost the same broadcom internals,so I do not think that is to blame.

Ok, that makes sense
egc wrote:
One thing comes to my mind, do you have jffs2 support enabled on administration/management? There have been reports of this kind of behaviour with jffs2

No, it is disabled. Should I try enabling it?
ibrewster
DD-WRT Novice


Joined: 04 Oct 2010
Posts: 28
Location: Fairbanks, AK

PostPosted: Mon Nov 20, 2017 1:19    Post subject: Reply with quote
quarkysg wrote:
I suppose you did not change or rebuilt the firmware image before flashing it into your RT_AC68U?

Nope. I try to avoid things like that Smile
quarkysg wrote:
Can you try uncompressing the ebtables.gz file in your Mac and check the file type using the ‘file’ command? If it shows ARM executable...

Now THAT was quite informative. For some reason after running gunzip, the file command indicated that the expanded file was still a gzip file. So, I unzipped it *again*. Now file indicated an ARM executable properly, the file size was about twice what I had been seeing before, and low and behold, when I copied it to my router, it worked! Apparently, somehow, my computer or browser or something had double-compressed it. Go figure. In any case, it is now working as expected. Thanks for the suggestion!
jaskerx
DD-WRT Novice


Joined: 24 Aug 2016
Posts: 32

PostPosted: Wed Nov 29, 2017 18:20    Post subject: Reply with quote
<Kong> wrote:
jaskerx wrote:
I have been dealing with this bug for over a year on my r7000 waiting for someone to fix it. THANK YOU. This needs to be mainlined IMMEDIATELY! Although finding out that Kong has had this bug fixed for quite some time pisses me off. Why wouldn't BS have added it already?


Are you able to read? If yes, then scroll up, go to the first page of this thread and read quarkysg's comment, there is no fix no bug in the code nothing, he compiled the source and it works, who knows what's broken on BrainSlayers compile.

Since I'm not sure if you are able to jump to the previous page. Quoting quarkysg's comment:

Quote:

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.


P.S.: Could you do me a favor, instead of being pissed off, just piss off.


This right here is why I would never contribute a dime to this project, an hour of my time to this project, why I would never recommend this project. Just counting down the time until my r7000 bites the dust and I can "piss" off. Looking forward to seeing if this is fixed in future builds, peace out disgruntled dev guy.
<Kong>
DD-WRT Guru


Joined: 15 Dec 2010
Posts: 4339
Location: Germany

PostPosted: Wed Nov 29, 2017 20:26    Post subject: Reply with quote
jaskerx wrote:
<Kong> wrote:
jaskerx wrote:
I have been dealing with this bug for over a year on my r7000 waiting for someone to fix it. THANK YOU. This needs to be mainlined IMMEDIATELY! Although finding out that Kong has had this bug fixed for quite some time pisses me off. Why wouldn't BS have added it already?


Are you able to read? If yes, then scroll up, go to the first page of this thread and read quarkysg's comment, there is no fix no bug in the code nothing, he compiled the source and it works, who knows what's broken on BrainSlayers compile.

Since I'm not sure if you are able to jump to the previous page. Quoting quarkysg's comment:

Quote:

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.


P.S.: Could you do me a favor, instead of being pissed off, just piss off.


This right here is why I would never contribute a dime to this project, an hour of my time to this project, why I would never recommend this project. Just counting down the time until my r7000 bites the dust and I can "piss" off. Looking forward to seeing if this is fixed in future builds, peace out disgruntled dev guy.


The only thing that you contribute is accusing devs holding back fixes, see your previous comment. Nothing more to say. No project needs users like you.

Although finding out that Kong has had this bug fixed for quite some time pisses me off. Why wouldn't BS have added it already?

_________________
KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
bl@d3runn3r
DD-WRT User


Joined: 10 Jan 2010
Posts: 210

PostPosted: Fri Jan 05, 2018 15:39    Post subject: Reply with quote
Since i'm also having issues that i currently link to OpenVPN (although in TUN mode) i'm willing to try this fix that quarkysg mentioned with script from JohnS@.
But i'm wondering, should i really need to use jffs for JohnS@'s startup script?
ibrewster
DD-WRT Novice


Joined: 04 Oct 2010
Posts: 28
Location: Fairbanks, AK

PostPosted: Fri Jan 05, 2018 16:52    Post subject: Reply with quote
bl@d3runn3r wrote:

But i'm wondering, should i really need to use jffs for JohnS@'s startup script?

Well, you have to use *some* sort of persistent storage - if you just copy the file, when the router reboots it will be wiped out. I'm using a USB thumb drive, which seems to work just fine, so no, technically you don't have to use jffs. Just adjust the paths accordingly and make sure whatever you use is mounted at boot time.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12837
Location: Netherlands

PostPosted: Fri Jan 05, 2018 17:27    Post subject: Reply with quote
Just fo a test you can copy the file to /tmp make sure to make in executable and do:
Code:
mount --bind /tmp/root/ebtables /usr/sbin/ebtables


But as the former speaker pointed out after a reboot everything is gone.

I do not think that ebtables is your problem because you are using a routed VPN.

You can check by telnetting into your router and run
Code:
top
a hanging ebtables will consume close to100% cpu
_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
ibrewster
DD-WRT Novice


Joined: 04 Oct 2010
Posts: 28
Location: Fairbanks, AK

PostPosted: Fri Jan 05, 2018 17:31    Post subject: Reply with quote
egc wrote:
I do not think that ebtables is your problem because you are using a routed VPN.

You can check by telnetting into your router and run
Code:
top
a hanging ebtables will consume close to100% cpu

For what it's worth, I am also running OpenVPN in TUN mode, and I was *definitely* affected by this issue. My router is dual-core, so the system as a whole continued working, but ebtables was gobbling up an insane amount of processor power (even though OpenVPN is in TUN mode), as well as hanging during testing, until I implemented this "fix".

So it's not just OpenVPN in TAP mode that causes problems here.
wirelesskebab
DD-WRT Novice


Joined: 12 Apr 2016
Posts: 33

PostPosted: Fri Apr 13, 2018 10:53    Post subject: Reply with quote
Hi there,

I just wanted to update everyone with regard to TP-Link Archer C9 V1.

I am currently on Firmware: DD-WRT v3.0-r35681 std (04/06/18 ). The ebtables unfortunately remains broken. OpenVPN will not enable post boot or on reboot.

I have copied the ebtables file from within the 09/22/16 build while flashed and online(last known instance of OpenVPN functioning for me personally on TP-Link Archer C9 V1). I have attached the ebtables.gz to this post.

I have attached the ebtables file which was compressed from within the system on the 09/22/16 build for the TP-Link Archer C9 V1. I don't know if this is more appropriate than the one posted, however, I think since it's native to the C9 V1 and it works when used in the v3.0-r35681 std (04/06/18 ) build for the Archer C9 V1 that it might be.

After some fiddling based on the guides posted, I enabled "USB Storage Support" + "Automatic Drive Mount" under "Services" tab. I also enabled "SSH" + "Password Login" under the Services Tab (subcatagory Secure Shell). I formatted a spare USB storage device to FAT32. I ran the copy, decompress, mount, test commands and the start script swapping out the relevant lines with "/tmp/mnt/sda/ebtables /usr/sbin/ebtables" directories. The start up script in my case doesn't need the sleep line, feel free to test with or without.

If you want to bypass WinSCP (to copy, decompress and test in the router while logged into WinSCP) and take the risk that the ebtables file from the older build will not work on a future build, read the following:

Grab a spare USB storage dongle, format it to FAT32, open it, open the ebtables.gz in 7zip, drag and drop the "ebtables" file into the root of the drive in windows, for example drive "E:". Remove the USB drive, plug it into the router. At this point, you can copy the following into "Commands" under the "Administration" tab: "## script for replacing broken ebtables binary from jffs
#!/bin/sh
killall ebtables
mount --bind /tmp/mnt/sda/ebtables /usr/sbin/ebtables
/usr/sbin/ebtables -L
logger "ebtables binary replaced (workaround)"" (Remove quotations) then click "Save Startup" Reboot the router, try enabling OpenVPN with the appropriate settings for your VPN service. Click the "Status" tab then the "OpenVPN" tab. Hopefully, you should see some information populated there, instead of nothing being populated. *****This should work in theory, however, I followed the steps to copy, decompress and test the ebtables to make sure they work on the newest "DD-WRT v3.0-r35681 std (04/06/18 )" for the Archer C9 V1.

In any case, with any effected router, if you want to use a USB thumb-drive for this, you might be confused on what the directories must be changed on the commands listed in the previous guides. "/tmp/mnt/sda/ebtables /usr/sbin/ebtables" or what settings to enable to get the usb working and how to get WinSCP to connect to the router.

Thanks to "quarkysg" for original ebtables and instructions and "JohnS@" for the startup script, both posts are on the 1st page. It took a long time to figure out what to change and what to enable to go the usb thumb-drive route, I'm not exactly a brain surgeon, so hopefully this will help someone who wants to do this via usb. Hopefully posting the C9 V1's ebtables isn't irrelevant. Let me know if I need to edit this to include more credit or something. Shocked

To elaborate, in my case on the 04/06/2018 c9 v1 build using a usb thumb-drive with the 09/22/2018 c9 v1 ebtables and the startup script minus the sleep command, OpenVPN client initializes immediately on boot and CPU usage will decrease significantly to levels seen with prior working builds.

Thanks!



ebtables.gz
 Description:
ebtables from 09/22/16 Archer C9 V1. (Last known working OpenVPN version for me personally) currently working for TP-Link Archer C9 V1 v3.0-r35681 std (04/06/18 )

Download
 Filename:  ebtables.gz
 Filesize:  30.89 KB
 Downloaded:  502 Time(s)

wirelesskebab
DD-WRT Novice


Joined: 12 Apr 2016
Posts: 33

PostPosted: Thu Apr 19, 2018 8:50    Post subject: Reply with quote
Confused

After testing, implementing this workaround on the TP-Link Archer C9 V1 w/without OpenVPN breaks QoS entirely, causes severe buffer bloat, inconsistent speeds, extreme jitter and packet loss.

I have no idea what to do from here. I am pleased to report however that the Archer C9 V1 JFFS has space available for the 65 KB file when mounted. SO there's that at least.

I have heard that compiling dd-wrt framework is difficult, but I have read some reports here stating that the issue is resolved when doing that. I wonder if I do all of that if it will give the same results. I don't see why it would be any different? Unless this is sort of like a symlink and there is added overhead going to and from for ebtables. Crying or Very sad

I have absolutely no idea how to even get the specific source to my device without pulling 18 gigs to my VM. Sad

Has anyone experienced this issue? Sad

Edit: Yeah,no, there's pretty much no chance I can compile it on my own to test. Ebtables workaround on th TP-Link Archer C9 V1 will result in high latency, high buffer bloat, eratic speeds ignores QoS settings and max rates, drops packets. If the fix is not implemented and OpenVPN is not enabled, QoS returns to normal as do the other issues. Not good.
BrainSlayer
Site Admin


Joined: 06 Jun 2006
Posts: 7463
Location: Dresden, Germany

PostPosted: Tue May 22, 2018 10:10    Post subject: Reply with quote
about the ebtables issues people mentioned. the commandline utility cannot cause any load since it virtually does nothing than just telling the kernel what todo.
but some hints

before using ebtables you must enable the kernel bridging filter capabilities by loading the required ebtables kernel modules (ebt_802_3.ko ebt_arp.ko ebt_dnat.ko ebt_ip6.ko ebt_log.ko ebt_mark_m.ko ebt_pkttype.ko ebt_snat.ko ebt_vlan.ko ebtable_filter.ko ebtables.ko
ebt_among.ko ebt_arpreply.ko ebt_ip.ko ebt_limit.ko ebt_mark.ko ebt_nflog.ko ebt_redirect.ko ebt_stp.ko ebtable_broute.ko ebtable_nat.ko)


and it may makes sense to enable

/proc/sys/net/bridge/bridge-nf-call-iptables

otherwise ebtables might not do anything

at all using ebtables filtering takes more cpu load than standard iptables filterin outside of the bridge. this isnt nothing new and as more packets are flowing as higher the cpu load goes. if you wont see higher cpu load its more likelly that ebtables isnt working. this is why dd-wrt doesnt use ebtables in standard configurations, but just of qos -> lan is enabled
depending on the traffic the cpu load can be very significant

_________________
"So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
wirelesskebab
DD-WRT Novice


Joined: 12 Apr 2016
Posts: 33

PostPosted: Thu Jun 07, 2018 1:20    Post subject: Reply with quote
BrainSlayer wrote:
..at all using ebtables filtering takes more cpu load than standard iptables filterin outside of the bridge. this isnt nothing new and as more packets are flowing as higher the cpu load goes. if you wont see higher cpu load its more likelly that ebtables isnt working. this is why dd-wrt doesnt use ebtables in standard configurations, but just of qos -> lan is enabled
depending on the traffic the cpu load can be very significant


Hi BrainSlayer,

That's interesting, unfortunately, with my TP-Link Archer C9 v1 this behavior was not present in the older build 09-22-2016-r30681-k3.10.103 in the exact same operating conditions with the same parameters. I appreciate your work.

You can verify the file is corrupt by running the command to test it, You can run the same command on an older build and then an effected build and compare the console readout and what is normal behavior while running openvpn. Sad

Thanks
https://svn.dd-wrt.com//ticket/5807
Goto page Previous  1, 2, 3 Display posts from previous:    Page 3 of 3
Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum