Finally I can flash my router! Which image should I use to flash it first? (Assuming I want to use the test image with DSA support.)
There are also some patch files in the folder, so I'm quite confused as to which file should I use.
If you use the TFTP flashing method, you need only the "factory" image file.
Like wiki says:
A new firmware to flash in. Either an original Netgear firmware or an Openwrt “factory.img” firmware. “Sysupgrade” version will not work.
You do not need the other files like patches.
If you need to save your configuration make sure to make a backup before using tftp and the factory image.
When I tried to flash stock firmware, it was able to boot normally, but when I tried to flash it with master image (either normal one or test DSA one) I got stuck in boot loop. Is there anything that must be done before flashing master image? (21.02 image is working fine)
Anyway, thank you so much for the help. At the very least my router is functional once again. Thank you!
My experience is that you can ping it but if you have a non default ip/netmask/defaultgw setup you will have to configure a static IP, NM and GW.
If I'm not mistaken the default openwrt setup is 192.168.1.1/255.255.255.0.
I have the same issue with DSA build in my R7800. I currently do not have Serial cable to get boot logs to debug the issue. We are discussing this in [PR] ipq806x: kernel 5.10 bump code propose. If you are able to obtain boot logs while and after flashing the DSA build, that would be helpful for the developer @Ansuel.
I flashed back to 21.02-SNAPSHOT using TFTP recovery method in my R7800, which is working. I am also not a developer to be able to propose any changes to fix this issue myself.
Without a serial output we can't really find the cause of the bootloop...
My bet would be on too low voltage, but we need a bootlog to confirm this.
Test-DSA-kernel510-master-r16249-9ac47ee469-20210318
Jow merged the VLAN config with DSA support into LuCI master (see discussion/advice in https://github.com/openwrt/luci/pull/4307), so I made a new test build with 5.10 DSA.
OpenWrt SNAPSHOT r16249-9ac47ee469 / LuCI Master git-21.077.59320-d1bf56d
Kernel Version 5.10.23
Kernel bootlog and system log at https://gist.github.com/hnyman/61bd118587871201f759fc1adece9893
1 Like
While your build indeed works fine looks like regular development snapshot builds do not yet get such a version of LuCI as of yet:
OpenWrt SNAPSHOT r16249-9ac47ee469 / LuCI Master git-21.060.51374-cd06e70
I now have a Macbook in the house which randomly resets to really low wireless speeds even when put right next to the router, and even after router is rebooted.
All other devices, even cellphones, get much better speeds than <10mbps garbage the Macbook randomly shifts down to.
REALLY wish there was a version of this firmware pre-baked with regular ath10k driver which must be more stable than this experimental ath10k-ct garbage.
Let me organize facts...
Apple use mainly broadcom chip...
Broadcom is very known for using non standard protocol and applying standard bad.
Apple is also known for using not the standard way of implement things
Ath10k-ct is garbage because it doesn't work on Apple product but works on any other device.
Also ath10k-ct doesn't work well with shitty iot Chinese device.
It's obviously ath10k-ct fault OR NOT?
ath10k-ct is working fine here with R7800 on OpenWrt SNAPSHOT r15964-4b92663f7a. I have two iMacs (2013 and 2017), a MacBook Air (2020), 3 iPhones and a Mac Book Pro (2011). All devices work flawlessly with community drivers.
1 Like
Since I can't get your exact snapshot, I upgraded from 19.07 stable to 21.02 stable (owrt2102-r15915-31bca5f256-20210319), hoping that it's been fixed in one of those hostapd/WMM commits. Though that commit is probably already in 19.07 stable, and in various threads just updating the version but staying with -ct doesn't seem to fix it. Anyway, hoping for the best with this version, thanks.
What you're using here is programmer logic, which I understand as a programmer. As a community project, OpenWRT doesn't have customer-facing side, of course. All the customers are basically programmers themselves.
However, if OpenWRT project did have customer relations, they would force the programming department to bundle, by default, the WiFi code which works with the MOST devices - regardless of how "programmatically wrong" and "non-standard compliant" those devices are.
There are normal people among us who just want a stable router, not an endless beta-testing adventure or a medal for participating in a "standards war".
1 Like
I think we are another time OT anyway...
Problem is that not standard thing are not documented and very hard to discover... most of the time results in performance problem or bug and nobody actually try to find the cause and just change the firmware.
In this specific case for example qcom know more not standard thing oem does than ct.
About the beta-testing adventure... honestly times where new changes caused very bad regression are far gone. Most of the time new version are just improvement and when a regression occurs, it's fixed within some days (or hours).
So really... all the problems about using stable version instead of endless-beta it's really laziness from people that wants to put a firmware on a device and keep it for years...
Anyway this is not random flame. What I really want to say is that there are standard accepted by everyone and people complains when a driver doesn't work when his device doesn't actually follow that. So pls don't call a driver garbage just because it doesn't support any existing device on earth, just report that it's not compatible for some unknown reason.
1 Like
Your logic is completely flawed to say at least and it can easily be reversed. You are operating some crapy devices which don't follow completely any main electronic standard on this planet. They like to play their own game and throw smack at every other devices they connect with. Just do yourself a favour and throw them away, too. Or do OpenWRT users and mainly to the dedicated OpenWRT developers a huge one and don't disregard their free time efforts to put together a tremendous community build for our routers many abandoned by the manufacturer. You are also free not to engage with and build your own firmware, drivers, etc for your crapy forbiden bite devices.
1 Like
Unlike some of the posters here, I fully understand your position (I have two iPhones, an iPad and an iWatch in the house).
The ath10k-ct driver/firmware issue is what almost pushed me away from OpenWRT to some other firmware on my R7800.
In the end, I pushed through, seeing as the -ct isn't getting fixed, so I did what hnyman outlined in the OP and replaced the drivers after flashing. All iOS devices work flawlessly without the irritant lag that accompanies the -ct variant.
Yes, it's a bit annoying, yes it takes a bit of effort (for us non-programmers types), but in the end, it's, IMHO, worth it. ¯_(ツ)_/¯
In closing, I would advise against the mantra of some the posters here that simply brush off the "-ct iOS issue". iOS devices are a huge part of many households, and this issue is still unresolved within the wider OpenWRT community so some understanding for the frustration of the iOS here should be welcoming.
4 Likes
Thank you. The problem is that there are no exact step-by-step instructions on installing the reliable driver in the original post. I know there are bits and pieces of it spread around this giant thread, but that takes a lot of effort.
EDIT: I think I did it, except for the vague blobs mentioned by hnyman that may also need to be installed after the IPK...
EDIT2: Ok I figured out the complete list of actions to install the reliable wireless driver:
Transfer the IPK file to /tmp/ folder using WinSCP with SCP protocol selected.
Login via SmarTTY to the router and run these commands:
opkg remove kmod-ath10k-ct
opkg install /tmp/ath10k-mainline*.ipk
=========
Go to Luci interface and:
- Click "Update lists" in "Software"
- Uninstall package "Alternative ath10k firmware for QCA9984 from Candela Technologies"
- Install package "ath10k qca9984 firmware"
Reboot router.
@Ansuel and @hnyman Test-DSA-kernel510-master-r16293-310b7f76e8-20210321 Boot Log
Power Adapter is
Netgear P/N 332-10762-01;
Model No. MU42-3120350-A1 (U.S.A. pin);
Input: AC 100-240V, 50/60Hz, 1.5A;
Output: DC 12V, 3.5A
I also got gibberish initially in Putty both in Windows 10 and Linux. I had to swap TX and RX pins to get proper output.