They should try to improve their release notes to something like this…
Using the proprietary MediaTek WiFi driver
The MediaTek WiFi driver requires us to use OpenWrt 21.02 instead of OpenWrt 23.05
Various packages will be downgraded
When installing this firmware please don’t keep your settings, since OpenWrt 21.02 won’t understand all of the settings from OpenWrt 23.05 and this has the potential to cause issues.
@alex_zheng The snapshot builds always seem to lack some patches, so what works in a stable or beta build might not work correctly in a snapshot or vice versa. For example, in the stable and beta firmwares if you open up /etc/hotplug.d/wireguard/ifup.sh you’ll find this:
Code
# endpoint dependency
if [ "${nohostroute}" != "1" ]; then
wg show "${interface}" endpoints | \
sed -E 's/\[?([0-9.:a-f]+)\]?:([0-9]+)/\1 \2/' | \
while IFS=$'\t ' read -r key address port; do
[ -n "${port}" ] || continue
echo "${address}" >/tmp/run/wg_resolved_ip
done
fi
uci set firewall.block_dns.enabled='0'
uci commit firewall
proto_send_update "$interface"
if [ ${proxy_mode} = "0" -o ${proxy_mode} = "3" -o ${proxy_mode} = "4" -o ${proxy_mode} = "5" ]; then
[ -n "$dns" ] && {
echo resolv-file=/tmp/resolv.conf.d/resolv.conf.wg > /tmp/dnsmasq.d/resolv.vpn
create_restart_service /etc/init.d/dnsmasq
}
else
[ -f "/tmp/dnsmasq.d/resolv.vpn" ] && {
rm /tmp/dnsmasq.d/resolv.vpn
create_restart_service /etc/init.d/dnsmasq
}
fi
/etc/wireguard/scripts/wgclient-route-update.sh "${interface}" ${proxy_mode}
But if you open up the same file from a snapshot then you’ll find this:
Code
# endpoint dependency
if [ "${nohostroute}" != "1" ]; then
wg show "${interface}" endpoints | \
sed -E 's/\[?([0-9.:a-f]+)\]?:([0-9]+)/\1 \2/' | \
while IFS=$'\t ' read -r key address port; do
[ -n "${port}" ] || continue
echo "${address}" >/tmp/run/wg_resolved_ip
done
fi
proto_send_update "$interface"
if [ ${proxy_mode} = "0" -o ${proxy_mode} = "3" -o ${proxy_mode} = "4" -o ${proxy_mode} = "5" ]; then
uci set firewall.dns_vpn.enabled=1
uci set firewall.dns_vpn_guest.enabled=1
uci commit firewall
else
uci set firewall.dns_vpn.enabled=0
uci set firewall.dns_vpn_guest.enabled=0
uci commit firewall
fi
/etc/wireguard/scripts/wgclient-route-update.sh "${interface}" ${proxy_mode}
There’s also some missing OpenVPN changes that mainly seem to handle DNS leak blocking and some firewall rules.
And I don’t know if this was intended, but in the 4.5.7 snapshot you corrected the firewall rule for Adguard Home to “tcp udp”. But in the beta version it’s reverted back to “tcpudp”.
This was all I could find that was useful in the log in 4.5.6 crash of ethernet lans/wans,
Sun Feb 4 09:08:12 2024 user.notice root: mtk-eth halted detected, now reset it...
Sun Feb 4 09:08:12 2024 kern.info kernel: [ 37.328833] mtk_soc_eth 15100000.ethernet eth0: Link is Down
Sun Feb 4 09:08:12 2024 kern.info kernel: [ 37.334582] mtk_soc_eth 15100000.ethernet eth1: Link is Down
Sun Feb 4 09:08:13 2024 kern.info kernel: [ 37.590167] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/2500base-x link mode
Sun Feb 4 09:08:13 2024 kern.info kernel: [ 37.598629] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
Sun Feb 4 09:08:13 2024 kern.info kernel: [ 37.897753] mtk_soc_eth 15100000.ethernet eth1: PHY [mdio-bus:01] driver [RTL8221B-VB-CG 2.5Gbps PHY] (irq=62)
Sun Feb 4 09:08:13 2024 kern.info kernel: [ 37.908081] mtk_soc_eth 15100000.ethernet eth1: configuring for phy/sgmii link mode
Sun Feb 4 09:08:13 2024 daemon.notice netifd: Network device 'eth1' link is down
Sun Feb 4 09:08:13 2024 daemon.notice netifd: Interface 'wan' has link connectivity loss
Sun Feb 4 09:08:13 2024 daemon.notice netifd: wan (4913): udhcpc: received SIGTERM
Sun Feb 4 09:08:13 2024 daemon.notice netifd: wan (4913): udhcpc: unicasting a release of 192.168.12.213 to 192.168.12.1
Sun Feb 4 09:08:13 2024 daemon.notice netifd: wan (4913): udhcpc: sending release
Sun Feb 4 09:08:13 2024 daemon.notice netifd: wan (4913): udhcpc: entering released state
Sun Feb 4 09:08:13 2024 daemon.notice netifd: wan (4913): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Sun Feb 4 09:08:13 2024 daemon.notice netifd: Interface 'wan' is now down
Sun Feb 4 09:08:13 2024 daemon.info avahi-daemon[4678]: Withdrawing address record for 192.168.12.213 on eth1.
Sun Feb 4 09:08:13 2024 daemon.info avahi-daemon[4678]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.12.213.
Sun Feb 4 09:08:13 2024 daemon.info avahi-daemon[4678]: Interface eth1.IPv4 no longer relevant for mDNS.
Sun Feb 4 09:08:13 2024 user.notice firewall: Reloading firewall due to ifdown of wan ()
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.250705 [info] Starting the DNS proxy server
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.250929 [info] Cache TTL override is enabled. Min=2400, Max=86400
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251023 [info] The server is configured to refuse ANY requests
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251081 [info] dnsproxy: cache: enabled, size 67108864 b
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251258 [info] MaxGoroutines is set to 500
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251306 [info] Creating the UDP server socket
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251484 [info] Listening to udp://[::]:3053
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251510 [info] Creating a TCP server socket
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251593 [info] Listening to tcp://[::]:3053
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251740 [info] Entering the UDP listener loop on [::]:3053
Sun Feb 4 09:08:14 2024 user.notice AdGuardHome[6165]: 2024/02/04 17:08:14.251762 [info] Entering the tcp listener loop on [::]:3053
Sun Feb 4 09:08:14 2024 user.notice route_policy: default_policy=0 mac_list=02:42:C0:A8:32:FD 02:42:C0:A8:32:FE
Sun Feb 4 09:08:14 2024 user.notice kmwan: config json str={ "op": 3, "data": { "cells": [ "wan" ] } }
Sun Feb 4 09:08:14 2024 kern.debug kernel: [ 38.923440] kmwan: Delete node:wan
The current openwrt 23.05 is the effect of porting MTK private driver to open source, and since MTK doesn’t maintain it on a continuous basis, there will always be compatibility issues.
Well this is was unexpected and an unpleasant surprise. The beta firmware MT6000 FW 4.5.7(2024-0204) is OpenWrt 21.02-SNAPSHOT r15812+1069-46b6ee7ffc with the Kernel version 5.4.238. I wish they would have given some indication that they were going back a version of OpenWRT from 2021.
I stand corrected, they mentioned it in an above post.
They did, way back earlier in this thread, post 833, so they can use the closed source MTK drivers, reports already coming in that its fixing the wifi issues.
But they still should mention it in the release notes, since you’d have no idea about the downgrade unless you follow this thread. And when you perform downgrades you’re not supposed to keep settings from the newer OpenWrt version.
You’re right to feel the way you do though, because like I said in a previous message…
So of course anyone that wants newer packages or cares about security isn’t going to be happy about the downgrade.
The right approach would be to figure out what change in the MTK driver fixes the issue. Then you’d copy it over to the mt76 driver.
Yes agreed they should put it in the release notes, at least then people would have the choice before flashing it, ive got a funny feeling or read in this thread somewhere its got something to do with Meditek not sharing the current driver info, so as a get by for now, GL inet have used an older driver.
The source code for the MTK driver can be found here. And I assume this is what GL.iNet are using, since many of the changes match and you can see an OpenWrt 21.02 directory within the MTK repository.
If you’re not familiar with the WiFi drivers source code then it could take a while to find the issue, but if the issue were correctly reported to the mt76 repository then Felix or one of the other contributors might suggest a fix.
For that SoC. But the GL-MT6000 uses the mt7986, so it doesn’t apply.
You’ll find changes for the mt7986 within the mt7915 directory, but there’s calls to functions such as is_mt7986 for anything that needs to apply to a specific SoC.
Is it irrelevant whether the upgrade is done via the Gl-inet or owrt interface? obviously the Gl-inet interface is no longer accessible, is it only openwrt pure lights? you can also help me configure interfaces for Wan pppoe user and password thanks to luci
