About irqbalance that is somewhere in this thread bottom line if I remember correctly do not use it but there where some manual tweaks described.
I did some throughput testing and it maxes out my 1 GB lan (LAN<>WAN wired iperf3) without any off-loading or tweaks
WireGuard throughput 800 Mb/s but the router was doing nothing else.
Wifi about 10-15% higher throughput than my R7800 (AX vs AC) but off course only 5 GHz and not too far away from the router.
But just some quick tests so just to give an indication
I settled on 650 Mbit download for SQM with software offloading, packet steering, and the above script from @hnyman. Above that and I would start to see worse scores from tests. My ISP download is 800Mbit with some overprovisioning to 900+.
My latest build of OpenWrt SNAPSHOT r23727-e6f8b69918 has now been stable for 5 days with WLAN.HK.2.9.0.1-01862-QCAHKSWPL_SILICONZ-1 , and no problems with wifi.
I have a feeling that part of the crashes were due to the bugs in the new hostapd control interface implementation with ucode by nbd, which was merged (on Aug 1st) roughly at the same time as the ath11k firmware bump to 2.9.0.1. The hostapd code has got several fixes since then, mainly last week: https://git.openwrt.org/?p=openwrt/openwrt.git;a=history;f=package/network/services/hostapd;hb=HEAD
2.9.0.1 may have got a rough start partially due to external reasons...
I'm using it as a "dumb access point" with all IP delegation (4 and 6) handled by other hardware in the building with two VLANs as well. Works fine. It isn't the most-stable when the signal gets a bit weak in terms of holding on but performance-wise it does a great job for a cheap price.
My latest build of OpenWrt SNAPSHOT r23727-e6f8b69918 has now been stable for 5 days with WLAN.HK.2.9.0.1-01862-QCAHKSWPL_SILICONZ-1 , and no problems with wifi.
In my experience the stability goes out of the window once you start seeing "ath11k c000000.wifi: failed to flush transmit queue, data pkts pending" messages in kernel log. Granted, these now are rarer compared to previous snapshot build.
My observation is that everything is fine if you don't have these error messages. Once the error message happens, the two critical issues that I'm tracking can be reproduced. Those are:
How to get the flush transmit queue error messages? They can happen on their own, maybe one message in a day now, or you can run "wifi" command from shell a bunch of times.
I am running yesterday's snapshot r23763-46ed38adeb but for reasons above I downgraded IPQ8074 firmware to WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1.
Flush transmit queue messages still happen. They are very very rare, I imagine thanks to hostapd fixes, but at least with 2.7 firmware they don't impact the stability.
i run it and reboot. hoping to see the LAN ip changing to 192.168.1.1 but to no avail. as far as i can tell with fw_printenv it did work and set itself into the environment but it have no effect at all. is this something u-boot related? i dont even know how to go about troubleshooting it.
That command means that it will try to boot from the USB stick that you have attached.
Is that your intention?
(Do you have the correctly named firmware image on the attached USB stick?)
You say that "you have unbricked it". What is the status?
Are you now running the OEM firmware?
Are you able to enter the OEM ssh console?
If yes, and you tried that fw_setenv command, does "fw_printenv" show the changed variable ?
yes it is currently running OEM firmware with the ssh enabling config (askey1234 password)
i can ssh into it and fw_printenv does show changes have been made using the fw_setenv. however after reboot it still boot with the same LAN ip 192.168.216.1 rather than 192.168.1.1.
the *.itb on the drive is the exact same name as the command in the wiki, and the usb is formatted FAT32.
trying to run "usb", "fatload", "bootm" return -ash: X not found causing me to wonder if my unit somehow boot differently
okay i decided to throw most of what i did to the bin and try again from a linux machine (no clue why that would make a difference but WE). everything worked well and im up and running. now time to run apps on this sucker!!
I’ve used your proof of concept for the dual boot (pretty much as is).
Edit: Removed the direct link to the commit, and added a link to the branch instead. I might force push commits, or add new commits, as it is WIP.
From the original I’ve added an attempt to usb boot initramfs at every boot first.
and changed the owrt_active from 0 (usb boot recovery) to 1 (first partition).
Edit: From the original I've removed the bootcount recovery logic, this is a WIP.
Edit 2: The original Luci-app-advanced patches needed some TLC after some code changes upstream. The latest (working ATM):
There are also 2 patches for luci-advanced-reboot to use the new functionality.
https://github.com/jaharon/luci/commit/632b4ed124d59959b34408adf15994d2bd6a752b
https://github.com/jaharon/luci/commit/118b5d7cd8f41e45638f247d79894bc737d87a7c
This work on my dl-wrx36, once both partitions have been sysupgraded with an image that includes the above patches.
I’m not sure about the long term consequences of writing to the bootenv every sysupgrade/partition change, but I’ve decided to try this, as I like the functionality of dual boot, and the same worked fine with an ea8500 for a few years now.
Still need to enable multicast-to-unicast in the latest main branch build for wifi to not crash constantly. Fwiw I only use ipv4, ipv6 disabled, and barebone build (luci, sqm) nothing special.
Assuming you used a serial connection to fix things, could you tell me what kind of cable you used? I am running into problems with the ones I have been trying (USB to serial). There's not enough room to fit the connectors onto the pins.
Thanks!
You need a 4-pin 2.0mm JST PH connector (which is mentioned many times in this thread, and also in the wiki page for the device).
At a pinch you can take the plastic off alternate Dupont female connectors such that pin 1 has a surround, 2 doesn't, and so on. You may need electrical tape to insulate them though.