Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion

Interesting, I'm running an 1 yo snapshot, and have had zero issues with my two WRXes.

1 Like

Out of curiosity, how many SSID you have per radio?

(My dl-wrx36 router is otherwise quite stable, but multiple SSID seems to cause occasional closed-source WiFi firmware crashes when a client leaves.)

I’ve tried snapshots, stable, multicast fix, everything I’ve seen on here. The disconnect when clients disconnects is the main problem for me. I only have 1 SSID per radio too.

1 Like

just one on each ...

I am using this router already for a couple of months and it works well, I did not find any difference between my R7800 and the DL-WRX36 regarding range but I did not do any formal testing.
Being an AX router the DL-WRX36 has about 15% better Wi-Fi throughput on average (depends on the distance of the router i.e on the signal strength)

But the router is lightly taxed with only 2 phones, a tablet and a smart TV.

I bought it including taxes for slightly over € 100 so for me this seems a bargain, only down side, I can not mount it on the wall :slight_smile:

1 Like

The testing I did was apples to apples...same location, same settings, same client and client distance, iperf3 server running on a device with plenty of free resources (an R4S). Key is that my use prioritizes 5 GHz 802.11ax dumb AP performance at medium to long range in my home office. In that comparison, the DL-WRX36 throughput was less than and more variable than the RT3200. The latter got me closer to my half Gig ISP speed over WiFi. I could also get an RT3200 shipped for under $50, so comparing both was not too costly.

All that said, the DL-WRX36 still worked and functioned acceptably. Oddly enough, I am the only member of my household that obsesses over clean iperf3 WiFi throughput tests, latency statistics and CPU utilization. The rest of them just decide if "it works" and if the answer is yes, they are happy - until I give advance notice of a sysupgrade, in which case I'm rewarded with an eye roll from the ungrateful Luddites.

Finally, the DL-WRX36 is hands down the better gateway router. There is no getting around its 2 GHz four core CPU and plenty of memory.

1 Like

I haven't had a single wireless driver crash in around four months now, on 3 separate WRX36 devices.

wrx1 is my router, connected to a Virgin Media DOCSIS3 cable modem (1Gbps/100Mbps) with a tunnelbroker 6-in-4 tunnel. It provides to the LAN side DHCP, NTP, DNS via DoH proxy; it also runs a tailscaled instance and an nginx reverse proxy for a couple of internal services. There's a wired VLAN trunk to wrx2, and an 802.11s mesh link out to wrx3. It broadcasts 2x 5GHz SSIDs and 3x 2.4GHz.

wrx2 is an AP, broadcasting 2x 5GHz SSIDs and 2x 2.4GHz and an additional 802.11s mesh link to a Zyxel AP down the garden.

wrx3 is an AP using mesh backhaul, advertising 1x 5GHz and 2x 2.4GHz SSIDs.

Each SSID is in a separate firewall zone that links into corresponding VLANs - one for our phones/laptops etc, one for guests, and one for IoT stuff.

I've got "multi-to-unicast" set on all SSIDs, which does have the side effect of breaking ota flashing of e.g. ESP32 devices using the espota protocol if the flash source is on a different SSID but that's not the end of the world.

For some time last year things were desperately unstable, with ath11k driver crashes at least weekly. Now though I can't recall when the last one was.

All three units are running a snapshot from last week. I'm very very happy with them, especially considering how little I paid for them!

3 Likes

I've obtained a dump of the "bootconfig" areas in my efforts to understand the OEM boot process.

Both files have exactly the same contents. I'm showing the relevant area as described below, the rest of the file is 0x00 or 0xFF.

I think I can't do further RE work until I can get a diff against some other files. I've never connected my unit to the Internet so it's on its original firmware. If someone who has updated their unit with the OEM utility could share it'd be appreciated.

Notable findings: The file is 512K in size, but only the first 2K page has ever been written, the rest is unformatted 0xFF. The written part is appears to be mostly empty (0x00) save for 336 bytes of 0-padded ASCII at the start.

I can see two possible ways the partition is selected.

  1. The partition name is changed - each partition is stored as its name in ASCII, so perhaps it changes from 0: to 1: or 0:1, depending on the formatting.
  2. There is a single "0x01" byte as the last nonzero byte before the footer, at offset 0xBC. I believe my device is on (CORRECTED) OEM slot 1 (of 2) [rootfs, not rootfs1]. So this may just indicate all partitions are to use the second choice.
  3. There is also a "0x02" byte immediately after the header, offset 0x05. Whether this is part of the header, wear-leveling, index, or something else I am unsure. I don't think this is partition-select since it seems to use 0/1 elsewhere but may be wrong.

Now, of course, the question is about what may happen for wear-leveling or bad-block management (I never did get a confirmation as to whether these partitions are in the "guaranteed" extended-durability region or not).

  1. The data may move around in the 0-marked region of memory. There are header and footer data elements (0xA0 0xA1 0xA2 0xA3 and 0xB0 0xB1 0xB2 0xB3, respectively) and the end of the nonzero portion (last digit of the footer) is only at 0x14F (for a size of 0x150).
  2. The data may move around within the entire 512K partition; if so I'm guessing it does so 1 page at a time. I don't have enough evidence to say how it indicates which page is active.
  3. Some combination of the two. Also worth noting is that there are two of these files, so it's possible that there's a checksum that I've missed indicating which or both are accurate. More likely, it uses the ECC of the nand itself and the pages are written one at a time (and the full page at once) so one is always valid. The version number could be the 1 or 2 I've seen so far, or a 0 that blends in with the others.

The wear-leveling/versioning (if present) and finding out exactly how it indicates the partition swap is the reason I request alternate copies to inspect.


Of course, this just tells bootipq what to load. I think we have other issues getting it to actually boot from there???

I am still expierenceing the occasional ath11k firmware crash that requires a restart of the router to get WiFi back. Otherwise, the router has been great. Hopefully, at some point we will get new firmware with a fix.

I was doing a further mosey through the OEM platform.sh in search of further details of the process...

Research notes

So, the upgrade process apparently starts with listing out the names in a dumpimage -l of the OEM firmware. This gets sent through a switch block to figure out how to write those. Mostly a few extraneous settings like the block size, but then it calls one of several write functions. Apparently this allows something like a differential image, where it only updates the things that actually need it.

Interestingly, for most of those individual write functions, it's given the name straight from the dumpimage. A few others use a hardcoded mtd name. These seem to be the base name of the mtd (that is, no trailing 1).

The trail, for those partitions that use dual images, next goes to a certain dratted kernel module, because a call is made to a path in /proc that gives us the name of the new target mtd location.
A second call to a path in /proc also checks if the name is the "primaryboot" and then writes the alternate value (0 or 1) to the same location.

If it can't make the call to that module to get the name, this section is bypassed. I presume this is for certain devices (there are a lot of listed ones in the script) that don't have dual-image for some/all of these partitions.

The actual write is accomplished by mapping the mtd name back to the mtd device then writing it or ubiformat-ing it.

After all of that, it writes BOTH bootconfig partitions sequentially with the same data from the module. So I assume that part is a simple whichever-one-survives failsafe. Writes are probably atomic, too, but we've already established the data fits within a page. We just don't know for sure it's always the same one.

Also, minutiae: Most partition updates use the dual-image system, but SBL1 (presumably 'signed boot loader,' I guess the uboot?), DDR/CDT (ramtest/setup?), DTB (device tree?), TZ (trust zone?), and SSD (no idea?) updates are just written as-is. There's also code to write an emmc device, but obviously that doesn't get used on this router.

Wi-Fi firmware has options of regular or ubi flashing, but the dumpimage name doesn't seem to have ubi in the "Image" part (despite it being in the description on my image), so it may be writing those as-is too.

Next steps (that I need help with):

Can someone hook me up with firmware upgrade images that are known to still be compatible with our SSH-enable hack (and ideally which don't upgrade me to the muted uboot)? I could try to disable the downgrade prevention by editing the sysupgrade files so I can just reupload, but it might also get enforced elsewhere.

Anyone know what command I can use to log data to the SSH terminal while updating? The script would be run by a different process than my SSH'd self, so I'm fairly sure I would not receive an echo to STDOUT.

With these, I can try to instrument these arguments and figure out where this data is coming from and also see how the bootconfig gets updated - both with the active partitions and how it's wear-leveled.

I'm setting up a new WRX36 and am a bit confused about whether or not it uses DSA. I've searched the forums and found some posts that say it does while others say it doesn't. Could someone clarify, if it does or doesn't?

I ask as I'm wanting to set up multiple bridged networks like the example "2. Multiple bridged networks" at:

If the WRX36 doesn't use DSA, would that setup still work or is there another applicable guide that might show how to do multiple bridged networks?

Thanks for any responses.

Of course, I'm still on stock 1.10.01.222, just like the August day I unboxed it brand new and patched into my trusty aging TL device last year. So, for all those out there quaking in their breeches about connecting this device to the Interwebs —

stock firmware does not autogprade

— or, at least, the build that I have doesn't do so in my setup. Evidently, either I'm just very lucky that my device is so very special that hasn't happened on its own over these past 5 months of being connected 24/7, or there's a glaring skill issue that has been the cause of those sporadic stock firmware upgrades that some report having experienced. (Hint: the webgui pops up an update nag every time one logs into it right after a restart.)

Here's the sha256.sum of my MTD dump files.
ccc4458b57d34acedad3ad170376b68318e23c1426db8009f5b2d488c8d5d88c  00-0:SBL1.bin
b2ff2eda7b9657adfffcdede04855a00d82daee4c35944eb4ba3790b6f699766  01-0:MIBIB.bin
2e749b1f51daec10ebf6b36b70e00d1b7038aed540d97c596464fa810e555570  02-0:BOOTCONFIG.bin
2e749b1f51daec10ebf6b36b70e00d1b7038aed540d97c596464fa810e555570  03-0:BOOTCONFIG1.bin
a19a4182bf9788528c4ecfbc3db1d9c60e15d4d5f240c8f418c0fe61e1c56e5d  04-0:QSEE.bin
a19a4182bf9788528c4ecfbc3db1d9c60e15d4d5f240c8f418c0fe61e1c56e5d  05-0:QSEE_1.bin
6ea8db02d57675dd068af7b1045aea13bed78c51ebf7f70e77acda5048c50f6c  06-0:DEVCFG.bin
6ea8db02d57675dd068af7b1045aea13bed78c51ebf7f70e77acda5048c50f6c  07-0:DEVCFG_1.bin
043e238a765f7cfbc62596a50e53c8ffb6b188a99357b0ebede251725d67589f  08-0:APDP.bin
043e238a765f7cfbc62596a50e53c8ffb6b188a99357b0ebede251725d67589f  09-0:APDP_1.bin
19eb5877630541af48347e2ec640f0654a57c5eced1aedb45960ec6357154f43  10-0:RPM.bin
19eb5877630541af48347e2ec640f0654a57c5eced1aedb45960ec6357154f43  11-0:RPM_1.bin
e3964a4f1c159779b1845e284a32efb911b4c450f78fdee0226ee977d90fbff3  12-0:CDT.bin
e3964a4f1c159779b1845e284a32efb911b4c450f78fdee0226ee977d90fbff3  13-0:CDT_1.bin
0b7cf84d28aade4980ccaebd0dde16e170c5c7d0b0166c938c6d020640ed2c97  14-0:APPSBLENV.bin
22566b3b05275e30430229b9d6bc36c2a4eb60fb4f3dd1d97c1f57753fa16147  15-0:APPSBL.bin
22566b3b05275e30430229b9d6bc36c2a4eb60fb4f3dd1d97c1f57753fa16147  16-0:APPSBL_1.bin
6618ed844b5cb6db360498e75e0c3b3a209e75e5023308af2d75598e2df960e9  17-0:ART.bin
92ea6f2f9f924af11117f66eff895b523a293b4d58161443919fb4bc719aeba4  18-rootfs_1.bin
5fa21b212db8323e0b8d40365c2564d686dd4671f76b08fa2ee9abd74f550cd2  19-0:WIFIFW.bin
93d69a0c350ffb4938080cd0b531109bbb83e8b2cfe7673d9cba27cbe8cc4e77  20-rootfs.bin
4c03302842dd5f71d0174ebd5b8909f62d96f74a29843e35e82c6d2cf3135815  21-0:WIFIFW_1.bin
2fc7b959018c121c2917656b0bc8e54ce199c04ab793bd87929c6a0978f470a5  22-ubifs.bin
043e238a765f7cfbc62596a50e53c8ffb6b188a99357b0ebede251725d67589f  23-0:ETHPHYFW.bin
7094f4b0230dc8d4fc4ae709c54930d52a24c7affda52440e1fa1065e14bc799  24-certificate.bin
b0da275fa1650ded69a2a37bb061743ce54a2f857c1214711e5acfe4f6d7d56a  25-kernel.bin
7254fdc3edaddabe27c2b7843f4f757460699c16201c54f2b747692b13f86a91  26-ubi_rootfs.bin
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  27-rootfs_data.bin
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  28-log.bin
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  29-vendor.bin
e528a4b8f8565850dfdbd3052c44db7b224f239db5d0ce090f50ac3825ef9538  30-user_data.bin
8e6c0aa32fa5f9ae3021dc537c8f091e52396284666fd693a38e20697d854540  31-wifi_fw.bin

Does any of these seem interesting to you? I suppose, you wouldn't care for those that are identical to what you already have, but I'd be glad if you find something useful among them.

Concerning,

what command I can use to log data to the SSH terminal while updating?

as long as it's truly SSH we're talking about, not telnet or other kind of remote terminal conn, you can employ SSH multiplexing. If you're running on the stock DNS settings and use the hostname to connect, just plop the following lines into your local ~/.ssh/config:

Host login.dynalink
	ControlPath ~/.ssh/cm-%r@%h:%p
	ControlMaster auto
	ControlPersist 1m

Read up the ssh_config(5) manpage (and/or the cookbook linked above) for details on how to tweak this to suite your usecases the best.

1 Like

I see the exact same. The milliseconds drop is notorious with VoIP calls. And it happens with a new client disconnects.

I am using SNAPSHOT r24895-3cf1fe5508 / LuCI Master git-24.023.26952-a4fd238, I see the following in my logs;

ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 146

I believe there is a security related 802 flush that should be done per disconnected client, but in ath11k we end up flushing the global shared queue, and thus we lose packets in a way or stall the queues.

See commit which in other posts indicate is where the problem was introduced d54c91bd9ab3c54ee06923eafbd67047816a37e4

package/kernel/mac80211/patches/subsys/331-wifi-mac80211-flush-queues-on-STA-removal.patch

Anyone wants to revert that and give it a go if it fixes it for their Dynalink DL-WRX36? To at least isolate it out

I just received my Dynalink and unfortunately it came from factory with firmware version 1.10.01.245. The WebUI has no option to enable SSH.
I attempted to download the backup.cfg file @NicholasKK linked, but that appears to have expired.
I did find an alternate firmware version V1.10.01.201 in this thread and attempted to downgrade the device to it via interface, but that generates an error indicating earlier versions cannot be used.
I did see earlier in this thread discussions on several OEM firmware versions ( .245 included ) and seemed those were being researched to find changes.

The most recent post I could find that both specifically mentioned starting with a particular OEM firmware version, and a successful OpenWRT install via SSH method was version .231, but included the use of the .cfg file for which the download link expired. I was unable to find any other alternate links to that file ( except the older ones where the default password would not work.

I am just wondering if the OEM firmware version my device is on has obsoleted all options ( listed in the Wiki ) for flashing to OpenWRT, or if there might be a future workaround.
Trying to figure out if I should return this, or hold on to it.

Thanks and regards.

The link for the premade backup config file, enabling SSH, is located in the DL-WRX36 wiki

Thank you @otnert , that is exactly the link I used, but the download was not functional. Though the link still leads to a page on mega.nz, the download link generated an error.
Specifically the file at this link did not download. Was it expired or deleted? mega.nz/file/QVdBCCTR#czWjAT6If4RN_JjArdexUgq3DmFiAjaJMEpg8zw2IB4

mmm, it's still working for me...

anyway here's a temporary link to the same file I just created.
sha256 8585c4adae74622924acc6bc4a639f5e9102f492fcf60b3fa4ddbab8e62fb27e

1 Like

Can you share one of the bootconfig files? You've got a different hash than mine.

fbfb29d3905eb410421ee2a40efda5ab5cb90288820fe6f6a02563786ab8da94  0.bootconfig.mtd2.bin

Also, to clarify, I'm trying to find a way that I can redirect logging output from, say, a statement I can put in the sysupgrade shell scripts, to my computer when I upload a firmware image via (I assume) web UI.

I haven't checked if I can use sysupgrade from the command line in the OEM firmware, maybe that'd work, but the issue is that I want to get output from the subordinate scripts it calls, not just the main one, and if I do run it via the webUI it's a totally different user with a different stdio. And it wipes much of the OS then reboots, so I have no idea where to put a file if I try to persist that way.

Works for me too, even on my cell phone, the problem's on your end, @JustAnotherEndUser.

Many thanks @otnert , your link and file worked and as a result I was able to successfully flash my device using the SSH method.

@frollic , not sure what the issue was for me with the other link. I was able to download other files linked to mega.nz but that particular backup.cfg gave a constant "error / retrying" message.

I read many posts during this experience with flashing the Dynalink. I came across additional issues pointed out by others above in this thread, and was able to workaround. When I have time later, I will compile the details of these and post in hopes of helping others.

Thanks again.

2 Likes