Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion

Hmm ok I just got lucky and happened to put in a 32GB. I always thought max format size for FAT32 was 4GB but just looked it up that's the max file size, you're right about max format size.

1 Like

How good is actually the coverage/wifi performance on this router? From what I've read, some people have excellent signal and some are reporting that rt3200 gives better coverage. Would be great to hear more opinions on this topic.

THIS router... Loving it!!

Have 3 of these in our home connected via smart switches, head is OpenWRT1900ACS.

VLANS x 4 coming into each Dynalink, one for each WiFi network. 3 of which have roaming enabled (my IoT ssid does not require roaming)

Running a recent snapshot.

Router interface is snappy.

Highly recomended from here.

Just love OpenWRT and Linux in general, really good hardware to play with, so good! Happy days!! Thanks to all who contribute to OpenWRT!

4 Likes

So I just experienced an odd issue, my WiFi has gone down but I am Using 3 of these routers, and the both radios for all 3 went down simultaneously, so an external trigger?

/sbin/wifi status (translation by chatgpt) reports;

The output you provided shows the status of the radio0 Wi-Fi radio and its associated interfaces. Based on this output, it appears that the radio0 Wi-Fi radio is currently up and operational. Here are some key details from the output:

    radio0 is up: "up": true
    It is configured for the 5 GHz band: "band": "5g"
    The radio is using the HE80 (802.11ax) mode: "htmode": "HE80"

Additionally, there are several Wi-Fi interfaces (phy0-ap0, phy0-ap1, phy0-ap2, phy0-ap3) configured on this radio, each with its own SSID and security settings.

Since the status of radio0 is reported as up in the output, it suggests that the Wi-Fi radio itself is operational. If you are experiencing issues with specific interfaces or clients connecting to these interfaces, you may need to check the configuration settings for each interface or investigate any specific issues related to the clients.

If you have any specific questions or concerns about the configuration or operation of a particular Wi-Fi interface, please feel free to provide more details, and I'd be happy to assist further.

So now I'm trying to come up with a script that can action a newtork reload or other based upon a trigger event that can be detected but I am unable to source a trigger as iwinfo and above do not report any issues.

A reboot sorts it out but I'd like to better understand why this happend if anyone knows.

1 Like

Need to look at this later

Have you got the WiFi Multi To Unicast settings ticked?

Seems this setting needs to be set, otherwise you're going to experience a myriad of WiFi issues.

2 Likes

I do not, thank you. To come to think of it I do recall coming across this recommendation in this thread.

I'll enable.

Update: this seems to have fixed the issue for me!

Update 2: 15hrs later, still going strong without any drop-outs

1 Like

I created a an attempt to fix the annoying sysupgrade problem, where the ath11k wifi driver takes so long to be terminated, that the sysupgrade silently fails and the router boots without actually sysupgrading. This happens quite often with DL-WRX36, and the manual fix is to kill "wpad" process before sysupgrade is started.

See PR 13042 for the patch and explanation. I propose to add 2 sec delay into the "kill all processes" loop, so that the ath11k has time to die during that 10 times loop).

EDIT:
Note that the PR discussion now includes also a newer, slightly modified version of the solution. (where exactly is the 2 sec delay added)

10 Likes

Is there a reason why can't we just wait for the hostapd PIDs to die, after a kill was issued?

Some processes might be stuck, so the approach has been to first try nicely terminating the processes, and after a few seconds try to forcibly kill the remaining reluctant processes. That has worked ok for OpenWrt for the last two decades.

ath11k driver seems to be more difficult and slow to kill, (as apparently some TX buffers in kernel space cause a slower termination). There have been at least two alternative solution attempt PRs, but there has been drawbacks in both of them.

The sysupgrade scripts are 95% common to all targets, so there can't be too complex ath11k targeting logic.

Making the final kill loop a bit slower seems to do the trick, as it gives ath11k time to die.

2 Likes

Its ok. I would consider it "very good" in general. For the money, its extremely good.

So the question isn't so much, how can we know when the hostapd is dead so that we can proceed with sysupgrade, but how long should the opportunity window for a graceful shutdown be, before we terminate it forcefully?

Please read the discussion in the two PRs that I linked in my PR.
The process does not even react well to being "forcibly killed". (Likely too deeply in the kernel space IRQs etc.)

2 Likes

I'm going to merge this in my custom build, thank you.

Whenever I faced issues such as this in the past (i.e. sturborn processes needing to fully exit first before proceeding), it helped if we had a pid file for example at /tmp which could be monitored.

Wonder if the action of ath11k driver being loaded and subsequently creating a ath11kDriver.pid would help.

Then in a subsequent script, it could check for the existence of said pid and if present sigterm pid before upgrade is allowed? It sounds like the other issue is is getting it to exit reliably...

Perhaps another approach, scripting a block to the driver loading on subsequent boot in preparation of an upgrade?

Okay, so, WiFi just went down for me again... So strange that all 3 routers fails in this regard at the exact same time so there must be an external trigger at play... Anyways, until a better solution is found, I've scripted a workaround.

vi /etc/init.d/dynaquirks

#!/bin/sh /etc/rc.common

START=99

start() {
    # Kill Blue LED
    sleep 2
    echo none > /sys/class/leds/blue:system/trigger
    echo 0 > /sys/class/leds/blue:system/brightness

    # Check if the "dynaquirks" file exists and create it if not
    if [ ! -f /root/dynaquirks ]; then
        touch /root/dynaquirks
    fi

    # Reboot router when WiFi is down
    # Initialize a variable to count consecutive failures
    failures=0

    while true; do
      if dmesg | grep -q 'phy[0-9]-ap[0-9]'; then
        # Wi-Fi appears to be up
        failures=0
      else
        # Wi-Fi appears to be down
        failures=$((failures + 1))
      fi

      if [ $failures -ge 5 ]; then
        # If five consecutive failures are detected, capture date and time
        # and append it to the existing "dynaquirks" file
        timestamp=$(date +"%Y-%m-%d %H:%M:%S")
        echo "Wi-Fi failure detected at $timestamp" >> /root/dynaquirks
        reboot -f
      fi

      sleep 60  # Wait for 60 seconds before checking again
    done
}

chmod +x /etc/init.d/dynaquirks

ln -s /etc/init.d/dynaquirks /etc/rc.d/S99dynaquirks

/etc/init.d/dynaquirks enable

So, the condition if dmesg | grep -q 'phy[0-9]-ap[0-9]' checks if the "phy[0-9]-ap[0-9]" pattern is found in the output of dmesg. If the pattern is found, it indicates that there's some relevant information in the kernel ring buffer related to the Wi-Fi interfaces, which suggests that Wi-Fi is up. If the pattern is not found, it suggests that Wi-Fi may be down, as there's no relevant information about the Wi-Fi interfaces in the kernel messages. Script also silences the Blue LED.

Script also logs when WiFi drops at /root/dynalinks

Now on my routers I'm using:

if [ $failures -ge 2 ]; then

but I would cautions against setting a low fail count unless you have brick protection setup and WiFi networks already established.

condition if dmesg | grep -q 'phy[0-9]-ap[0-9]' checks if the "phy[0-9]-ap[0-9]" pattern is found in the output of dmesg. If the pattern is found, it indicates that there's some relevant information in the kernel ring buffer related to the Wi-Fi interfaces, which suggests that Wi-Fi is up. If the pattern is not found, it suggests that Wi-Fi may be down, as there's no relevant information about the Wi-Fi interfaces in the kernel messages.

What could possibly be causing this!? All three routers are connected to a UPS.

Kernel log

System Log

Update 2:
10 hrs uptime now (overnight) no issues.

Update 3
Just happened again this morning. This script is rebooting my router when WiFi does go down. I suspect 802.11r may be the problem. I've switch from FT over the air to FT over DS. I've also disabled "Inactivity polling" on all WiFi networks.

Update 4:
May have found the fix!
10hrs uptime (during the day)
Changes made;
Now using 802.11r "FT over DS" (previously was 802.11 "FT over Air")
Enabled "Disable Inactivity Polling"

Updat5:
24hrs uptime without a single reboot with script still running. So the culprit for the instability, router just required the right WiFi settings.

2 Likes

It looks like WLAN.HK.2.9.0.1-01890 was merged around a week ago... is it showing yet in anyone's builds?

I just used the Firmware Selector and it did not pull it in.

I build from sources with the full toolchain, and it is there

[   13.661065] ath11k c000000.wifi: fw_version 0x290104a5 fw_build_timestamp 2023-08-02 20:32 fw_build_id WLAN.HK.2.9.0.1-01890-QCAHKSWPL_SILICONZ-1

Ps. Note that in 23.05 you are supposed to get WLAN.HK.2.9.0.1-01385

EDIT: actually the PR is still unmerged, and I get the new version only because I have manually appplied the PR.

2 Likes

1862 shows in main. Did you build with the PR?

PR is not yet merged.

2 Likes

Actually, now when you say it, I checked and I do.
I got misled by the above:

It has not actually been merged, I think.

What has been merged, is the revert in 23.05 to an even older firmware.

2 Likes

I’m a doofus - I’m sorry - you’re right about it not being merged yet. I’m building with master, just wasn’t paying attention. Thanks for clearing it up.