I'm trying to create a vxlan interface on the Brume 3 4.9.0 beta2 with luci-proto-vxlan from out the wan access.
It does not want to apply it just logs me out.... if I do forced save and apply, it does apply but the config is never written.
I'm not sure why this is, but this can be a huge issue for interface creation with custom protocols.
Is there some kind of watchdog script running which aggresively tracks the interfaces and deletes foreign ones for some reason due to how vpn software is implemented?
Edit: i can confirm that creating unmanaged interfaces work and get saved properly, but fails with vxlan.
I did another test by using uci directly, when I restart the vxlan interface to force a ip link up to bypass luci creation, this time on the Beryl 7.
it restarts and becomes a softbrick, this points me to the direction that your packagings are problematic with kernel and userland because they are compiled against totally different toolchains than the toolchain where the firmware is compiled orginally on.
I'm speaking on behalf of the main_dir/toolchain part with different musl and other tools.
This is like a interpreter trying to make a int of a endian... but a endian is reversed and this is why it won't work with different tooling and different sdks, MTK SDK should have packages on the MTK sdk, QSDK should have packages compiled on the QSDK, and OP24 on the OpenWrt toolchain.
Then packages will not failure with segfaults or strange bugs and issues
I mean in a extreme example you made packages on QSDK OpenWrt 15.5 and try to use it on OpenWrt 21 although the whole toolchain is ignored with high chance of issues.
