Upgraded from 4.7.5-op24.
Kept settings
Came up ok - showed internet connected but no client had internet access.
I rebooted it.
Came up ok but same issue - no internet.
Rolled back to 4.7.5-op24 - all working ok.
Where to look for 4.7.5? Seems gone from download
Same issue on GL-MT3000...
The problem is on the VPN. If it's ON, the internet doesn't work.
It seems they don't test absolutely nothing before releasing a firmware.
They should never release a new firmware on Fridays... Now we need to wait until next week.
It looks for me like a major update due to the dashboard, I wonder if it also have these issues without the kept settings ?
I suspect the old wireguard config becomes incompatible.
Yes I think so, although 4.8.0 did not work for me even when WG VPN was disabled.
I might wait a few days and try again with fresh settings.
EDIT:
4.7.5 failed to work with VPN after rollback.
I had to reflash Saved Settings to get VPN going again as before.
I'm going to reinstall 4.8.0 and then flash the saved settings from 4.7.5 and see if that helps.
Edit:
No, didn't work. Back on 4.7.5
Has wifi been fixed on this firmware or does it still use MTK driver?
The OP24 firmware uses the Open Source drivers, not the MTK.
I've used 4.7.5-op24 for 2 months without wifi issues.
Have you tried a completely fresh install without restoring the old config?
They should release a major update changing the firmware number to 5.x
x.yy.zzz
x = major update
yy = minor update
zzz = bug fixes / patches
1 Like
Thanks - good to know. Does it use the GL-Inet interface?
That would be a better idea yeah.
Actually I'm more fan of how c# properties do it, 4 octals with max 3 numbers that is enough room to bump very small versions, and big ones.
But I'm confident the vpn change is a bigger change, besides that the issue may also relates to this issue dnsmasq: fix path to default dnsmasq confdir by stangri · Pull Request #16806 · openwrt/openwrt · GitHub the PR is dated, but the issue can still be recent.
I guess they ported the gl sdk from mtk sdk where this change doesn't exist, and also not on the older op24.
On a other topic I saw you posted a log, I wonder if that file even exist with the dnsmasq.d/mark 
likely if it is related it can be fixed temporary.
Either you can do:
uci set dhcp.@dnsmasq[0].confdir="/tmp/dnsmasq.d"
uci commit dhcp
/etc/init.d/dnsmasq restart
That returns the old behaviour but can break with new updates or packages with workarounds.
Or you can browse /tmp and check if there is a similar structure path as what the error shows probably in /tmp/dnsmasq.cfgxxxx.d/mark.
Then you could make a symbolic link:
ln -s /tmp/dnsmasq.wireguard/mark /tmp/dnsmasq.cfgxxxx/mark
Unfortunately i don't use this firmware but that is maybe a workaround.
xxxx is a random string by uci per dnsmasq instance, often 0 is always the same randomized string.
Please check the paths from your logs to be accurate, in my posts they may not be accurate for symlink👍
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.