Flint - AX1800 will be a while. Unfortunately

Radiocrazy · 2021-11-01T17:36:13.925Z

That sounds great because the Wi-Fi channels at present are very limited (in manual settings) and can’t be changed in LuCI as its too old.

Johnex · 2021-11-01T23:50:56.660Z

This is completely wrong. QSDK is a patched Chaos Calmer, OpenWRT 15.0.5 with a newer kernel and patches to make it work with the Qualcomm proprietary drivers. GL has also upgraded most of the packages. If some package has not been updated, they would be able to do it for you. Things like wireguard and openvpn are close to the latest version.

The specs GL have written for all routers are 100% correct, its OpenWRT; just an older platform version. Also notice that OpenWRT versions basically specify the filesystem layout, config formats, kernel and packages. It is not like in Windows. Parts can be upgraded independently.

For example, i am running the latest GL QSDK for the S1300. It has kernel 4.4.60 and OpenSSL 1.1.1i from December 2020, while Chaos Calmer, the version QSDK is based on, has kernel 3.18 (you can see directly in the link you posted).

You can read about QSDK here:

CodeLinaro Wiki

Welcome to the CodeLinaro Wiki!

PbH2O · 2021-11-02T00:47:10.856Z

Take it up with OpenWrt and QSDK: From OpenWrt history page (which I was quoting above), emphasis in the original:

OEM devices may indicate a specific OpenWrt or LEDE release name in banners or other locations that are built using Qualcomm Atheros’ QSDK. These builds, while based on OpenWrt code are not OpenWrt

The page you link to says the same. It doesn’t claim to be OpenWrt but something based on OpenWrt .

The QCA Software Development Kit (QSDK) project allows users to build an OpenWrt based platform

So when Glinet describe the router as having Openwrt preinstalled that is incorrect because firmware built with QSDK is not OpenWrt.

Johnex · 2021-11-02T12:40:16.127Z

This is just nit picking, and interpreting the text in a way that fits your narrative. OpenWRT just does not want people to go to their forums asking for support for QSDK builds, in the same way that GL does not support vanilla OpenWRT, just their own firmware.

The GL firmwares are all modified OpenWRT, changing things like default config, packages and so on. If we were to apply what the OpenWRT page says, then only routers with pure OpenWRT off the site with not a single file change would be able to be labeled as running OpenWRT, it’s just silly.

Having the firmware be based on OpenWRT is enough for most users. It is just a label anyway.

On top of this. Checking the link i sent you again, you can see this at the bottom:

FAQ

What are the major changes between OpenWrt AA and QSDK?

The following directories include patches and enhancements from QCA:

arch/mips/ath79/* – updated QCA base platform device support – GPLv2
sound/soc/ath79/* – new ALSA-compliant QCA soundcard driver – ISC
drivers/net/ethernet/atheros/ag71xx/* – updated QCA Ethernet switch driver – GPLv2
net/core/* – performance enhancement updates to Linux sk_buff management – GPL v2
drivers/spi – added modes to QCA spi driver – GPLv2
drivers/mtd/nand/ – new QCA NAND flash controller driver – ISC

OpenWRT with files added. Again, it’s just silly to say that adding some files to the base OpenWRT makes it no longer OpenWRT.

mfoxworthy · 2021-11-02T15:14:29.488Z

I’d kind of like to keep this on topic if we could. QSDK is NOT GL.iNet 3.203 or 4x. All the other GL.iNet devices we use are. We are eagerly awaiting a 21.02.x release for other reasons. However, QSDK is based on OpwnWrt 15. There are numerous dependent libraries that are nowhere near 19.07 or 21.02. For example, the entire TCP stack. A simple diff in the kernel net directory will tell you all you need to know. For this reason, I cannot run my custom software on this device, we tried. The amount of back porting we’d have to do is just not worth it. Also, we build our images based on the GL image builder. There isn’t one for the QSDK versions. This breaks our entire CI/CD chain. This device is simply not ready for prime time to replace previous GL gear. So again, it will sit on the shelf until it can. It’s a great hardware platform, we are eager to use it, but it isn’t ready yet. We will stick to the Beryl for now and forgo our plans to move to WiFi 6, at least with this product. To that end, devices that support the MT7621A (built in GigE switch) look promising. There is support for a few in 21 snapshot already.

You must also consider that IPQ6000 chips are not generally supported by OpenWRT 15-21 at all. This is a pure QSDK development. This means we are stuck with those package repos. They are missing a lot.

mfoxworthy · 2021-11-02T16:30:58.409Z

It looks like the ath11k open-source code had been done for about 6 months or so. I’m not certain if it supports all the IPQ6018 features or not, but if it can drive the basic WiFi and ax functions, it’s a good place to start. Porting the WiFi driver to GL 4.x and releasing 4.x is preferred, but we’d be happy with a 3.20x version for now if that is all GL can sign up for. We just need WiFi 6, multicore CPU and OpenWrt 19.07+ for the basic configuration we have. We have an upcoming project that will require bandwidth and CPU performance beyond what we currently support.

Johnex · 2021-11-02T16:33:28.076Z

The stack issues yeah, but there is imagebuilder for the QSDK devices. I use it every day to compile for the S1300 and others. It might not be updated for Flint yet, @alzhao can answer that.

You can see here where the Imagebuilder binaries are stored:

GitHub

gl-inet-builder

gl-inet-builder has 61 repositories available. Follow their code on GitHub.

mfoxworthy · 2021-11-02T16:44:13.619Z

I should have been more specific. Our build process builds all devices with all of our custom code at the same time. Think -p switch. While there is an imagebuilder for QSDK it isn’t the same as the imagebuilder we use for our CI/CD processes. We have generic OpenWrt device we support too but again, they are also based on the imagebuilder for OpenWrt much the same way. So, it isn’t really useful yet. But what alzhao said in the last reply sounds like it could be a near term option. I looked at the repo for the open-source ath11k driver. It looks complete. But also porting a driver to support 19.07 or 21.02 would also be a good option. I don’t mind building my images from the GL.iNet imagebuilder and using those as long as my software works.

PbH2O · 2021-11-02T17:34:40.782Z

mfoxworthy:

QSDK is NOT GL.iNet 3.203 or 4x. All the other GL.iNet devices we use are. We are eagerly awaiting a 21.02.x release for other reasons. However, QSDK is based on OpwnWrt 15. There are numerous dependent libraries that are nowhere near 19.07 or 21.02…You must also consider that IPQ6000 chips are not generally supported by OpenWRT 15-21 at all.

Exactly.

There are also security considerations. Unlike those other devices, it’s not just running an old version of OpenWrt but a 4+ year old Linux kernel. Many people run real OpenWrt to avoid exactly this issue. Most OEM’s that sell routers don’t adequately update and patch their firmware. This has been a notorious problem for years. See for example here and here.

Johnex · 2021-11-03T11:59:01.093Z

That doesn’t apply to GL. Even though the kernel is older, GL has patched all firmwares when vulnerabilities were found such as

FragAttacks (CVE-2020-24586, CVE-2020-24587, CVE-2020-24588, CVE-2020-26139, CVE-2020-26140, CVE-2020-26141, CVE-2020-26142, CVE-2020-26143, CVE-2020-26144, CVE-2020-26145, CVE-2020-26146, CVE-2020-26147)

Again, you can’t just compare a version number. Patches have been made to all kernels from upstream when needed.

PbH2O · 2021-11-03T15:30:36.654Z

Johnex:

That doesn’t apply to GL.

Trust us because we are not like any of those other router companies? No thanks, not after the claimed OpenWrt turned out to be QSDK.

mfoxworthy · 2021-11-03T16:13:20.026Z

I’m just going to hold off on AX until IPQ6000 SoCs are part of the vanilla OpenWrt build or GL rolls in the ath11k driver. That is the only thing holding me back. If I can get all that working with our LTE dongles, we’ll migrate to Flint. Just needs some dates so I know if my waiting is futile. Need some transparency, is all.

Johnex · 2021-11-03T18:05:22.789Z

You can check the forums for past vulnerabilities that were fixed. If that isn’t enough then return it and get another OpenWRT router with Wifi6. You seem like one of those users that will never be happy no matter what.

alzhao · 2021-11-04T01:31:36.237Z

mfoxworthy:

If I can get all that working with our LTE dongles

That does not need to be ath11k. We can make it work in current firmware, cannot we?

ath11k is not impossible though.

mfoxworthy · 2021-11-04T17:23:28.741Z

That isn’t all I/we need. We are using MPTCP which now only supports 21.02.1. We have our own TCP acceleration software for sat links which needs 19.07 or newer. We have MQTT management software (Not Gls MQTT) that requires 19.07 or newer. We use a custom version of netifyd that requires 19.07 or newer. We build our images with those custom packages on top of GLs imagebuilder. It’s not just the ath11k driver that is needed, it is 21.02.1 that is needed for other reasons. I doubt IPQ6018 support will be in 19.07, in fact, the other forums I’m watching pretty much confirmed that. So, as I said in an earlier post, I think we need IPQ6018 support in 21.02, and we need GLs 4.x version to make all this align. One other thing to note, 21.0.1 is based on kernel version 5.4.154. The ath11k driver is being tested, at least right now, on 5.13+. I don’t know if those are really that different or not in terms of ath11k driver. I have considered porting it to 21.02.1 myself just to kick things off, but I just don’t have the resources for that right now.

PbH2O · 2021-11-08T21:30:57.360Z

Johnex:

return it and get another OpenWRT router with Wifi6

“another OpenWrt router”? Seriously, Flint is not an OpenWrt router and is unlikely to be one any time soon. OpenWrt itself states that firmware built with QSDK is not OpenWrt. Why do you insist on pretending otherwise and ignoring the fact that misrepresenting what you are selling is a real problem for some users for a variety of reasons?

I’d be happy if I could return it but it was an international order so unless Glinet is paying for the shipping – which seems unlikely given that Glinet doesn’t appear to recognize there is a problem slapping a label on something and selling something else-- I’m not throwing good money after bad.

Johnex · 2021-11-08T22:51:53.078Z

@PbH2O

him · 2021-11-25T07:41:37.772Z

Damn, and I just purchased the Flint hoping it’d be better than the Beryl.

If you or anyone is using vanilla OpenWrt on a router with AX compatibility(that’s stable or will be in the near future) that they can recommend, I’d be grateful.

him · 2021-11-25T07:46:58.262Z

Do you understand one of the fundamental reason why a lot of your customers buy a OpenWrt router?

A Chinese company selling routers touted at giving users control of their internet privacy, yet reading this thread is portraying something different and given the bad press on Chinese operations I don’t know why you think it’s funny. You will be seeing a very negative review on amazon linking this thread and others to save potential buyers the hassle, since your marketing fails to be transparent when you promote and sell your ishwares, it seems like others have to!

Johnex · 2021-11-25T23:42:20.846Z

First of all i am not a GL employee so its not “my marketing” and “your customers”. I moderate the forums on my free time since i love the GL products. Second, i’m not even Chinese. Yes it was very funny, all he was saying, since all GL routers are OpenWRT based, fully patched for vulnerabilities.

GL has never stopped giving users control over their privacy, i don’t see how me laughing at a user twisting words for his own narrative do that either.