Flint - AX1800 will be a while. Unfortunately

I just received my Flint router, and I didn’t realize it was based on the IPQ6000. It’s in the specs, but I didn’t realize OpenWrt didn’t support it. It is only supported by QSDK which is based on OpenWRT 15. This is far too old to be useful. I am going to put this on the shelf until there is support. I don’t imagine that there will be support in 19.07 for the IPQ6000 so I think it won’t be until 21.02 version or later that supports it. I need to support some 3rd party packages that will not run on 15. It was a great idea but a waste of $100. Back to the drawing board.

1 Like

There are many other posts talking about this, maybe join in those conversations instead of starting a new one? :slight_smile:

https://forum.gl-inet.com/search?q=openwrt%2015%20flint

This thread is my favourite of the many:

1 Like

In addition to the thread vvv linked to, also see my posts here. My box is literally on a shelf with the shrink wrap - a complete waste on money. As far as I am aware, no one from Gli-net has addressed this issue or corrected their marketing materials that claim Flint “comes with OpenWrt operating system” and “OpenWrt is pre-installed”.

I suppose I could have found a different conversation about this and followed that one, too.

The unofficial information given is quite interesting. The device has a lot of promise!

I just wish Glinet would build ALL standard OpenWrt packages and put them in they repo at http://download.gl-inet.com/releases. IMO it misses a lot of kmod packages with drivers so I cant plug 2 additional wifi cards into flint. Full wpad would also be nice.

Yeah, I know what you mean. I think it’s just super new and once OpenWRT support IPQ6000 chips we’ll get more coverage. The problrem is really that GLinet hasn’t moved their stuff into 21.02. I really doubt 19.07 will see support for IPQ6000. So we have two things that needs to align. First the IPQ6000 support in vanilla OpenWRT then GLinet needs to move their whole platform to 21.02. These routers will sit for 1 maybe 2 years.

First, we are moving to 21.02 in our firmware 4.x.

Second, doing all our best to migrate AX1800 to higher version of openwrt. If possible use ath11k open source wifi driver. If not possible, port the wifi driver to higher version.

3 Likes

Timeline? If you read the discussion on the OpenWrt forum about support for IPQ60* there is every indication that in the best case scenario this is at least a year away.

Meanwhile you have Glinet’s marketing claiming “OpenWrt Pre-installed” when in fact they mean QSDK. QSDK builds “are not OpenWrt”.

2 Likes

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.

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:

https://wiki.codeaurora.org/xwiki/bin/QSDK/

2 Likes

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.

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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:

1 Like

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.

1 Like

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.

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.

1 Like

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.