hello folks,
is there any documentation/whitepaper available
that an non dev is able to trace the differences between the native and the modified one.
regards
I got a question 
What is the reason to check the difference?
To me as a developer it makes sense to distinct between the vanilla OpenWrt and the gl-inet variations, not only for the purpose but also because of different toolings being used, different patches, and therefore also on some versions different drivers.
For sanity it is required to get support where the image come from, because otherwise OpenWrt is searching a bug which doesn't exist in the firmware and only in gl firmware as example.
How far do you want to know the difference ? 
You could use the diff command on a other linux or in OpenWrt itself to check between files in /etc/config, but gl firmware also uses iptables and OpenWrt nftables.
Modified packages often get a ~ in there names.
What is after the ~ often refers a commit hash, but since it is private you can only know it is probably modified by a patch.
Also command:
ubus call system board
Will give you usefull info.
For me:
root@X-SDK-Central:~# ubus call system board
{
"kernel": "6.12.62",
"hostname": "X-SDK-Central",
"system": "ARMv8 Processor rev 4",
"model": "GL.iNet GL-MT6000",
"board_name": "glinet,gl-mt6000",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"firmware_url": "https://downloads.openwrt.org/",
"revision": "r0+32728-c9229d3ae2",
"target": "mediatek/filogic",
"description": "OpenWrt SNAPSHOT r0+32728-c9229d3ae2",
"builddate": "1766257088"
}
Clearly not OpenWrt or GL firmware 
Hello @xize11 
Yes, ure developer but im not thats what it makes an difference for me cause im not able to understand code in this context as ure able to do.
For me its interesting, to rebuild the features on an native open wrt which comes in glnet firmware from scratch.
For example add an wg connection which rules will be implemented or which interfaces will be added/modified.
Regards
Ah I see.
As for:
There are scripts often located in /usr/lib or in /lib on a bit older firmwares before the new vpn dashboard the script was called route_policy.
In short what it does:
it creates a table i.e 100 for wan, and a table 200 for vpn.
Then they define a ip rule, you can view this with ip rule basicly they define logic there for routing what goes for vpn gets put in table 200 and what needs over wan gets table 100.
In luci you also have ip rules.
Then they also add a firewall mark for both directions and allow forwards.
There is also a guide on OpenWrt but complicated.
^ this basicly shows how GL-iNet also does it for a big part.
Imo you can also replace that info with just a luci app called PBR, the only rule of thumb is to make sure there are not default routes, only lan, wan and wan type interfaces should have it defined, new custom interfaces such as vlan must have it unchecked because it doesn't need to be seen as default gateway.
See documentation:
Thnx for ur insights,
I’ll have an look on the folder locations.
But honestly i think its realls hard for me to gather so much knowledge to understand sth.
For me, it will be good that sth. exist like either an document which describes this for every or the most gl functions, like the
or an log,debug trace tool, which is able to record the necessary steps from the gl functions.
But may its not available atm.
Regards
1 Like
As far as I know there isn't anything official documentated, but maybe it is a idea for GL-iNet aslong it is clear for them for the awnsers you seek
Like the vpn script is a usefull one, since they changed names within the new dashboard I myself are also interested to see why the extra dnsmasq instances are needed for wireguard since that is what I see in luci.
1 Like
will be a nice move, may @bruce could say sth. to that idea.
regards
Hello,
For some reasons, the GL SDK is not public, and we can not provide a white paper related to the GL firmware.
Since the GL firmware is developed based on OpenWRT (closed-source based on MTK SDK or QSDK), we can learn information on the OpenWrt community about general interfaces, configurations, parameters, and more details.
No, I dont want the u reveal any company secrets or closed drivers.
Just what the frontend does in the Background which is also possible to do it manually with openwrt.
Regards
All is manually possible, and you can try to reverse engineer it. The UI is one of the company secrets. 
All changes are based on scripts made by GL (you can compare them against a vanilla image) and the UI itself.
You could rebuild the (nearly complete) same system by just using uci and knowledge of OpenWrt.
I used to make changes to how GL iNet firmware worked for some special needs I had, including support for some VPN protocols that GL iNet does not support. Many times I was able to understand their scripts and firewall rules and make the changes required to match my needs.
The big problem was that the next version of their firmware would break everything I had done. Even minor revision number changes would break things. My recommendation when using GL iNet firmware is this: if it does what you need in its unmodified form, use it. If you need to do anything custom, you are much better off using generic OpenWRT, where there is no undocumented proprietary layer getting in your way.
1 Like
hi Bruce,
I wonder is it not possible to have some kind of javadoc but only as a list to the scripts names?
This means the code is not shared, but there is only a pointer where the script is located.
That makes it much easier to self engineer custom changes, although there should be a rule that these codes cannot be spreaded in support threads/other githubs, due to the propetairy code.
With patching I see no issue never the less, what do you guys think?
It may not be available for now, but there is an API, through which some things can also be achieved.
But the API is not public either; it’s generally limited to 2B channels. (we indeed need to guard against some software rogues).
1 Like