Reporting back, After rolling back to 47692, connections in my setup now appear stable - appx 16 hrs. (though i have only hit about 60% peak load)
The WDS setup also appears stable now. perofmance is better and throughput is more consistent without latency spikes.
I also haven't lost the ability to manage the WDS STA through ui, connected through WDS AP, as i was occasionally having on december builds. My config is in a previous post on this thread
Another update: 22 hours in and had another disconnect. I'll try going back to a 2020 build to see if that works if there aren't any other suggestions.
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Tue Jan 04, 2022 16:46 Post subject:
I'm wondering if a conflict in country code on the clients is causing the STA to do something weird because it's using Canada...
You could also be getting interference from other neighboring devices trying to associate to the STA because it's power is stronger than surrounding routers which are being limited to 100mW (20dBm) in BA while in Canada you are allowed up to 30dBm (1000mW) and you essentially are broadcasting your signal 50% stronger than any neighbor at 23/24dBm.
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Tue Jan 04, 2022 17:59 Post subject:
GamerHD wrote:
msoengineer wrote:
Try using the right country code in the drop down and see if anything improves.
Apparently my country isn't listen on the list when selecting the regulatory domain. I'll try and select one that has matching regulations.
Also, I read about Airtime fairness and that it can potentially cause disruptions so I'll disable that as well.
Airtime fairness is actually a really important feature to use especially on 2.4ghz to make sure that no client eats up all the network bandwidth available. But since we haven't been able to find anything specific, go ahead and give that a try too, maybe you'll find a device that is trying to dominate the bandwidth and find the real issue that way... who knows ¯\_(ツ)_/¯ _________________ FORUM RULES
Another thing I noticed is that I can't get full 150 Mbps on 5GHz (150 is what I get via wire) while I used to be able to get that some time ago (irrelevant to the airtime fairness option), currently topping out at 130 Mbps (on devices as well as on the bandwidth monitor from ddwrt). I've got Short GI and preamble enabled as well as using it on 80hz width on channel 132 and extending up by +6.
Uhm, the second link I get and I do understand that Wifi is nowhere perfect in some scenarios and how it works on a somewhat slightly more than basic level. What I don't understand is what does SuperG have to do with not getting a certain speed that was otherwise possible in the past via 5GHz Wifi. I might be missing something obvious here but can't tell what.
I pinned down the reason for not having the full 150 Mbps on 5GHz. Turns out SFE couldn't be enabled due to a VAP being unbridged (guest network). Changing that to bridged again allowed me to enable SFE which allowed for a higher throughput (150Mbps).
Now if there was a way to create a guest network without unbridging the VAP (which wouldn't make sense I think) or to somehow enable SFE even if there is an unbridged VAP (seen a post where it was mentioned that there were no issues running SFE and unbridged VAP), that'd be nice but probably can't have them all.
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Wed Jan 05, 2022 19:57 Post subject:
The link is indeed for super g but the actual section you see when you click on the link talks about wireless channel settings and choosing the right channels.
You're using DFS channels...
I thought it would be intuitive enough if you click on the link first to read...
Guess I have learned my lesson again about TL:DR...
Quote:
Recommended Setting: For either 2.4ghz or 5ghz-Use the cleanest channel with the least noise, most stable throughput, & lowest latency jitter. For 5ghz try to stick to the following channels: 36-48 or 149-161. Read about DFS channels in the extensions section below and the links at the bottom to understand more why to never use the channels in the DFS subset and to only use the ones in the suggested range above.
and
Quote:
**DFS Channels are 52-144. This means that you might have clients that won't work on these channels because they have been hard coded not to. Your Mileage may vary.
'''''*WARNING ABOUT USING DFS Channels: Using DFS can significantly increase 5 GHz association times because devices (STAs) can only passively scan for available APs. So instead of being able to send out a probe request and waiting for APs to reply, a STA using DFS channels must wait until an AP announces itself. You wouldn't think this would make much difference, but when switching from running 2.4 to 5 GHz tests, it took over a minute to find and associate to the router's 5 GHz SSID. IF YOU USE DFS CHANNELS MAKE SURE TO TURN OFF RADAR DETECTION TO AVOID THIS REQUIREMENT. DON'T BREAK ANY LAWS IF YOU LIVE NEAR A RADAR STATION!'''''
The link is indeed for super g but the actual section you see when you clike on the link talks about wireless settings and choosing the right channels.
You're using DFS channels...
I thought it would be intuitive enough if you click on the link first to read...
Guess I have learned my lesson again about TL:DR...
I realized that. Moved away from it to channel 48 extending down to 42. Seems to resolve an issue that I didn't even notice until I read about it, that being 5GHz wifi not getting "recognized" right away after being connected to 2.4GHz. I knew about the DFS channels but forgot about em. Thank you anyway. However the case about slower speeds has been resolved by turning on Shortcut Forwarding Engine at the cost of not having the guest network unbridged.
Now about the disconnecting WDS Stations. I've exhausted every possible setting that I could find and decided to try the recommended builds from the Low Memory builds sticky thread. Just finished setting it up and will report how those builds work (I know mixed builds aren't recommended but not sure what else to do). If you have any other suggestions I'd appreciate it!
Update: Running build 47618 on the Archer C7 v5 as WDS AP (5GHz 80VHT 48+42 channels, 2.4GHz HT40 6+10 channels) and build 44715 on two WDS Stations (WR1043ND v2 and WR841ND v8 (no VAP on this one)), uptime 36* hours and connecting uptime 36 hours.
* The WR841ND v8 had 1 reboot actually in the first 12 hours, appears to have ran out of memory (hovering very close on the edge of running out always)
Posted: Sun Jan 09, 2022 18:04 Post subject: [SOLVED by downgrade] WDS Stations frequent disconnects
Final Update before marking it resolved by downgrade:
Over 2 days of connection uptime on build 44715. Updated (and reset + set up again to make sure everything is clean) to 47618 (and a few builds above for more tests) and WDS Stations can't keep a steady connection for more than a few hours. Conclusion, something between 44715 and 47618 went wrong for WDS Stations.
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Mon Jan 10, 2022 1:52 Post subject:
If you want this fixed, you need to narrow it down to a more specific range. Right now your range is too far apart to know where things went bad for sure. You need to keep playing around to find it. 2903 changes were made in between; that's way too many things to try and narrow down.
Perhaps go back a few months in 2021 and report what you find. Until you get to a range of less than 20-40 SVN builds- we're in no position to further help you out in determining what's wrong. You're more than welcome to look at SVN.dd-wrt.com yourself to see when drivers were updated and find something that might be of significance and then test it out in your environment. _________________ FORUM RULES
If you want this fixed, you need to narrow it down to a more specific range. Right now your range is too far apart to know where things went bad for sure. You need to keep playing around to find it. 2903 changes were made in between; that's way too many things to try and narrow down.
Perhaps go back a few months in 2021 and report what you find. Until you get to a range of less than 20-40 SVN builds- we're in no position to further help you out in determining what's wrong. You're more than welcome to look at SVN.dd-wrt.com yourself to see when drivers were updated and find something that might be of significance and then test it out in your environment.
I have a second WR841ND v8. Will put it to use as a test device and gonna keep jumping builds. Will tolerate a stable connection of 24hrs uptime on it. If and when I find what build or at least a smaller range of builds where the issue appeared I will report.
