GL-iNet false advertising, not really using OpenWrt?

Technical Support for Routers
21

Depends how you look at this.

But theoretical its invalid to call it only OpenWrt.

If that was true, my issues with vlans would also be happening on pure openwrt but that is because there are scripts and logic which are not in OpenWrt, the wireguard is completely different between GL-iNet and OpenWrt, heres one example: when i use opkg banip the wg tunnel gets not detected because its different implemented different uci nodes get intepreted and a different config, on pure OpenWrt its implemented in the network config.

Then there are also routers with siflower arch, these routers are never compatible with pure OpenWrt and closed source.

And then there are also routers with only QSDK (qualcomm sdk), or MTK SDK (mediatek SDK) with propertairy drivers.

As soon propertairy comes at play, and there is no source and there are major differences which do not co-exist with normal OpenWrt i.e wifi drivers, you cannot call it pure OpenWrt like that, but a fork and support should be handeld on the forks channel👍

1 Like
22

They run a fork, it’s not pure OpenWRT, it doesn’t matter it’s a old version.

Yeah, that’s the false advertisement we talking about :rofl:

2 Likes
23

So it doesn’t run on OpenWrt 18.06? (the original post was moaning about lack of support for older versions - not that it didn’t run the older version entirely)

24

For the last time, GL-iNet routers run on a fork of OpenWRT doesn’t matter what version :person_facepalming:

25

So the main question is if you need to tell it someone. Is it needed to say „fork of OpenWrt“? Or would it just be more precise?

26

I would advise to say fork.

Also because it might be a branding issue aswell.

If you call it OpenWrt and not a fork, people have expectations of OpenWrt and also 100% interopability, but when it is a fork they have 0 control what else has been changed.

Which can cause situations openwrt team get blamed for issues in a fork or gl-inet for that mather😉, when the issues may only be existing in the fork.

To be honest ive no issue if people chatter here about it like this, but it is more how it is been set in marketing the expectation it creates.

^ this will assume people to have full potentional of OpenWrt without the regressions of internal functions or backports which are not visible, a clean source with just a ui.

People often think its just a gui overlay, but to be more precise there is much more different, the firewall wan zone is set to reject on OpenWrt, but on gl-inet its drop.

And then there might be propertairy changes to mt79 which are not from OpenWrt.

2 Likes
27

I will just say, most of the folks who are set on using OpenWRT will be able to tell immediately upon logging in or seeing the pictures of the interface that it is not an OpenWRT interface. If they don’t understand that piece, then I am not sure any real amount of word smithing will be able to prevent them from blaming someone who is potentially not the source of their ire.

2 Likes
28

The problem here it’s the “marketing” wording used by GL-iNet on the description pages of their products, read again…

1 Like
29

I have read these and posted my opinion of the situation, which has not changed. You and I do not see this the same way. It is ok to disagree, though.

30

the large mislead of point is no software description on specification page

biggest bugger

31

We are not running fork of openwrt now. We did that before.

We add our stuff on top of openwrt.

We have labeled the openwrt version, kernel version etc clearly.

We are using the openwrt text according to their policy.

We have no interest to argue about the definition of openwrt or open source, whether it is called pure openwrt, vanilla openwrt modified openwrt or customized openwrt. We have stated it clearly.

If you see any volition or miss use of open source thing we have email address that you can report: support at glinet.biz

3 Likes