I've used sysupgrade between different builds, and different versions of openwrt on the same router without hassle.
This is mostly correctly, with a small caveat applying to version 17.01.x or snapshots predating 18.06.x (those need tftp in order to install properly, due to the changed NAND partitioning). But you can only install this while running OpenWrt, not dd-wrt (in this case you'd need to revert to the OEM firmware first), not the OEM firmware (the normal installation procedures described in the wiki apply, using the factory firmware).
1 Like
I am very interested in your tweaks, and want to try them in hnyman's build. Do they make the router more powerhungry? I've seen many (unconfirmed) tweaks, some of them always run the cpu on max freq.
These are the only tweaks you added in /etc/rc.local?
fyi
I had to revert to ddwrt for now. I want to get back on openWRT, but I had a very angry family yesterday and needed to get something that just 'works'. All 4 of us are at home and all rely on the network to get work done (at least 2 of us do).
I kept getting a dropped network on hnyman's R13768 build. It would loose internet connectivity to the cable modem. Same happened at least once with the R13625 build as well. It starts by dropping some connections then all of them. Restarting the network would allow a re connection then it would start over again dropping things. This is with cabled connections to the router, not just WiFi.
I keep getting dropped wifi connections on the hnyman's 19.07.3 and R13625 build, so, basically, none of the current builds work for me. I am back running ddwrt and it is rock stable though missing a lot of desirable features... I'll wait a while for these ath10k bugs to get worked out. Maybe a 20.07.1 build? I'm surprised that I seem to be the only one with these issues. I have about 25 devices connected on a variety of connections 2.5Ghz, 5Ghz, cable plus 3 virtual machines on my NAS, so does that make me a power user?
what were the symptoms, out of interest?
When I was getting dropped WiFi, it was as above:
ath10k_pci 0000:01:00.0: Invalid peer id 16 peer stats buffer
and
ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
and
ath10k_pci 0000:01:00.0: Invalid peer id 41 peer stats buffer
[286759.259184] ath10k_pci 0000:01:00.0: failed to lookup txq for peer_id 41 tid 1
These were with different versions of hnyman's builds. I started with a mainline build as I had originally started with 19.07.3 standard for the R7800 and it was atrocious with wifi disconnects, so I tried a mainline build and it was better, but still had wifi issues. So then I found this thread and tried hnyman's mainline build, first as I thought it was probably closer to the mainline I was having decent luck with. Also had issues with wifi disconnects, so I tried the R13768 build and it was terrible. I never gave hnyman's 19.07.3 build much trial just because I was having so many problems with the normal R7800 build.
The symptoms of the disconnecting network were: Reboot router and all is good. Then my wife would complain 'no internet'. I'm working away locally and do not notice. Router still connect-able, everyone still had an IPv4 address but the IPv4 address from Xfinity would go away and then some of my Son's threads would go away, but he would still be connected as a voice link, just no other internet. I would go to the router page and restart ipv4 and ipv6 WAN links. and it would come back for a while then it would do the same thing, again. Power cycled the modem, power cycled the router and it happened again. Everyone angry. 
So I reverted to an old image of ddwrt that always just worked, just no features like banip, adblock, etc. Also, the openvn setup is much easier under openWRT I do not yet have my openvpn server back running under ddwrt... I want to use it, but it seems I tried it at a time when the drivers are all in flux for wifi.
ah...i meant more the latest master build, with problems with wired connections.
i haven't had many wifi problems, except for the daft Sky Q box which seemingly disconnects itself and then claims no connectivity. perhaps it's a similar problem.
Been there recently. Stick with what is working for now.
These symptoms sound familiar to me for this ISP and occurred whenever I made a significant change to my WAN (i.e. like changing routers or even router OS, i.e. likely not all of your issues are openwrt related).
If you continue to have issues keep an eye on your cable modem, see this. In particular, I recall downstream "RxMER" needed to be about 33+ for a docsis 3.0 modem and upstream "Power Level (dBmV)" need to be ~ 40.
When I experienced similar symptoms, I'd reset the modem and it would be fine for a bit. Then the upstream channels would degrade (power level increasing to 50+) downstream RxMER (aka SNR) would drop below 33, eventually I'd lose 2-3 upstream channels (out of 4 total), and eventually the modem would fail.
Patiently and repeatedly resetting the modem would eventually get it to settle down. However, I'd have to do this several times a day over a period of a week or two. Just going back to my prior router/os seemed to help.
HTH
I had the same problems with my cable connection. The modem was fine, and so were my routers. All the inside connections were tight and sound.
Of course the people answering the online chat at Spectrum wanted to have a technician come by and rummage around, but that had happened twice already, and nothing had changed. This is how I got a fix:
I suggest taking a look at the logs from the modem. (Try 192.168.100.1 to access it.) I was getting tons of errors of various kinds, but the T-2, T-3, and T-4 errors showed that the problem was upstream (what they call "the plant"). That's why the upstream channels kept dropping. Basically the cable modem was trying to "phone home," but the pings were not getting to Spectrum. Seeing no reply from my modem, they dropped the connections.
Once I explained what was going on (and believe me, it took a lot of repetition), they were able to fix it remotely. The whole neighborhood had been having issues, but this fixed everybody's connection all at once.
Do your own research. Once you see your modem logs, copy and paste some of the error messages into Google and see what you get. It helps when you talk to the cable people. The first people you contact will not be the best and brightest, but if you really talk like you know what's up, they should escalate the issue to someone up the chain who can get you fixed up.
Oh, and apologies to @hnyman. This is NOT particular to his build
1 Like
Anyone noticed wifi connection instability from certain clients with the most recent 3-4 builds? I suspect it all started for me with the hostapd bump. Any known issues with hostapd?
These are messages that I now often see in logread:
Sat Jul 18 13:46:33 2020 daemon.info hostapd: wlan0: STA 94:bf:2d:... IEEE 802.11: disconnected due to excessive missing ACKs
...
Sat Jul 18 15:03:32 2020 daemon.notice hostapd: wlan1: STA e8:b1:fc:... IEEE 802.11: did not acknowledge authentication response
On both 2.4 and 5GHz radios. Clients affected have strong signal, they are close to the AP, and I haven't changed channels/wifi settings in a long time. Something else is going on here, it feels like a hostapd software issue rather than a physical wifi issue. Perhaps I should try a "stable 19.07" build and see how that behaves.
I've just got this device and using the official image (vanilla, no sqm, no nothing) I was getting a lot of connection issues in the WAN, it would drop for about 2-15 secs every 2-5 minutes.
I've installed this build (stable 19.07) and the issue is gone, not sure what caused it though
Thanks!
1 Like
master-r13951-6c57fb7aa9-20200726
I built a new master build, but it crashed pretty soon (in 15 minutes or so).
Not yet sure if that was an one-time mishap, or if something has got buggy in the last few weeks.
(Note that the uptime of the previous build master-r13881-bae4204e34-20200718 was 8 days, so that build is hopefully stable...)
1 Like
r13938-15f585afc5 (with ldir's kernel bump from the mailing list) has been running fine on my nbg6817 for the last ~12 hours.
i'm running r13929-98b60b3efa on a dumb ap for the last 1.5 days without issues.
r13951-6c57fb7aa9-20200726 up for 10 hours now, no issues as far as I can tell. Before that I was on r13768-f632747704-20200709 for 14 days.
For what it's worth I've been running r13951-6c57fb7aa9 for 1d 2h 24m 42s so far without any issue.
The only entries in kernel log since finishing the boot are:
[ 3014.040548] ath10k_pci 0001:01:00.0: htt tx: fixing invalid VHT TX rate code 0xff
[68074.426634] ath10k_pci 0001:01:00.0: Invalid VHT mcs 15 peer stats
though no functionality seems to be affected.
master-r13978-d15b6e4895-20200730 with firmware-5.bin_10.4-3.10-00047 seems to run well for me. There's a new version of mac80211 that appears to have fixed a bunch of messages in dmesg/logread.
Spoke too soon. mac80211 crashed, same trace as reported before. Didn't take the device down, it recovered from it.
[60521.528498] ------------[ cut here ]------------
[60521.528604] WARNING: CPU: 0 PID: 767 at backports-5.8-rc2-1/net/mac80211/sta_info.c:1929 ieee80211_sta_update_pending_airtime+0x1f8/0x1fc [mac80211]
[60521.532185] STA xxxx AC 2 txq pending airtime underflow: 4294967248, 48
...