Well, basically the whole ath11k FW crapped out and crashed
Hi All,
Anyone know how to flash back to Dynalink original FW?
1 Like
Hi @luaraneda ,
can you share how to decrypt and uncompress the config ?
I have modified my original post to include this and make it more explicit.
Credits to @lmore377 for finding how to decrypt and encrypt the config on link (from this thread)
Anyway, here it is again.
To decrypt (assumes downloaded config is called "backup.cfg"):
# openssl enc -d -aes-256-cbc -a -in backup.cfg -out backup.tar.gz -pass pass:AskeyRT5000wKey1357924680
To compress configuration and encrypt it (assumes source directory is called "backup"):
# tar czf backup-enable_ssh.tar.gz -C backup etc lib
# openssl enc -e -aes-256-cbc -a -in backup-enable_ssh.tar.gz -out backup-enable_ssh.cfg -pass pass:AskeyRT5000wKey1357924680
1 Like
Thank you for porting some of the ath11k fixes. I did test the latest build (OpenWrt SNAPSHOT, r0-a56980f) bun unfortunately it continues having the same issue with ath11 crashing.
i tried to reproduce it with two ssid on radio1 one with WPA and it is not crashing maybe because i don't have a similar device as yours... are you able to share the wifi config ? one thought could be to setup the ssid that the ecobee is connecting to in legacy mode
When trying to reproduce the issue yesterday, it appears that I had to try to access two separate SSIDs from this one device (ecobee). Both are WPA2 but one is Auto and the other Force AES for cipher. (I incorrectly said it was WPA2 that prevents device from connecting but it seems to be cipher setting.
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/c000000.wifi'
option band '5g'
option htmode 'HE160'
option country 'US'
option cell_density '1'
option distance '66'
option channel '100'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/c000000.wifi+1'
option channel '1'
option band '2g'
option htmode 'HE20'
option cell_density '0'
config wifi-iface 'wifinet4'
option device 'radio1'
option mode 'ap'
option ssid 'wifi1'
option encryption 'psk2'
option key '***'
option network 'lan'
config wifi-iface 'wifinet5'
option device 'radio1'
option mode 'ap'
option ssid 'wifi2'
option network 'lan'
option encryption 'psk2+ccmp'
option key '***'
would you mind to add to radio1 the country? i always use psk2+ccmp... i doubt this is the problem
it crashes when "disassociated due to inactivity" ... is the mac 01:01:01:01:01 the ecobee? as a workaround set the interface like this
or you could increase the "station inactivity limit" .... i am curious to see if it still crashes
Sorry, I changed MACs of all devices to 01...
I think disassociated due to inactivity is a side-effect of the issue, as crash only happens on authentication. AES-CCMP is more secure therefore I choose it when I can. It might be that most people have it on psk-ccmp and hence the crash is not widely reported.
1 Like
@robimarko, I see the commit on your repo adding support for single-partition only.
The script from @clayface has some interesting logic that can be used for multiple-partitions (and some bootcount for recovery).
What would be the best approach for official OpenWrt support?
Having a way to TFTP load an initramfs image as a recovery method without seral access would be great for users.
But there might be some trade-off like flash wearing.
bootcount logic from @clayface does a saveenv on each count.
And it seems implementing multiple-partitions would required saving the active one to u-boot env as well (on each sysupgrade).
I can run some tests on my device to make sure it's working fine.
On the same lines, do you know if we can detect at runtime what is the active slot being used?
OpenWrt probably has something for devices that support it, and I can try on OEM firmware as well.
U-boot writing bootcount or active partition is the least of worries for flash wear.
I dont have anything against using the traditional dual FW with update one, keep the previous as backup, but I dont have to implement anything like that myself.
I think I got an idea why attempting to automatically load (using bootcmd) an image from TFTP is not working compared to manually calling the commands by serial connection.
It seems the network is only initialized when autoboot is stopped and the U-Boot shell is shown.
Does anyone knows how to initialize the net (or anything that would make it work) without getting into the U-boot shell?
Any ideas are appreciated.
I used the following command to test (the same happens with tftpboot, and adding a sleep before doesn't help):
# setenv bootcmd "echo ping start; ping 192.168.1.10; echo ping end;"
And here is the output from serial connection:
Hit any key to stop autoboot: 0
ping start
No ethernet found.
ping failed; host 192.168.1.10 is not alive
ping end
Net: MAC0 addr:2c:ea:dc:xx:xx:xx
PHY ID1: 0x4d
PHY ID2: 0xd0b1
PHY ID1: 0x4d
PHY ID2: 0xd101
EDMA ver 1 hw init
Num rings - TxDesc:1 (0-0) TxCmpl:1 (7-7)
RxDesc:1 (15-15) RxFill:1 (7-7)
ipq807x_edma_alloc_rings: successfull
ipq807x_edma_setup_ring_resources: successfull
ipq807x_edma_configure_rings: successfull
ipq807x_edma_hw_init: successfull
eth0
(interactive shell reached)
IPQ807x# ping 192.168.1.10
ipq807x_eth_halt: done
eth0 PHY0 Down Speed :10 Half duplex
eth0 PHY1 up Speed :1000 Full duplex
eth0 PHY2 Down Speed :10 Half duplex
eth0 PHY3 Down Speed :10 Half duplex
eth0 PHY4 Down Speed :10 Half duplex
eth0 PHY5 Down Speed :10 Half duplex
ipq807x_eth_init: done
Using eth0 device
ipq807x_eth_halt: done
host 192.168.1.10 is alive
It seems to ipq7x functions are doing something.
U-boot will init networking as soon as you interrupt autoboot and drop into shell, but you have to give it like 20-30 seconds
That's the thing, I don't what to interrupt autoboot and get to the U-boot shell.
I'm trying to avoid the need for serial access.
Since I was not able to initialize the network with a command, I'm now exploring loading the initramfs image from USB.
And how do you plan to instruct the U-boot to load the initramfs image then?
So far this seems to be working, but it needs to be refined and further tested by setting the variables from OEM firmware:
setenv initramfsboot 'setenv mtdids nand0=nand0 && setenv mtdparts mtdparts=nand0:0x6100000@0x1000000(fs) && setenv bootargs console=ttyMSM0,115200n8 && bootm'
setenv bootcmd "usb start; if fatload usb 0:1 0x44000000 openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb ; run initramfsboot; else bootipq; fi;"
It has a fallback to OEM firmware if USB can't be loaded.
If you have root access to the stock FW, why not simply flash OpenWrt from there?
That could be yet another option that I plan to look at, but first I wanted to have an initramfs to try a few things.
For flashing from OEM firmware I think I need to identify the current slot and flash it to the other one, then enable the other slot so it's the current one.
That requires more logic and knowledge of OEM firmware so I went to initramfs for now.
@robimarko, I need your advice on a few things that could improve the current support for this device.
I've done a lot of testing with both OEM firmware and OpenWrt regarding flash.
I think I have several ways to flash OpenWrt without requiring a serial connection.
I can even automate a few operations on OEM firmware by using uci-default scripts on a custom config file.
There are several features we can add to the device, like dual-partition, bootcount, and recovery (USB), but I don't know whether they would be accepted for official inclusion.
The first query is related to recommended flash method for UBI.
@clayface script has a recovery method of flashing factory image from U-boot using "nand erase" and "nand write".
I'm reading that we might lose UBI metadata (erase counters) if we do that.
Flashing from U-boot can simplify the process (can be scripted with env vars), but it could be a risk as well.
There seems to be "nand write.trimffs", but I don't know whether it would improve the situation.
Is it Ok if we flash from U-boot from time to time (install, recover) or should it be avoided and use ubiformat instead?
The second query is related to supporting dual-slot partition for rootfs.
The current code on your repo is only adding support to single-slot partition, but the device has 2 OEM partition slots.
They are controlled by the "bootconfig" mtd partitions on OEM firmware (I think there is even a kernel module).
I'm leaving a table at the end of this post that summarizes the behavior I observed during tests.
I think we can't reliable control the OEM feature from OpenWrt, but we can come up with a way to implement a dual-slot setup using sysupgrade and U-boot.
What do you think about having dual-slot partition support by default?
To do so we would need to modify a few things.
For example, your commit message only references the current slot on mtdparts:
if rootfs is: 0x1000000 0x6100000
setenv mtdparts mtdparts=nand0:0x6100000@0x1000000(fs)
For dual-slot setup, following what OEM is doing, it should be something like this:
if rootfs is: 0x1000000 0x6100000
setenv mtdparts 'mtdparts=nand0:0x6100000@0x1000000(fs),0x6100000@0x7a00000(fs_1)'
That would allow us to load the kernel from "fs" or "fs_1" using "ubi part".
A dual-slot system can be running from "rootfs" or "rootfs_1".
However, when doing sysupgrade current code uses "rootfs", which could result on the wrong slot being flashed.
Here is a simple (tested) snippet that identifies the mtd name of current slot (assumes it's on ubi0):
# File: /lib/upgrade/platform.sh: for board "dynalink,dl-wrx36"
# Get mtd name of current ubi device
ubi0_mtd_num="$(cat /sys/class/ubi/ubi0/mtd_num 2>/dev/null)"
ubi0_mtd_name="$(cat /sys/class/mtd/mtd${ubi0_mtd_num}/name 2>/dev/null)"
if [ "$ubi0_mtd_name" ]; then
CI_UBIPART="$ubi0_mtd_name"
else
echo "cannot find mtd name for ubi0. Using default"
fi
The snippet should be backwards compatible with current implementation of single-slot partition.
It can be enhanced to flash to the inactive slot, but that would require modifying U-boot vars as well and I wanted to get your opinion first.
Finally, as I was not able to trigger TFTP without getting into the U-boot shell, I have something that can work with USB (file on FAT partition).
It could be useful for a recovery method to load a factory or initramfs image.
Do you think it would be acceptable?
By the way, I was bot able to sample GPIOs or toggle LEDs from U-boot, so the options are reduced.
Here is a summary of the behavior I observed during tests related to OEM partition slots for rootfs:
-------------------------------------------------------------------------------------
O.S. | Var. / partition | OEM partition slot 1 | OEM partition slot 2 |
-------|----------------------------------------------------------------------------|
U-boot | smeminfo part 18 | Name=rootfs | Name=rootfs |
| | Start=0x1000000 | Start=0x7a00000 |
|--------------------|---------------------------|---------------------------|
| smeminfo part 20 | Name=rootfs_1 | Name=rootfs_1 |
| | Start=0x7a00000 | Start=0x1000000 |
|--------------------|---------------------------|---------------------------|
| mtdparts | 0x6100000@0x1000000(fs) | 0x6100000@0x7a00000(fs) |
| (env var) | 0x6100000@0x7a00000(fs_1) | 0x6100000@0x1000000(fs_1) |
|--------------------|---------------------------|---------------------------|
| ubi mtd partition | fs | fs |
| (for kernel load) | | |
|--------------------|---------------------------|---------------------------|
| bootargs | ubi.mtd=rootfs | ubi.mtd=rootfs |
| (env var) | root=mtd:ubi_rootfs | root=mtd:ubi_rootfs |
-------|--------------------|---------------------------|---------------------------|
Linux | mtd18 | name=rootfs | name=rootfs_1 |
| | start=0x000001000000 | start=0x000001000000 |
|--------------------|---------------------------|---------------------------|
| mtd20 | name=rootfs_1 | name=rootfs |
| | start=0x000007a00000 | start=0x000007a00000 |
|--------------------|---------------------------|---------------------------|
| ubi0 | mtd18 | mtd20 |
|--------------------|---------------------------|---------------------------|
| ubi0:1 | name=ubi_rootfs | name=ubi_rootfs |
| | (mtd26, mtdblock26) | (mtd26, mtdblock26) |
| | (ubi0_1) | (ubi0_1) |
|--------------------|---------------------------|---------------------------|
| ubi0:2 | name=rootfs_data | name=rootfs_data |
| | (mtd27) | (mtd27) |
| | (ubi0_2) | (ubi0_2) |
|--------------------|---------------------------|---------------------------|
| root | mtdblock26 | mtdblock26 |
-------------------------------------------------------------------------------------
2 Likes
As far as I remember, they are using bootconfig for switching the active slot so that bootipq/bootqca in U-boot know whats active and its switched via SCM call which I suppose we can implement as well.
It will also dynamically update the partition table.
Who cares about UBI erase counts if you are recovering.
I honestly think you are overthinking this, since there is root access we can just flash from the stock FW, but I guess its gonna need some figuring out how to switch the slot.
Ok, just checked out their upgrade script from stock FW and they are getting a new binary for BOOTCONFIG and BOOTCONFIG1 and flashing that which I am now interested in whats generating it.
Ok, so QCA have a bootconfig kernel driver for generating this
1 Like