New version of Cudy WR1300 (V2.0)

Hi,

I am sending this simply to inform you that there is a V2.0 of the Cudy WR1300 router. This new version is externally identical to the previous one only that no longer brings the USB 3.0 port.

In this new version it is impossible (as of today) to install OpenWRT. The method described here for V1.0 does not work. It indicates that the firmware is not compatible and won't let you upgrade.

I have sent an email to Cudy technical support to see if they say anything about this issue or if they simply have a new image that supports this version. I will let you know if they answer or not (so far I have only had silence and I sent the email to support yesterday).

However, I think it would be interesting to put a notice about this on the router page. Indicating that for now V2.0 is not supported.

If you want me to do some test or send a picture, let me know.

Greetings.

1 Like

Just now I received a reply from Cudy support. Version 2.0 is not compatible with OpenWRT. Here is the answer they gave me:

Dear Customer,
Sorry to tell you the WR1300 V2 don't support the OpenWRT.
Best regards,
Cudy Team

Keep this in mind, because the version that is being sold now on Amazon is the 2.0 version.

hi,

i had a related problem few days ago with A-version. Installing OpenWrt fails on Cudy WR1300 - #33 by rmax

Cudy support sent me a binary which worked on my router openwrt 19.07. If you would like to try this version on your router send me a pm.

Hi @o0maddin0o

Is it possible that you have router version 1.0, does your router have a USB port?

If you upload the file somewhere and pass me the link I can try to see if it works. But I find it strange that you have been sent a firmware and I am told that v2.0 is not compatible with OpenWRT.

Greetings

This case is different, the incompatibility is artificial, not by nature or by bug.

According to the device trees in Cudy's latest firmware images the two models are mostly identical. In addition to the missing USB port and missing or unused USB LED, v2 has the WPS button on a different GPIO pin and it has a different "model" string, "R10" on v1, "R23" on v2.

The non-matching model string is probably the reason why the V2 device does not accept V1 firmware, even though it would most probably work, except for the WPS button.

It might be possible to trick the updater by editing the model string in the firmware binary, but there are probably checksums that would also have to be adjusted and the firmware might even be signed by Cudy.

In the latter case the only chances to get OpenWrt to the device would be either an intermediate OpenWrt image from Cudy like the one they provided for v1, or directly writing the U-Boot part of their v1 OpenWrt image to the flash and then flash OpenWrt using the serial console.

Yes, for now surely the only method that could be used to install OpenWRT would be to directly write the U-Boot as you comment. But this would require opening the device to make a serial connection to it which would prevent me from returning it in case I couldn't get it to work.

I don't know if the people at Cudy are planning to release their version of OpenWRT later for the 2.0 version of the router, but for now their answer is no.

Personally, what I am looking for is something that I can update comfortably without having to open it or having to go around with serial consoles. So I think I will look for another model.

On the other hand I think the change they have made to the 2.0 version is a step backwards, they have removed a functional USB 3.0 port to not make any improvement and continue selling it at the same price.

Inspecting Cudy's own image would at least hint at the format their firmware expects, which you could use to edit the existing v1 OpenWrt image.

Just ask them if they have plans to release a "step stone" OpenWrt image for v2 as well. So far they have always replied to my emails, although the answer wasn't always helpful and sometimes it was needed to insist and rephrase the question to get a better answer.

The firmware image appears to be a linear dump of the flash up to the size of the image with the factory partition obviously being skipped when writing to the flash.

"R10" and "R23" appear once within the U-Boot partition, then around offset 0x50000 in the uImage header, and in a JSON string right at the end of the image. I guess the web updater checks the latter for compatibility. That block does not seem to contain a checksum, but it might be part of the uImage and require adjusting checksums there when it gets changed.

I have asked them to tell me about their future plans, but I am not very hopeful. Besides, I understand that in order not to make a commitment they will not tell you an exact date, so you can be waiting indefinitely for something that never arrives.

I can try to change the strings in the firmware to see if it passes validation, but I don't know how to do it, if you give me a hand I could try.

yes i have a router with usb-port (v1.0). i bought mine at conrad.de. I wrote some emails with cudy support and they sent me then the file.

I have heard back from Cudy support about their future plans, so it seems they are completely ruling out offering OpenWRT.

Dear Customer,

Yes, you are correct. Only the X6, WR1300, WR2100 old version support the OpenWRT. As you can see, we also remove the page of OpenWRT.

Best regards,
Cudy Team

I have already requested a refund from Amazon because obviously I don't want a brick.

I think that someone responsible should modify all the notes regarding this model to clearly indicate that only the V1 is compatible with OpenWRT and so that if someone is thinking of buying it check that they find the correct version.

I've added v1 to the tech data entry, but broke something in the process.:confused:

@tmomas could you have a look at https://openwrt.org/toh/hwdata/cudy/start ?
Tried to add v1 to the hwdata page, but it changed the link text in the process.

Finally apparently from Cudy they have realized their mistake and have decided to release their version of OpenWRT for the V2 and even apparently for a V3:

Dear Customer,

Recently, we received much feedback about the demands of the OpenWRT firmware of WR1300 Version 2. So we released a OpenWRT firmware for it yesterday. I remeber you need it and if you still need now, you can kindly have a try:

https://www.cudy.com/openwrt_software_download

Best regards,
Cudy Team

Too bad I returned mine, but well, I'm going to buy it again because right now it's the best value for money option. I'll let you know when I get it (again).

2 Likes

I have the V2.0 router back and I confirm that you can change the firmware to the OpenWRT that the Cudy people give you at https://www.cudy.com/openwrt_software_download.

However, the official OpenWRT firmware is a different story. If I go into the System -> LED Configuration section, the system hangs. The WiFi does not work and gives this error in the dmesg.

[   11.437123] mt7621-pci 1e140000.pcie: bus=2 slot=1 irq=23
[   11.442585] pci 0000:00:01.0: enabling device (0004 -> 0007)
[   11.448262] mt7603e 0000:02:00.0: enabling device (0000 -> 0002)
[   11.454416] mt7603e 0000:02:00.0: ASIC revision: 76030010
[   12.486009] mt7603e 0000:02:00.0: Firmware Version: ap_pcie
[   12.491587] mt7603e 0000:02:00.0: Build Time: 20160107100755
[   12.534692] mt7603e 0000:02:00.0: firmware init done
[   12.703927] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   12.703961] ------------[ cut here ]------------
[   12.708629] WARNING: CPU: 2 PID: 766 at backports-5.15.58-1/net/wireless/core.c:882 0x826012dc [cfg80211@458f9f36+0x45f40]
[   12.719631] Modules linked in: mt7603e(+) mt76 mac80211 cfg80211 slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_ipv6 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c crc_ccitt compat ledtrig_usbport tun sha256_generic libsha256 seqiv jitterentropy_rng drbg hmac cmac leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common crc32c_generic
[   12.759016] CPU: 2 PID: 766 Comm: kmodloader Not tainted 5.10.138 #0
[   12.765345] Stack : 00000000 807200d8 809a0000 00000001 00000000 00000000 00000000 00000000
[   12.773689]         00000000 00000000 00000000 00000000 00000000 00000001 825219e0 f2631e59
[   12.782031]         82521a78 00000000 00000000 82521888 00000038 80399864 ffffffea 00000000
[   12.790377]         82521894 00000122 807c2868 ffffffff 825219c0 806ef0cc 80000000 806f0000
[   12.798727]         00000009 8277a884 8277a888 00000001 00000018 80403190 00000008 80980008
[   12.807076]         ...
[   12.809515] Call Trace:
[   12.809547] [<80399864>] 0x80399864
[   12.815450] [<80403190>] 0x80403190
[   12.818925] [<80007b08>] 0x80007b08
[   12.822394] [<80007b10>] 0x80007b10
[   12.825867] [<8037e984>] 0x8037e984
[   12.829346] [<826012dc>] 0x826012dc [cfg80211@458f9f36+0x45f40]
[   12.835238] [<8007fa1c>] 0x8007fa1c
[   12.838715] [<826012dc>] 0x826012dc [cfg80211@458f9f36+0x45f40]
[   12.844603] [<8002ff38>] 0x8002ff38
[   12.848084] [<826012dc>] 0x826012dc [cfg80211@458f9f36+0x45f40]
[   12.853975] [<80030000>] 0x80030000
[   12.857450] [<8018fcac>] 0x8018fcac
[   12.860928] [<826012dc>] 0x826012dc [cfg80211@458f9f36+0x45f40]
[   12.866828] [<8050834c>] 0x8050834c
[   12.870307] [<8276fd38>] 0x8276fd38 [mac80211@3a639f8e+0x81220]
[   12.876211] [<82739e20>] 0x82739e20 [mac80211@3a639f8e+0x81220]
[   12.882109] [<82701508>] 0x82701508 [mac80211@3a639f8e+0x81220]
[   12.888005] [<80395020>] 0x80395020
[   12.891477] [<804be560>] 0x804be560
[   12.894962] [<825e4254>] 0x825e4254 [mt76@34035c22+0xafc0]
[   12.900436] [<825f2920>] 0x825f2920 [mt7603e@54034d2e+0x96c0]
[   12.906160] [<8008c680>] 0x8008c680
[   12.909640] [<825f0168>] 0x825f0168 [mt7603e@54034d2e+0x96c0]
[   12.915361] [<803c96b0>] 0x803c96b0
[   12.918835] [<803c0648>] 0x803c0648
[   12.922304] [<80414ed8>] 0x80414ed8
[   12.925778] [<804158ac>] 0x804158ac
[   12.929251] [<8024bc14>] 0x8024bc14
[   12.932722] [<804163d4>] 0x804163d4
[   12.936202] [<803c04f4>] 0x803c04f4
[   12.939676] [<80416460>] 0x80416460
[   12.943147] [<804163e4>] 0x804163e4
[   12.946619] [<804132a0>] 0x804132a0
[   12.950095] [<80414ab4>] 0x80414ab4
[   12.953571] [<82600000>] 0x82600000 [cfg80211@458f9f36+0x45f40]
[   12.959470] [<82600000>] 0x82600000 [cfg80211@458f9f36+0x45f40]
[   12.965365] [<80416c54>] 0x80416c54
[   12.968836] [<800c1f50>] 0x800c1f50
[   12.972310] [<82600000>] 0x82600000 [cfg80211@458f9f36+0x45f40]
[   12.978207] [<825ff048>] 0x825ff048 [mt7603e@54034d2e+0x96c0]
[   12.983929] [<825ff000>] 0x825ff000 [mt7603e@54034d2e+0x96c0]
[   12.989649] [<8000157c>] 0x8000157c
[   12.993121] [<800c31f0>] 0x800c31f0
[   12.996594] [<8018fcac>] 0x8018fcac
[   13.000072] [<800c3210>] 0x800c3210
[   13.003542] [<800c5254>] 0x800c5254
[   13.007028] [<80014578>] 0x80014578
[   13.010508] 
[   13.012120] ---[ end trace a755b286f7613a01 ]---
[   13.018188] mt7603e: probe of 0000:02:00.0 failed with error -22

Surely V2.0 has some hardware change in the WiFi part, but I can't identify where.

I compared the device trees between the Cudy OpenWrt images for the two device revisions, and I can see some differences in the GPIO assignment for Buttons, LEDs and the PCIe interface to the WiFi chip. Also, the SPI flash is run at a much higher frequency by OpenWrt than in Cudy's V2 image, which has already been identified as problematic with some V1 devices.

This all would explain why you run into trouble with LEDs and WiFi, and it means that OpenWrt needs to be patched to support the new device revision.

Yes, I have already built a new version of OpenWrt for this v2. I have added a merge request with the changes.

As for the SPI flash, I have verified that in my v2 it works correctly by setting the same value as in v1. However, I have seen that some people have had problems with v1 having such a high frequency, but I have not been able to reproduce that error.

On the other hand, wifi chips are different:
V1: MediaTek MT7603E, MediaTek MT7612E.
v2: MediaTek MT7603E, MediaTek MT7613BE

That's why wifi doesn't work if you use v1 firmware.

Not sure if the decision to go with 80 MHz for SPI speed should be based on a single device that has run stable for a relatively short time. This has already shown to be not sufficient for V1 where it depends on the flash chip type and/or temperature of the SoC whether or not it runs stable at 80 MHz. I'd rather go with a lower speed by default (e.g. 40 MHz) to be on the safe side and ask some users to test it at 80 for a longer period of time, and only consider increasing the default it if none of the testers found any problems.

BTW, which type of flash chip is there in your V2 device?

I have not opened the case (for warranty reasons). In dmesg says:

spi-mt7621 1e000b00.spi: sys_freq: 220000000
spi-nor spi0.0: w25q128 (16384 Kbytes)

Thanks for the merge request. I'd like to review it but running into problems. I compiled an image based on 22.03.2 with your changes without errors. Flashing it coming from the Cudy OpenWrt 22.03.0 v2/v3 version worked and the box boots. But it is not reachable from the network and wifi doesn't turn on.

I used defconfig and changed the target to wr1300-v2 before compiling. A reset of the configuration by using the reset button worked but didn't change the result. The box is not reachable.

Can you please provide a working config file for the compilation? Would be great as I cannot figure out what I have missed in the config so far.