IPQ5018: GLiNET B3000 info

For Developers
731

indeed, when next major release is out...

1 Like
732

It will make it into release at some point - sans NSS full support...

As others have mentioned - NSS within a chipset is supported to some degree, but across chipsets, it's a hard problem to solve...

This goes even with QSDK builds outside of OpenWRT

733

Is there the code/script to build the image with the NSS support somewhere?
I'm thinking in building an image with some changes, and it came to my mind the idea of rolling out a firmware-selector fork that includes customized changes like these.

734

Various NSS builds are posted in https://forum.openwrt.org/c/community-builds-projects-packages/11.

735

Thanks, actually I'm looking with just the diff that adds the NSS capability alone, since I know that all the SoC initial support is already in the openwrt upstream repository building snapshot images.
I guess might be a sort of c code and headers linked to the kernel, or maybe some headers linking to a closed source binary? I have no idea.

736

You are underestimating just how invasive and how much of a moving target[*] NSS support isā€¦ Of course a diff against rev 'n' can be done (which would probably be your job), but don't expect it to just apply to rev 'n+1'. It's complex and unless you're neck deep into the topic, you will fail.

--
[*] upstream NSS itself may not be, but that's because QSDK locks down hard on the exact kernel sub-revision and never updates it (within a branch), making -and keeping- it work against a moving target (OpenWrt) howeverā€¦

737

I'm not underestimating anything, when I said "diff", afaik, that's a measureless term, so you can have a single line of code or millions, whatever complexity it is, people told me that I'll fail my entire life and most of times they been wrong.
But thanks anyway for your -sincere- input, I guess we just need to leave this entirely in experts hands.

738

Someone seems to be working on NSS. The last commit was 18 hours ago. One detail: it says it's for the IPQ6018, not the IPQ5018. Perhaps it works for both, but I have no idea.

739

I installed a snapshot firmware on my device but decided to revert back to the OEM firmware. I downloaded the latest OEM version and attempted to flash it via LuCI. Unfortunately, this seems to have bricked my router.

I also tried using U-Boot to flash the OEM firmware, but during the upload process, the connection resets and the flash doesn't complete.

Is there any way to recover the router and bring it back to life?

740

Probably not bricked, turn it on, wait 5 minutes, then press the reset button until start flashing fast, then release and press it again until stop flashing, wait 5 minutes, turn off and turn on, wait up to 5 minutes.
hopefully it will clear the settings to firstboot ones.

741

Thanks for the tip!

I was eventually able to flash the OEM firmware using uboot from my Windows 10 bootcamp partition. I'm not sure why, but when I tried the same process from macOS, the connection would reset during the firmware upload on the uboot page.

742

Iā€™ve tried the latest OpenWRT snapshot and noticed significantly worse performance compared to the OEM firmware.

My internet connection is 600/600 Mbps using PPPoE with VLAN tagging.

Here are the speed test results over a wired connection to the router:

Software offloading active:

Idle Latency:    16.35 ms   (jitter: 2.57ms, low: 15.88ms, high: 20.60ms)
    Download:   350.09 Mbps (data used: 329.0 MB)
                 18.17 ms   (jitter: 1.86ms, low: 15.41ms, high: 25.93ms)
      Upload:   310.14 Mbps (data used: 475.7 MB)
                 19.23 ms   (jitter: 3.38ms, low: 15.34ms, high: 262.87ms)
 Packet Loss:     0.0%

Hardware offloading active (does this router support HFO?):

Idle Latency:    15.57 ms   (jitter: 0.58ms, low: 15.11ms, high: 15.86ms)
    Download:   474.52 Mbps (data used: 607.5 MB)
                 17.98 ms   (jitter: 1.45ms, low: 15.05ms, high: 32.45ms)
      Upload:   383.15 Mbps (data used: 484.0 MB)
                 18.55 ms   (jitter: 5.14ms, low: 14.98ms, high: 420.74ms)
 Packet Loss:     0.0%

None active:

Idle Latency:    15.98 ms   (jitter: 0.31ms, low: 15.60ms, high: 16.18ms)
    Download:   156.87 Mbps (data used: 193.9 MB)
                 42.47 ms   (jitter: 5.49ms, low: 17.45ms, high: 350.99ms)
      Upload:   134.77 Mbps (data used: 167.7 MB)
                 39.36 ms   (jitter: 5.56ms, low: 20.83ms, high: 159.25ms)
 Packet Loss:     0.0%

OEM firmware (network acceleration enabled):

Idle Latency:    15.92 ms   (jitter: 0.16ms, low: 15.81ms, high: 16.09ms)
    Download:   624.38 Mbps (data used: 757.3 MB)
                 48.10 ms   (jitter: 5.39ms, low: 34.31ms, high: 289.40ms)
      Upload:   642.36 Mbps (data used: 1.1 GB)
                 22.19 ms   (jitter: 5.75ms, low: 14.81ms, high: 524.11ms)
 Packet Loss:     0.0%

OEM firmware (network acceleration disabled):

Idle Latency:    16.01 ms   (jitter: 0.11ms, low: 15.88ms, high: 16.11ms)
    Download:   285.37 Mbps (data used: 506.4 MB)
                 36.39 ms   (jitter: 7.09ms, low: 17.18ms, high: 392.10ms)
      Upload:   274.92 Mbps (data used: 358.0 MB)
                 30.60 ms   (jitter: 14.02ms, low: 15.98ms, high: 614.24ms)
 Packet Loss:     0.0%

anyone else who can share his experience?

743

The GL-Inet firmware is based on QSDK, so when you enable their HW acceleration, youā€™re seeing the Qualcomm NSS doing itā€™s thingā€¦

744

can you please try the image here ? itā€™s a build with NSS added.

745

I realized that the vanilla OpenWrt images do not include NSS supportā€¦

746

Iā€™ll try to find some time to run a few tests. I assume I can flash it from luci as usual.

Have you tried it ?

747

I tried it, but since I was just trying to use this device as a bridged client I figured that I wonā€™t benefit of NSS not doing routing, I discarded the possibility of using it as main router too since I read that might be a bit slow or unreliable, not able to saturate a gigabit connection.

Just dont check the box of preserve settings, since might cause issues.

748

@georgem83 is there a reason you never enabled monitor mode for the 5018. I need it for a project, I got it going by simple setting it to true in core.c ..

diff --git a/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq50xx/linux-6.12.55/drivers/net/wireless/ath/ath11k/core.c b/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq50xx/linux-6.12.55/drivers/net/wireless/ath/ath11k/core.c
index afac4a1e9a..4493d69416 100644
--- a/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq50xx/linux-6.12.55/drivers/net/wireless/ath/ath11k/core.c
+++ b/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq50xx/linux-6.12.55/drivers/net/wireless/ath/ath11k/core.c
@@ -680,7 +680,7 @@ static const struct ath11k_hw_params ath11k_hw_params[] = {
                .interface_modes = BIT(NL80211_IFTYPE_STATION) |
                        BIT(NL80211_IFTYPE_AP) |
                        BIT(NL80211_IFTYPE_MESH_POINT),
-               .supports_monitor = false,
+               .supports_monitor = true,
                .supports_sta_ps = false,
                .supports_shadow_regs = false,
                .fw_mem_mode = 0,

Just wondered if you purposely disabled it for some reason ? Its enabled in oem ... for my device anyway.

749

support for ipq5018 wifi had already been upstreamed as such. I simply have never had a need to play around with it.

750

i kind of figured as such but thought I'd better check to be sure. I don't think its worth a pr, it looks like i am the only one who's noticed.