Flint 2 (GL-MT6000 ) - bug reports - collective thread

admon · March 4, 2024, 6:13am

Just don’t upgrade then. Mostly you can keep all settings - but this highly depends on what you’ve done.

Just from my point of view there is no need for more feedback since the main bugs aren’t fixed yet.

bonefire · March 4, 2024, 6:31am

I was wondering: What is the maximum speed you are gettting when using WiFi + wireguard? Is the promoted 900Mbits only via ethernet?

Anaron · March 4, 2024, 6:33am

If you turn on Keep Settings before upgrading, then it should retain your settings. Personally, I wouldn’t risk going from any current stable version to the beta. I was briefly tempted to try the latest beta and I’m glad I didn’t go through with it.

admon · March 4, 2024, 6:40am

Shouldn’t matter. As long as Wi-Fi is doing it’s job perfectly fine.

bonez · March 4, 2024, 6:44am

Thank you (and @admon) for your responses. I shall leave it alone

japa182 · March 4, 2024, 11:26am

Hello, to everyone who is having a pppoe problem, I kindly ask you to follow the steps below, as it resolved the issue of fullconenat and also of dns in quic in adguard.

I found the problem related to pppoe, here’s how I fixed it.

I was getting this error “DHCP packet received on eth1 which has no address”

this is the fix

echo "except-interface=eth1" >> /etc/dnsmasq.conf
service dnsmasq restart

After that, update the fullconenat file to the data below.

#!/bin/sh /etc/rc.common

START=99

set_rules() {
    iptables -t nat -I POSTROUTING -o $1 -j FULLCONENAT 2>/dev/null
    iptables -t nat -I PREROUTING  -i $1 -j FULLCONENAT 2>/dev/null
}

clear_rules() {
    local ifaces=$(iptables -t nat -nvL POSTROUTING|grep FULLCONENAT|awk -F' ' '{print $7}')
    for item in $ifaces; do
        iptables -t nat -D POSTROUTING -o $item -j FULLCONENAT 2>/dev/null
        iptables -t nat -D PREROUTING  -i $item -j FULLCONENAT 2>/dev/null
    done
}

find_wan_gw()
{
    local wan_list=$(ubus list|grep interface.|grep -v -E 'lan|loopback|4|6')
    for item in $wan_list; do
        local ubus_data=$(ubus call $item status)
        local up="$(echo $ubus_data|jsonfilter -e '@.up')"
        [ "$up" = "true" ] || continue

        local gw="$(echo $ubus_data|jsonfilter -e '@.l3_device')"
        [ -n "$gw" ] && set_rules $gw
    done
}

stop() {
    clear_rules
}

start() {
    if [ "$(uci get fullconenat.global.enable)" = "1" ]; then
        local ifaces=$(iptables -t nat -nvL POSTROUTING|grep FULLCONENAT|awk -F' ' '{print $7}')
        [ -z "$ifaces" ] && find_wan_gw
    fi
}

located at /etc/init.d/fullconenat

After that everything works perfectly.

Follow the correction link.

another fix is regarding dns in quic in Adguard, to be able to use it you have to place the commands below in /etc/sysctl.d/10-default.conf and/or /etc/sysctl.conf

Below are the corrections.

Mon Mar 4 08:46:52 2024 user.notice AdGuardHome[21936]: 2024/03/04 11:46:52.756130 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size for details.

net.core.rmem_max=2500000
net.core.wmem_max=2500000

Dondi · March 4, 2024, 11:47am

I hope GL.iNet is taking on these fixes. It is also a big configuration management challenge for GL.iNet to try to maintain (and backport to) their old OpenWRT 21.02 software base. This is long-term bad for us as users, but also creates challenges for them in software maintenance.

xize11 · March 4, 2024, 11:49am

That is a interesting setting , currently i got a different issue with my dumbap, but in my case goes wild in ACKing dhcp, maybe that exclude it, because dhcp should not be served on wan for me from out dnsmasq.

Dondi · March 4, 2024, 11:53am

@admon it actually does matter. The air interface has a lot of overhead, plus most devices even those supporting WIFI 6 are only 1 or 2 streams. So yeah, the max speed was tested by GL.iNet over Ethernet not using WIFI.

admon · March 4, 2024, 12:07pm

Yeah but not really because Wi-Fi will not slow down WireGuard. If your Wi-Fi can do >900 Mbps WireGuard will do 900 Mbps.

Mostly Wi-Fi 6 will be >900 Mbps.

japa182 · March 4, 2024, 1:16pm

Just let us know, the gl team removed the mt6000 firmware snapshot from the website.

Now there are only stable and beta versions… It was something good for me that I always tested and reported bugs for the devs to resolve… let’s see what will happen from now on.

japa182 · March 4, 2024, 2:38pm

Did this solve your problem?

admon · March 4, 2024, 2:58pm

Hopefully there will be finally some peace in this thread until the old bugs are fixed

xize11 · March 4, 2024, 3:00pm

unfortunately its still dhcp discovering for me in a spammy way.

on my backbone which run a MT6000 on a OpenWrt snapshot I see this in the logs:

Mon Mar  4 14:54:32 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan.52) <dumbap mac>
Mon Mar  4 14:54:32 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan.52) 10.33.77.130 <dumbap mac>
Mon Mar  4 14:54:38 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan.52) <dumbap mac>
Mon Mar  4 14:54:38 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan.52) 10.33.77.130 <dumbap mac>
Mon Mar  4 14:54:38 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan.52) <dumbap mac>
Mon Mar  4 14:54:38 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan.52) 10.33.77.130 <dumbap mac>

but I still need to observe this more wether it is a miss configuration or something else

because I also see banip doing something with it.

heres my network config:


config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd3c:d48b:2c1c::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'lan5'

config device
	option name 'lan1'

config device
	option name 'lan2'

config device
	option name 'lan3'

config device
	option name 'lan4'

config device
	option name 'lan5'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.8.1'
	option netmask '255.255.255.0'
	option isolate '0'
	option delegate '0'
	option ip4table 'main'

config device
	option name 'eth1'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'
	option ipv6 '0'
	option metric '10'
	option force_link '1'
	option delegate '0'

config rule 'policy_direct_rt'
	option lookup 'main'
	option suppress_prefixlength '0'
	option priority '1100'

config rule 'policy_default_rt_vpn'
	option mark '0x8000/0xc000'
	option lookup '8000'
	option priority '1101'
	option invert '1'

config rule6 'policy_direct_rt6'
	option lookup 'main'
	option suppress_prefixlength '0'
	option priority '1100'

config rule6 'policy_default_rt_vpn6'
	option mark '0x8000/0xc000'
	option lookup '8000'
	option priority '1101'
	option invert '1'

config device
	option type 'bridge'
	option name 'br-wlan0'
	option bridge_empty '1'
	option ipv6 '0'
	list ports 'eth1.50'

config interface 'wlan0'
	option device 'br-wlan0'
	option proto 'dhcp'
	option delegate '0'
	option force_link '1'
	option defaultroute '0'

config device
	option type 'bridge'
	option name 'br-wlan1'
	option bridge_empty '1'
	option ipv6 '0'
	list ports 'eth1.51'

config interface 'wlan1'
	option device 'br-wlan1'
	option proto 'dhcp'
	option delegate '0'
	option force_link '1'
	option defaultroute '0'

config device
	option type 'bridge'
	option name 'br-zigbee'
	option bridge_empty '1'
	option ipv6 '0'
	list ports 'eth1.52'

config interface 'zigbee'
	option device 'br-zigbee'
	option proto 'dhcp'
	option delegate '0'
	option force_link '1'
	option defaultroute '0'

config interface 'modem_1_1_2_6'
	option proto 'dhcpv6'
	option disabled '1'
	option device '@modem_1_1_2'
	option reqprefix 'auto'
	option reqaddress 'try'
	option defaultroute '0'
	option ifname '@modem_1_1_2'

config interface 'tethering6'
	option proto 'dhcpv6'
	option disabled '1'
	option device '@tethering'

config interface 'wwan6'
	option proto 'dhcpv6'
	option disabled '1'
	option device '@wwan'

config rule 'policy_default_rt_vpn_ts'
	option lookup 'main'
	option priority '1099'
	option mark '0x80000/0xc0000'
	option invert '0'

the mac address options are removed by me.

Steve68 · March 4, 2024, 3:32pm

Yes, I’m running AdGuard, OpenVPN server (also WireGuard sometimes) SMB, reserved IPs, some custom settings on AdGuard and a few more things. Working without issues

Steve68 · March 4, 2024, 3:33pm

No, the Beta version I’m using is the one released on February 28th, I think I’ll upgrade but this one is working good for me.
I just saw that new one 3/1/24

Steve68 · March 4, 2024, 4:51pm

Would be nice to have the changelog on that new beta @alex_zheng

bonefire · March 4, 2024, 7:40pm

I did some speed tests with an AX210 WiFi card and indeed wireguard influences the WiFi transfer speed negatively.

Test	iperf3 speed result
WiFi, testing a local iperf3 server	[SUM] 0.00-10.02 sec 1.04 GBytes 889 Mbits/sec sender [SUM] 0.00-10.00 sec 1.02 GBytes 876 Mbits/sec receiver
WiFi, testing a remote server (ping.online.net) via wireguard	[SUM] 0.00-10.04 sec 480 MBytes 401 Mbits/sec sender [SUM] 0.00-10.00 sec 452 MBytes 379 Mbits/sec receiver
LAN cable connected, testing a remote server (ping.online.net) via wireguard	[SUM] 0.00-10.04 sec 910 MBytes 760 Mbits/sec sender [SUM] 0.00-10.01 sec 876 MBytes 734 Mbits/sec receiver
Commands:	iperf3 -c ping.online.net -p 5200 -R -P 10 and iperf3 -c 10.71.xxx.xxx -p 5900 -R -P 10 for the local server

Version: 4.5.7 release 1, 160 MHZ, 5GHz, free channel, same reduction on 80 MHz, full signal, 0,5 m away from the router

I’m not sure why this is happening, the CPU cores are never overloaded, the load maximum of around 2.9

Edit:

Here some speedtest.net results:

Via LAN cable

via WiFI (160MHZ, full signal, 0,5m away from the router)

Its interesting that the software acceleration is faster than the hardware acceleration on both LAN & WiFi.

Can someone confirm these values?

ygorsoares · March 4, 2024, 9:53pm

Would it be possible for each beta release available to point out what was changed/improved so that we can focus on what to observe?
Currently the releases are simply released without any information!

Without a release note, it’s difficult to know what to look at and understand the improved points!

The newest release available, 4.5.7 - 2024-03-01 (openwrt-mt6000-4.5.7-0301-1709277553.bin), has a problem with the PPOE connection. I use two links, WAN1 PPOE and WAN2 DHCP, the link via PPOE simply does not stabilize in any way, it stays in a loop trying. I return to the previous view and it returns to normal.

Best regards

alex_zheng · March 5, 2024, 3:02am

V4.5.7 release3–>release4

BUG fix

Fixed the problem of blue screen on some computers after connecting to wifi
Fixed the problem of not connecting the network cable or not being able to access the web management interface during pppoe process
Fixed the issue where WAN port gateway information displays abnormally after setting static routing
Fixed the problem that the WAN port negotiation rate is abnormal when the 2.5G network port is inserted into the 1G port and then the 2.5G network port is inserted.
Fixed the problem of being unable to access the web remotely through wan2 and relay IP
Optimize portal features.

Vulnerability fixes

Fixed a vulnerability related to log download.
Fixed a vulnerability that caused the router to fail to log in if special characters were entered.