I've been running the 19.07.3 release on a ZyXEL NBG6817 for more than two weeks now. I upgraded from the 18.06 branch because the WiFi had started to hang the device approximately once a week (earlier 18.06 releases could work for months without any issues). The 18.06 firmware image used the "classic" ath10k drivers. I built a 19.07.3 image based off a configuration file from 18.06 with the same ath10k firmware. The resulting image hung after a few days just like the 18.06 one did. So I reverted to a default configuration, only adding my custom packages and replacing some packages with the *-full equivalents. Now the resulting image reboots or hangs the router about every day or even more often. I noticed that the default configuration uses the ath10k-ct driver and firmware instead of the regular ath10k and that is the only difference. Is there a way to make the 19.07.3 operation as stable as the early 18.06 releases used to be? I don't want to roll back that far.
Updated Archer A7 v5 with "opinionated customization", works as expected:
opkg update && \
opkg remove wpad-basic ath10k-firmware-qca988x-ct && \
opkg install wpad-openssl ath10k-firmware-qca988x-ct-htt
These changes enable DFS 5GHz channels and stable 80Ghz wide wifi throughput of about 400Mbit/sec (via iperf3). DFS channels did not work using wpad-basic.
I've updated my BT Home Hub 5a with OpenWrt 19.07.3 r11063-85e04e9f46. I use it as switch, with no DSL cable on.
Every 20 minutes, it reboots. I had this issue with the older 18.x release, also, but I disabled dsl_control and it worked fine. I've done the same on this 19.07.3 release, but it keeps rebooting after a while.
I have a BT Home Hub 5a as well.
I had the same problem with 19.07.3 and I returned to OpenWrt 18.06.4 which had no issues with dsl_control disabled.
I disabled dsl_control and it didn't solved the reboot issue.
Then I used the ssh method to disable it, writing these two lines in ssh console:
/etc/init.d/dsl_control stop
/etc/init.d/dsl_control disable
and it didn't reboot anymore. This with 19.07.3 release.
Hi,
Thank you for taking the time to respond and for your assistance.
I used exactly the same method via SSH with 19.07.03 and it did not fix the problem as I had to do the same with version 18.06.04. With version 18.06.04 and dsl_control stopped and disabled, I have not had a drop for 29 days since I downgraded. Also, more free memory is available for version 18.06.4 versus 19.07.03 and the Luci browser response for 18.06.04 is way faster than 19.07.03.
Note well: for both versions, I am not running additional packages.
I will stick with version 18.06.04.
Probably, my issues were caused by overheating. Although the router itself is physically placed on a cabinet and nothing is obscuring the ventilation grill in the body, it still felt rather hot at the touch. So I unplugged an external hard drive from the USB port, stopped some related services to lower CPU usage a bit (it had been far from 100% anyway), placed a couple of CD cases under the lags to ease ventilation, and since then the router has been running fine for 3.5 days now. I also have reverted the WiFi country code settings to default US but am not sure if this has had any effect. So my theory is that the older 18.06 releases put lower load on the system causing less heating. Then, at some point after I did a minor patch-release upgrade, some firmware components (probably the WiFI firmware, because it was the only component that changed significantly in the 18.06 branch) began to put higher load on the electronics which caused overheating and was distinctly visible as periodic hang ups.
I found that running firmware version 18.06.04 on a BT Home Hub 5a led to a temperature drop of a 14°C when compared to firmware version 19.07.03. This was monitored over a number of days. For the two firmware versions, I used Flash new firmware image and I did not keep the settings.
Interesting, this is rather unexpected.
Please open a bug report with details and comparison in similar usage: load average, which processes use CPU in top, temperature. If possible test and compare several OpenWrt versions (18.06.X, 19.07.X, latest master) and variation of wireless driver and firmware (regular ath10k versus ath10k-ct versus no wireless at all)
It is likely related to ath10k. However, it could also be a general problem affecting all devices (caused by newer kernel or userspace process issue), althought that would be really surprising.
@briskycat your input is also welcome
Hi
my TP-LINK Archer C7 V5 (Firmware 1.0.11) does not accept the 19.0.3 factory.bin for a first install. Support for TP-LINK Archer C7 v5 (RU) says that the previous 19.0.2 works through the factory web gui, which i can confirm.
I suggest that you decrease the v5 factory.bin-link from 19.0.3 back to 19.0.2 at your website https://openwrt.org/toh/tp-link/archer-c7-1750 until its solved.
Did anybody have a successful UPGRADE to 19.0.3 on an Archer C7 V5, compared to an unsuccessful factory.bin fresh install?
Regards
I upgraded with the result LUKS doesnt work on my x86 device Problems opening LUKS-devices on APU (x86) running latest version of OpenWRT
Anyone else has the same problem ?
I measured two different R7800 with very similar configuration. 18.06.8 / 19.07.3 both idleling and with non ct wireless driver, both about 10.6W
DFS channels are not working with 19.07.3 and the DLINK DIR-860L B1 (MT7621).
Wireless is not associated + the following syslog message:
daemon.notice netifd: radio0 (7271): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process 6949 path ()
daemon.notice netifd: radio0 (7271): Device setup failed: HOSTAPD_START_FAILED
Actually only channel 36 is working which seems to be a bit odd. I've flashed the factory.bin of 19.07.3 via recovery and set up everything from the scratch, so there is no old config involved.
I guess it must be a driver related problem?
I am a new user currently on 19.07.02 which I installed in May. If I do a sysupgrade will I need to reinstall all of my packages again (Nord VPN, QOS, printer, attached storage and bandwidth monitor)? Also does it keep configuration files?
Thanks,
Chris.
Yes.
Typically yes, but it depends on where they are stored. If these live in /etc/config you are good to go, otherwise you might need to add them manually to /etc/sysupgrade.conf
Upgraded Netgear R8000 from 18.06.4 to 19.07.3 and 5GHz wifi is crashing every other day or so. Country code is US. Radio 2 is on channel 48. Radio 0 is on channel 149. Did an upgrade first, then also tried a clean/fresh install. Nothing else installed.
Unfortunately I can't physically access the router as it's installed at a family member's house over an hour away. I don't have access to logs, etc. Note that everything worked in 18.06.4.
After using the LuCI gui to run the upgrade to 19.07.3, will I then have to ssh into the router and reset the password? I have problems with re-entering the wifi passwords, too. I'm too much not computer literate to understand wep, wpa, wpa2-psk, and I've tried to learn my way around this, to not much success.
Gentleman (and undoubtedly some ladies), for an utter amateur as myself, I would dearly prefer to not be inside my router's workings at all. If I could but run the upgrade and run a backup to save the configuration, it would be so much less scary.
@MarkP2015 - If you keep settings during the update, you will not need to login to set passwords and such. However, keeping settings is only considered safe if you are performing a maintenance upgrade (i.e. 19.07.2 > 19.07.3). It is not recommended if you are upgrading across a major release such as from 18.06.x > 19.07.x. This recommendation is not to say that it won't work, but rather that it is plausible that there will be some changes under the hood that could result in the configuration incompatibilities -- this is especially true if you're making a large jump (say OpenWrt 15.05.x > 19.07.x, or if your router is Atheros 71xx based and has been migrated from the ar71xx to the ath79 target platform).
My guess is that you have a relatively simple configuration since it sounds like you aren't utilizing OpenWrt's advanced features and tinkering with stuff all the time. So even if you do need to log in to update things, you can probably do everything you need with the LuCI web interface in just a few minutes. The community here can also help you with this process by pointing you to the relevant documentation/tutorial pages (the quick start guide is really useful) or just describing the steps involved. For this, you may want to open a new thread.
What router are you using and what is the current version of OpenWrt?
Thank you, first of all. In response to your 2 questions.
From the login screen:
LuCI openwrt-19.07 branch (git-20.057.55219-13dd17f) / OpenWrt 19.07.2 r10947-65030d81f3
and this is the maintenance upgrade from 19.07.2 to 19.07.3 for a TP-Link Archer C7 version 2.0.
I have the downloaded filename as:
openwrt-19.07.3-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade
However, reading about checksums at: https://openwrt.org/docs/guide-quick-start/verify_firmware_checksum:
"3. Check that the checksum string matches as the one you can find in the sha256sums field on the download page you retrieved by following the instructions above." Unfortunately, when I downloaded the above .bin, I was not take to a page with checksums. All that happened was a smaller window opened asking whether to Save the file.
As long as you are currently using an ath79 target, you can keep settings, no issues.