QoS is disabled currently and r49467 is stable in this configuration. If I enable QoS, click save and then click apply, the box seems fine.
The problem is after I enable QoS on VAP br1(or wl0.1 if unbridged), if I ever reboot, the box enters a boot loop. And the only way to recover is to reset nvram (somehow, either thru the CFE Mini or reset button, either way allows me to start configuring dd-wrt from the start again)
Same here, that was my third router update in a row, and the only one one with a QoS configuration.
I was upgrading them from a good old r40270M kongac to r49492 std (nvram erase, reboot, manual reconfig, etc.) The first two were done in roughly an hour (1xR7000, 1xR8000), it took me couple more hours to pinpoint the issue with the last one (1xR8000). To break the loop without having to restart from stock, ended up timely injecting by scp a script to replace nvram with the last r49492 backup I made before configuring the fluff (I always make 2-3 of those during the configuration, good habit...)
I have also have a deactivated WAN. Without QOS it works.
Just adding to your thread: I had flashed the r49492 build onto my EA6200 what is weird and surprised me today which would have been a 24hr uptime, I was adding a static ip and all of sudden it stated restarting please wait, I was like no why? anyhow the build is okay, qos didn't give me any problems especially setting the port to lan & wlan and switching back to wan still didn't give me any issues, even after setting up mac priority or netmask priority it didn't give degrade or break anything but I do have to apply settings twice for qos to work or the network will stop working and this has been like this since the last time I had flashed dd-wrt but this seems to happen with qos every other settings done this doesn't occur, setting tcp packets works till the uploading starts then latency starts to rise a bit just enough if your a gamer, disabling them will stop this and keep your latency down when qos is configured properly. If service priorities is set be sure to check it as well while using some adding port ranges I notice the same behavior as the tcp packets setting while ingress was work the outbound would give to latency and so I disable it to ensure if I was playing a game I wouldn't lag, stutter or freeze.
So far the r49492 build is working okay at least for my needs for my network, qos isn't always on just for gaming sessions using mac priority.
CTF and CTF & FA will by design break port forwarding and QoS, because they are both by definition bypassing all this traffic shaping and other rules in order to do their job.
I saw a few of your comments about CTF being incompatible with QoS on a few other threads. I have purposely disabled CTF while trying to debug this issue.
the-joker wrote:
OK that said, when you enable CTF & FA it needs two reboots, the first loads the modules the second enables the onboard chip that handles the HW acceleration for FA. proper initialization is required...
Wow, I had not seen a anything before that outlined the two reboots requirement for CTF & FA(I guessing it's in some wiki that I have not read carefully enough to catch...yet). I will keep the 2 reboots in mind when I work with CTF & FA in the future.
the-joker wrote:
...so I hope this isn't what the boot loops are that you noticed. I may have missed your detailed explanation.
I have disabled CTF for debugging this QoS rebooting loop issue. In the initial posts for this thread, I included a screen shot titled "FYI, Engine should be disabled (but syslog shows CTL messages).png" This png shows CTF is disabled; yeah, on review - It was a poor choice for an image title.
The next post in this thread show that the values for the nvram variables sfe, stp & ctf - just in case there was any doubt. As a sanity check for myself, I wanted to be sure, they were all disabled while debugging this issue.
Neither SFE (Fast-classifier from QCA) nor CTF/CTF+FA function together with QoS in DD-WRT. Before CTF was re-introduced along with FA, SFE and QoS could *not* be enabled at the same time because they cannot coexist. SFE does essentially the same thing as CTF.
One of the initial posts for this thread includes a screenshots that show that sfe & ctf are disabled via the GUI for my test configuration. Also, as a sanity check, I included additional screenshot which shows the nvram values for sfe & ctf are disabled, ie zero(0).
I have been reading the recent build threads. For the moment I decided to avoid using the the CTF feature; just to avoid some of the very beta type testing issues that have come up recently.
And I posted it early in this thread because I noticed that more than a few times, the suggested fix on the build threads was to disable CTF.
A few days ago, I upgraded my EA6700 to the new r49492 build via the cli. I reset nvram, just to be sure I started clean. (ie wget, write, nvram erase, reboot)
I then rebuilt the configuration settings, one item at a time. Testing as I went.
A few small changes to the config I posted at the beginning of this thread:
1) I set up VAP on wl0.1 without using the bridge br1.
2) I enabled wl1(5Ghz)
3) I did not use dns-options to "manually" configure a dnsmasq's DHCP for br1; there was no br1. I used dd-wrt's GUI for additional DHCPs(on the networking tab) to enable a DHCP server for wl0.1.
I had disabled wl1 for the initial testing, because I read a few comments on the build threads that 5GHz might be an issue on some recent builds.
With this configuration, I ran the EA6700 overnight. Everything was just fine(without QoS). I added a post to the r49492 build thread, saying it was fine.
I then enabled QoS, added interface wl0.1 (instead of br1, since there is no br1 in this test configuration) and set wl0.1 with a traffic on LAN limited to 500kbit, clicked save, clicked apply. The EA6700 seems happy. However, if I reboot, the EA6700 with r49492 enters a reboot loop. I can only recover by resetting nvram through either using the CFE mini browser's nvram reset or holding down the reset button.
As an aside, an EA6500v2 & EA6900 arrived from two separate eBay purchases. Hopefully they both work. Once I get the CFE issues fixed, I will try setting these up to debug the QoS issues. Honestly, it was very annoying to losing the home while debugging this issue; and then struggling to get it back.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Tue Jul 19, 2022 22:16 Post subject:
SO in essence it seems the only constant variable is enable QoS all OK, reboot and it goes into a boot loop, right?
You know, by default you have Bootfail options on the Admin page, after 5 failed boots the router resets itself, so how many boot loops did you go though?
On the other hand, the only way to get to the bottom of this, is with a serial connection and serial logs of this all happening, the logs will show what may be going on with indicators where to look at.
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Tue Jul 19, 2022 23:07 Post subject: Re: Boot loop (r49418,r49467): when QoS enabled (VAP br1)?
Along with CTF-FA/SFE not able to be enabled with QoS (this is a given, not an exception) which will result in the possible bootloop/bootfail, there is also the fact that you're running XWRT-Vortex CFE, I presume. I'm sure @egc can clarify here on any possible caveats to doing 'nvram erase && reboot' with the modified CFE in place...
ZenInTexas wrote:
Router/Version: Linksys EA6700/V1(CFE with 32k Fix)
Posted: Wed Jul 20, 2022 2:33 Post subject: Re: Boot loop (r49418,r49467): when QoS enabled (VAP br1)?
kernel-panic69 wrote:
the fact that you're running XWRT-Vortex CFE, I presume.
Yes, I am running a modified Vortex CFE. The idea that it might be CFE related also occurred to me. For the EA6500v2, I decided to use the tomato CFE, just to change things up a little.
I finished converting the new to me EA6500v2 with a 32k CFE fix & loading it with dd-wrt r49492. It's configured identically to the EA6700 r49492(without QoS). I am going to let the EA6500v2 run overnight to be sure it's stable.
A few days ago, I upgraded my EA6700 to the new r49492 build via the cli. I reset nvram, just to be sure I started clean. (ie wget, write, nvram erase, reboot)
I then rebuilt the configuration settings, one item at a time. Testing as I went.
A few small changes to the config I posted at the beginning of this thread:
1) I set up VAP on wl0.1 without using the bridge br1.
2) I enabled wl1(5Ghz)
3) I did not use dns-options to "manually" configure a dnsmasq's DHCP for br1; there was no br1. I used dd-wrt's GUI for additional DHCPs(on the networking tab) to enable a DHCP server for wl0.1.
I had disabled wl1 for the initial testing, because I read a few comments on the build threads that 5GHz might be an issue on some recent builds.
With this configuration, I ran the EA6700 overnight. Everything was just fine(without QoS). I added a post to the r49492 build thread, saying it was fine.
I then enabled QoS, added interface wl0.1 (instead of br1, since there is no br1 in this test configuration) and set wl0.1 with a traffic on LAN limited to 500kbit, clicked save, clicked apply. The EA6700 seems happy. However, if I reboot, the EA6700 with r49492 enters a reboot loop. I can only recover by resetting nvram through either using the CFE mini browser's nvram reset or holding down the reset button.
As an aside, an EA6500v2 & EA6900 arrived from two separate eBay purchases. Hopefully they both work. Once I get the CFE issues fixed, I will try setting these up to debug the QoS issues. Honestly, it was very annoying to losing the home while debugging this issue; and then struggling to get it back.
I mentioned that the configuration your attempting maybe the cause as you had mentioned it the configuration was running fine until qos was enabled for the wl1.1.
Was this config still a wap or was the config in question setup on a gateway config?
If I enable qos and I had mention there is a big delay before qos is activated and if I don't press apply twice it will not activate and the time before it does active is like
--- google.com ping statistics ---
79 packets transmitted, 33 received, 58.2278% packet loss, time 206ms
rtt min/avg/max/mdev = 32.125/33.820/41.512/2.370 ms this is the only issue so far that I encounter on this build r49472 on to my EA6200 it does as well have a modified cfe from FreshTomato flashed for sometime now and while this build has been up for a little over 2 days I haven't experience nothing to serious other than what I had mentioned with qos but aside from that it running both radios are up nothing to out of the ordinary except my EA6200 is in front of the network and in my previous post was running in Station bridge mode but qos didn't work and no boot loop.
For testing purposes when you have enough time over your network: setup the EA6500v2 again but setup as the gateway not in any other config, clone the wan of the main router to the EA6500v2, setup the vap separate vlan if you need to, you should be able to use both wifi radios without having to disable any of them and try qos again.
Narrowing down your issue to either the config or the build would be important to know for you and development.
I setup the new to me EA6500V2 with r49492 using a FreshTomato CFE (different CFE than the original thread post device, EA6700V1). I let the EA6500V2 run r49492 as a WAP & VAP, but without QoS enabled for a day to verify stability.
Then I slowly enabled QoS; enabled QoS, clicked apply(1st time), clicked apply(2nd), waited until it settled, rebooted, Added wl0.1(configured as unbridged) interface to QoS limiting, clicked apply(1st time), clicked apply(2nd), waited until it settled, rebooted, Changed QoS port from WAN to "WAN & WLAN" clicked apply(1st time), clicked apply(2nd), waited and rebooted. I let EA6500V2 r49492 run with QoS run for a day to see if any problem appeared, it ran just fine.
Then, I upgraded the EA6500V2 r49492 to r49544 and let it run with QoS overnight. Version r49544 on EA6500V2/(with FreshTomato CFE fix) has not entered a bootloop. I have not checked to see if QoS actually traffic limits(yet). Honestly, I am just pleased that the EA6500V2/(with FreshTomato CFE fix) does not boot loop.
Next I plan on using a FreshTomato CFE on the EA6700V1 to see if the boot loop goes away on that one.
It is possible that the boot loops were due to a mistake on my part when applying the Vortex CFE for EA6700 & EA6400. Or possibly a mistake in the Vortex CFE itself(or instructions on how to use it). I don't have a good method of testing that hypothesis.
Was this config still a wap or was the config in question setup on a gateway config?
WAP only
native_tx wrote:
If I enable qos and I had mention there is a big delay before qos is activated and if I don't press apply twice it will not activate...
I did not know about the need to click apply twice. @the-joker mentioned that as well for CTF & FA configs. I took both of the suggestions and did click apply twice.
native_tx wrote:
Narrowing down your issue to either the config or the build would be important to know for you and development.
At this point, everything so far points to my configuration not the build. I plan on updating the EA6700/V1 & EA6400 with FreshTomato CFE's; I will post what I find(it may take a week).
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Fri Jul 22, 2022 19:09 Post subject:
CTF & FA does not require two apply clicks, I said it requires two reboots, not even close to being the same. These reboots are automatic DD-WRT side, CTF 1 reboot on selecting and clicking apply, CTF & FA two reboots upon selection and clinking apply. At least thats the behavior last time I tested, even if my ISP speed doesn't require it.
You are however using CFE's that aren't stock, these could very well be not fully compatible with DD-WRT, we know that its a a FT CFE that likely meant to work with FT firmware and everything else be dammed. Does it even register over there as a external cause likely causing issues?
You cant just mix and match and hope for the best. Its not even logical unless you have the skills to tell whats what.
XWRT-Vortex CFE is an AsusWRT / Asus CFE bootloader with the mini webserver for recovery that is perfectly safe to use with DD-WRT if properly modified as twindragon6 did. I guess you've forgotten about that conversation? <lol> <eyeroll> _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
CTF & FA does not require two apply clicks, I said it requires two reboots, not even close to being the same.
As I wrote, I combined two suggestions from two different people. Yes, I know that's not what you wrote. However, I thought it was appropriate to reference your suggestion (I apologize for that). If you recall, I am not running a configuration that uses CTF & FA. I am just trying to get QoS working with a VAP.
However, I did not know about the internal code for CTF & FA enabling that reboots the router twice - At this time, I have not had the luck to find the right wiki's or viewed the right thread that discusses that detail.
the-joker wrote:
You are however using CFE's that aren't stock, these could very well be not fully compatible with DD-WRT, we know that its a a FT CFE that likely meant to work with FT firmware and everything else be dammed. Does it even register over there as a external cause likely causing issues?
You cant just mix and match and hope for the best. Its not even logical unless you have the skills to tell whats what.
You and every other user has to understand the implications, hence my comments, as usual Im willing to eat my non existing hat when otherwise is proven.
Are you saying that we should throw out boxes that have bugs in outdated firmware?
And never attempt to run dd-wrt on devices that have bugs in original firmware?
Or are you implying, that we should never ASK for help or otherwise post about issues for devices that don't conform to some unstated(or personal) requirement?
I am curious what the goal of dd-wrt is today regarding old boxes with bugs in the original firmware.
CTF & FA does not require two apply clicks, I said it requires two reboots, not even close to being the same.
As I wrote, I combined two suggestions from two different people. Yes, I know that's not what you wrote. However, I thought it was appropriate to reference your suggestion (I apologize for that). If you recall, I am not running a configuration that uses CTF & FA. I am just trying to get QoS working with a VAP.
However, I did not know about the internal code for CTF & FA enabling that reboots the router twice - At this time, I have not had the luck to find the right wiki's or viewed the right thread that discusses that detail.
the-joker wrote:
You are however using CFE's that aren't stock, these could very well be not fully compatible with DD-WRT, we know that its a a FT CFE that likely meant to work with FT firmware and everything else be dammed. Does it even register over there as a external cause likely causing issues?
You cant just mix and match and hope for the best. Its not even logical unless you have the skills to tell whats what.
You and every other user has to understand the implications, hence my comments, as usual Im willing to eat my non existing hat when otherwise is proven.
Are you saying that we should throw out boxes that have bugs in outdated firmware?
And never attempt to run dd-wrt on devices that have bugs in original firmware?
Or are you implying, that we should never ASK for help or otherwise post about issues for devices that don't conform to some unstated(or personal) requirement?
I am curious what the goal of dd-wrt is today regarding old boxes with bugs in the original firmware.
It is good that you have it working the way you want as far as joker's comment let's move on, the modified cfe works fine for either projects but for me the r49544 still pauses when enabling qos but as long as it works it's acceptable except the "submitfooter" its a little anoying moving up and down as you scroll the page covering areas of the page with the exception that on firefox it is still quick but on google it slow transitioning through to other tabs I didn't experience this on the other build but for the most part I'd say you could mark your post as "Solved" good job I do feel most to a lot users that don't use "SFE/CTF" will have it disabled when using qos and those who need it will of course have it enabled so they receive their full bandwidth, the reboots dd-wrt does at some point after save/apply it's just has to be that way, no worries.
