Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion

Its impossible to say what the ODM intended, do note that they multiple similar boards with a single image

This available as source?

Can BDF files be edited? @Ansuel was changing regdb inside them.

The package was manually prepared.
BDF files can be found in the firmware: https://dl46.askeycloudapi.com/file/dynalink/RT5010W-D350/DL-WRX36/
You can unpack it e.g. like this: docker run --rm -v .:/data/output -v .:/data/input ghcr.io/onekey-sec/unblob /data/input/Dynalink-RT5010W-d350-V1.10.01.254_sysupgrade_nand_img.bin and prepare board-2.bin using ath11k-bdencoder.


So I take that this is part of the closed source of the WiFi FW? Where to push to in a custom build ?

Why are we using docker to unpack?

unblob is written in Python. You probably didn't know that. Otherwise you'd know better than to ask that question. Here, I'll let Randall explain:
xkcd: Python Environment


This made me laugh.

But I still don't understand why docker and not native python or is this applicable to window users or because we need to run a specic version (older) ver. of python

Using docker is easier because you don't need to install (often even compile) the required dependencies. But this is just an individual preference.
Even binwalk is available as a docker image: https://hub.docker.com/r/refirmlabs/binwalk


Basically, what @lytr said.

A more involved explanation (laced with an opinion, though I know I'm not the only one holding it) would be that, although Python is a great language for ducktyping a quick and handy prototype or shell script, and it has an enormous, thriving ecosystem, it's performance leaves much to be desired (it is even slower than PHP), which is why most performance-critical Python projects depend on components written in serious languages, such as C, C++, or, lately, Rust. This, coupled with the shitshow that is Python dependency management, means that getting a project run on a native Python installation may turn out to be, to put it mildly, a bit... finicky.

So, once you've managed to painstakingly pull all the oddly Python-shaped pieces and native binaries together into a working whole, to ensure a low-hassle deployment on user systems, you might be better off by putting the whole shebang in a Docker container. Which is exactly what the unblob team does.

It was just last week when we ran into this problem rather painfully at my work.

We had all been happily using the notorious cassandra-migrate tool to update the local (Docker, mostly) instances of the namesake DBS on our work machines, when, after a long-overdue distro upgrade from Ubuntu 22.10 to 23.04, it just stopped working. Evidently some Python dependency/version mismatch. Nothing we tried was working (and I probably borked my systemwide Python installation), so, being pressed for time, we did just the above — pulled the Docker image that we're using to run DB migrations in our CI/CD pipelines, wrapped it in a thin POSIX shell script, and called it a day.

Moral of the story: Docker is reliable. Unlike Python.


this all makes me think if I should have maybe.. backed up the firmware before adding openwrt to keep the calibration data.

This is my experience with Python as well... In fact, I'm using a tool atm to address this issue the name of which escapes me... I'll dig it up Edit: Conda. Thanks for the in-depth.

1 Like

Openwrt uses exactly the same radio calibration used by dynalink FW.
If you go back to dynalink fw it will be like it was when bought.

I would like to mount rootfs_1's squqshfs while we have booted with root from rootfs mtd partition. I tried using ubiattach command first, then ubiblock command to create block device like /dev/ubiblock1_[0,1,2].
Finally I used "mount -t squashfs /dev/ubiblock1_1 /mnt". I got error message:
/dev/ubiblock1_1: Can't open blockdev

Has anybody tried this steps?

I get this error when building firmware using firmware selector. I'm trying to go from r23685 to latest snapshot

AUC and Attended sysupgrade fail too.

It must have a "case of the Monday's". :laughing: Give it time - it'll come back up.


We know, and it's not device specific, so don't post it in here.

An upstream commit changed things and now it’s broken. Should work again for firmware selector and luci, I’ll think about how to fix it for auc



Anyone have any comments on the problem I am facing as described in this :point_down: forum post?

If anyone is wondering, I sorted out my networking issues. They seem to have been related to config error on my end but also, i'm building fw for 3 different routers and it seems compiling for DIR-505 for reasons unclear to me, breaks VLAN functionality for future compilations of fw for other hardware

1 Like