Reinstall stock firmware on qhora-322

[zaq]

Would like to know of a way to reinstall stock firmware for the qHora-322 router from QNAP. Currently I am running the latest stable openWRT release and just for trying it out I tried flashing the image straight from qnap using LuCI but I get a message saying the firmware is not compatible.

Is there a way to flash this using the UART?

[zaq]

OK, So I was able to get back to stock on my own.

The process to convert to OpenWRT was to sort of follow this guide

Support QNAP QHora-322 ? (aka. IEI PUZZLE M902)

I'm travelling for work and have very limited time, if someone could create and update the wiki with these instructions for QHora-322 you should be able to run full OpenWRT on it. to get OpenWRT booting with original uboot you need to do this: assuming you already have opened the box and have a UART serial connected, if not do it before anything else, also get a TFTP server running before anything else with a cable directly connected to port 2 stop at uboot environment by pressing ctrl + c or…

OpenWRT install

1. Connect UART (for some reason I had to connect my USB interface board Rx and Tx pins to the published Rx and Tx pins on the Qhora straight-through... should be crossed but whatever).
2. Statically set my PC to 192.168.1.111 and start a TFTP server with the initramfs (Kernel) image I got from the OpenWrt Firmware Selector
3. Enter U-boot. It helped me to save the output of env print for going back later.
4. Connect the ethernet cable to port 2 and set these env variables:

setenv ipaddr 192.168.1.11
setenv serverip 192.168.1.111
setenv ethact mvpp2-1

5. Test connectivity with a ping to the tftp server. This should be successful:

ping 192.168.1.111

6. Pull the intrarmafs image and boot to it using the qHora database:

tftpboot 0x6500000 openwrt-22.03.3-mvebu-cortexa72-iei_puzzle-m902-initramfs-kernel.bin
ext4load mmc 0:2 0x6000000 cn9132-db-A.dtb
booti 0x6500000 - 0x6000000

7. Copy the openWRT images to a usb drive. You need linux to prepare the images to be copied. Since intrarmafs has no internet access, this needs to be done offline and copied to a usb drive. This is where I diverged a bit from the guide. I don't know why they copied the snapshot image, that gave me dependency nightmares. I found it best to use the stable release of openWRT. This is how I did it, assuming I mounted the usb drive to /mnt/pendrive. Another note on that though, I had to format the pendrive ext4. Formatting it as fat32 caused complaints when trying to mount it on the qHora:

• In my raspberry pi:

wget https://downloads.openwrt.org/releases/22.03.3/targets/mvebu/cortexa72/openwrt-22.03.3-mvebu-cortexa72-iei_puzzle-m902-squashfs-sdcard.img.gz
gzip -d openwrt-22.03.3-mvebu-cortexa72-iei_puzzle-m902-squashfs-sdcard.img.gz
# the warning about extra data that was ignored is fine. This is the metadata used to install the image during sysupdate or LuCI
newloop=$(losetup -f)
sudo losetup -P $newloop  openwrt-22.03.3-mvebu-cortexa72-iei_puzzle-m902-squashfs-sdcard.img
# The complaint about the discard of the 512 bytes at the end was fine too. I ignored it and I was fine.
sudo dd if=${newloop}p1 of=/mnt/pendrive/0.img
sudo dd if=${newloop}p2 of=/mnt/pendrive/1.img
sudo losetup -d $newloop

• Back in the qHora322, insert the usb drive in the port and mount it:

8. Copy 0.img to partition 1 and 1.img to partition 3. Leave other partitions alone so you can go back if needed. Both results have to display same number of records in and out.

dd if=/mnt/pendrive/0.img of=/dev/mmcblk0p1
dd if=/mnt/pendrive/1.img of=/dev/mmcblk0p3

9. Reboot and go back to U-boot interrupting the startup sequence. Then set the new bootcmd, change the current_entry and save:

setenv bootcmd 'ext4load mmc 0:1 0x6500000 Image; ext4load mmc 0:1 0x6000000 cn9132-puzzle-m902.dtb; setenv bootargs $console cpuidle.off=1 root=/dev/mmcblk0p3; booti 0x6500000 - 0x6000000'
setenv current_entry 0
saveenv

10. Reboot once more and profit! you are in openWRT

Stock reinstall

Going back to stock is a bit of a reverse procedure of the above. It is useful if you stored the envs before installation. The important one is bootcmd.

This was helpful to decrypt the QNAP image. The passkey is indeed the first 9 characters of the filename:

Adding OpenWrt support for QNAP QHora-301W

The FW can be found here: The FW can be decrypted using this script: And the secret are the first 9 characters of the filename...

1. Back to the raspberry pi:

# Download the firmware from QNAP
wget https://download.qnap.com/Storage/Networking/QHora-322/FW/production/QHora-322_20230206-2.2.13.016.img
# Decrypt the file. It is a tar.gz
python3 qnap-qts-fw-cryptor.py d QHora-322 QHora-322_20230206-2.2.13.016.img QHora-322_20230206-2.2.13.016.img.tar.gz
# Extract the package
tar -xzvf QHora-322_20230206-2.2.13.016.img.tar.gz
# Copy Image and usr.squashfs to the usb drive
cp Image /mnt/pendrive/p1.img
cp usr.squashfs /mnt/pendrive/p3.img

2. Interrupt boot sequence to get back to U-boot. You need to boot up initramfs but while you're here, set the boot variables back to the original values:

setenv bootcmd 'ext4load mmc 0:1 0x6500000 Image; ext4load mmc 0:1 0x6000000 cn9132-db-A.dtb; setenv bootargs $console cpuidle.off=1; booti 0x6500000 - 0x6000000'
setenv current_entry 0
saveenv

3. Load back up initramfs

tftpboot 0x6500000 openwrt-22.03.3-mvebu-cortexa72-iei_puzzle-m902-initramfs-kernel.bin
ext4load mmc 0:2 0x6000000 cn9132-db-A.dtb
booti 0x6500000 - 0x6000000

4. Re-mount the usb drive in the qHora and overwrite partition 1 and partition 3 with the QNAP firmware:

dd if=/mnt/pendrive/p1.img of=/dev/mmcblk0p1
dd if=/mnt/pendrive/p3.img of=/dev/mmcblk0p3

5. Reboot and profit! you are back on the stock FW. I would do a full firmware upgrade using the stock GUI just to make sure everything gets re-created as expected.

[Av3ng3r01]

@zaq Quick question. Did you have the opportunity to test throughput on the 2.5 Gbps and the 10 Gbps with OpenWRT ?

Also, Did you know if the interfaces can negotiate 2.5, 5 and 10 Gbps?

thank for the info you have posted.

[zaq]

Hi @Av3ng3r01 . I only tested throughput using my WAN connection for the 2.5Gbps connection. That was completely fine, around 2.1 Gbps both ways. Did not get to test performance of the 10Gbps negotiation though.

The router itself negotiates 2.5, 5 and 10 when using the QNAP firmware but it does not negotiate 5G when using openWRT out of the box. I had to trick it advertising the 5000baseT option with ethtool and only then did it negotiate the link at 5G (my modem has a 5G port even if I only have 2.5Gbps service). The 5000baseT option is just not recognized as supported by the hardware when looking at ethtool eth6 (which was my WAN interface).

2.5G and 10G both negotiated fine with openWRT.

Also a weird thing I found is that the ports are all messed up in the ordering. I had to put a script in init.d so at startup all interfaces got reassigned to a temp name and then they got properly set to eth0-eth8 sanely using the MAC addresses of the ports.

[Av3ng3r01]

@zaq Super - great information. I am really interested in the QHora-322 because the multi-gig ports however the biggest disappointment is the QoS. I have been told by QNAP that QoS is not supported unless is part of a private SD-WAN organization. QoS is a must for me. I looked at the Netgate 6100 but the HW seems old (Intel Atom C3558) for the price and if I want to run pfsense on a muti-gig appliance then becomes expensive for the budget I have in mind. I really like pfsense. Maybe I have to wait longer to see the multi-gig port on a newer HW.

The QHora-322 looks very good if can run OpenWRT with the QoS enabled. if you do not mind I will ask you more questions once I have the Qhora to re-arrange the ports and trick at least one of the ports to run at 5gbps, that's the max speed on the current provider I have.

Thank you again!

[daniel]

@zaq

Stock reinstall

Can you share the partition layout of the stock firmware? It seem to be 7 partitions, I figured the partition labels based on the expectations of the stock firmware, but I don't know the sizes...
If anyone who didn't mess it up could dump it using gdisk -l or the like that would be helpful.