The problem AFAICT with snapshots is that I can't just install one and leave it for months/years due to issues like kernel module packages being updated beyond compatibility with the snapshot's kernel.
I went back to Reboot (17.01.4, r3560-79f57e422d) for various unrelated reasons (mainly SQM QoS being garbage, and compiled-in to my custom build), and can confirm it still has the WiFi dropout issues. I will probably get fed up with the WiFi issues in a few days, enough to go back to building a custom firmware (without SQM this time), and will try to remember to test it out without modifying anything... Luke On Saturday 26 May 2018 18:20:47 Russell Senior wrote: > For reference, I'm running a recently built "OpenWrt SNAPSHOT, > r6951-22c16c5d82" on a Buffalo WZR600DHP and I am not seeing the problem > you describe. > > On Sat, May 26, 2018 at 10:59 AM, Luke Dashjr <[email protected]> wrote: > > On Saturday 26 May 2018 17:11:56 you wrote: > > > On Sat, May 26, 2018 at 12:34:30PM +0000, Luke Dashjr wrote: > > > > Half a year ago, I went to the trouble to identify the exact cause of > > > > the > > > > > > regression since 2015 where Openwrt/LEDE would drop off wifi every > > > > few hours: > > > > > > > > https://bugs.openwrt.org/index.php?do=details&task_id=1180 > > > > > > > > There's even a clear and obvious solution: just remove the broken > > > > patch. > > > > > Thank you for bringing this up. I haven't been aware of the ticket on > > > the bugtracker and can confirm this or a very similar problem on all > > > ath9k devices. > > > So do I get right that you can also confirm the problem exists and have > > > tried significantly hard to make sure that removing patch > > > 355-ath9k-limit-retries-for-powersave-response-frames.patch > > > and/or completely disabling power-management resolves it? > > > If so, please share in more detail what exactly you have tested, on > > > which exact hardware and in which way(s) you can reproduce that the > > > problem does exist for sure or doesn't exist for sure. > > > > My personal setup for testing is as follows: > > > > Two Nest thermostats, which upon connecting to my network, I shut off the > > NestLabs application (which sets up the wifi, among the thermostats' > > primary > > controls) and launch my own (which doesn't handle wifi). The relevance of > > these is limited only to detecting the bad wifi conditions - they could > > presumably be replaced with any other device that connects once and does > > not > > reconnect when the network fails. > > > > Buffalo WZR-600DHP router. Until 6 months ago, I ran Attitude Adjustment > > for > > years with no issues. Due to exploits (I forget which), I tried upgrading > > to > > LEDE, and found the wifi would drop out after a few hours. I tolerated > > this > > problem for a few weeks before going to the effort to do an exhaustive > > git bisect, building new firmware images to try after confirming > > stability for a > > few days (or instability usually within a day). > > > > Last November, after isolating the problematic commit to > > b30e092de65ca7be7cb277f934016484137d924c, and the problematic patch to > > (at > > the time) 305-ath9k-limit-retries-for-powersave-response-frames.patch, I > > checked out 6b6578feec74dfe1f5767c573d75ba08cc57c885 (HEAD of the > > lede-17.01 > > branch at the time, I believe) and created the following patch: > > > > --- > > a/package/kernel/mac80211/patches/305-ath9k-limit-retries-for-powersave- > > response-frames.patch > > +++ > > b/package/kernel/mac80211/patches/305-ath9k-limit-retries-for-powersave- > > response-frames.patch > > @@ -20,7 +20,7 @@ Signed-off-by: Felix Fietkau <[email protected]> > > - struct ath_buf *bf) > > + struct ath_buf *bf, bool ps) > > { > > -+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(bf->bf_mpdu); > > ++ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(bf->bf_mpdu); > > ps=false; > > + > > + if (ps) { > > + /* Clear the first rate to avoid using a sample rate for > > PS > > frames */ > > > > I ran this build on my router from November until February. In February, > > I merged it into 92ea65b36aa783f28accd01fa4850f3640d2c6b6 and upgraded my > > router, and have been running that ever since. > > > > I can't say wifi has been 100% reliable since November, but drop-outs are > > maybe monthly instead of every few hours. > > > > > > Yet still it's been 6 months with nothing done... not even an > > > > acknowledgement that the bug report was seen by a human. > > > > > > Probably due to the bug description which makes it look like if it was > > > a device-specific problem and you could only reproduce it on those > > > specific Buffalo boxes... > > > > Don't have anything else to test on :) > > > > > > I even emailed nbd (who added the broken patch) back in November, and > > > > heard nothing back from him either. > > > > > > > > Is Openwrt even being maintained at this point? Has everyone moved on > > > > to > > > > > > yet another project or something? > > > > > > nah. LEDE has merged back with OpenWrt, as you can see in the git > > > history, we have been very active in the recent past and a new release > > > is coming up very soon (18.06). It's kinda true that currently nobody > > > feels too responsible for ath9k, because most people developing code > > > for new hardware have moved on to mt76, ath10k and so on. > > > I agree that this is not a very desirable situation and as a community- > > > driven project with most contributions being unpaid for, there is not > > > much we can do about it. In that sense, you just did something valuable > > > by bringing up the culprit patch responsible for all our ath9k problems > > > and hopefully someone with that hardware around will find the time to > > > come up with a good solution. > > > > Somewhat off-topic, but... is there any company today that financially > > supports the work/development of Openwrt? As noticed, my router is a bit > > out > > of date, and when I upgrade, I'd prefer to support a company that > > supports the free software firmware community. :) > > > > Luke > > > > _______________________________________________ > > openwrt-devel mailing list > > [email protected] > > http://lists.infradead.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/listinfo/openwrt-devel
