I’m currently running 4.5.6 release 1, if I were to flash 4.5.7 beta (2023-03-01), will I lose any settings or customisations that I’ve done?
Eg. I’ve set up Unbound for recursive DNS and had to get some custom config working for Dynamic DNS and I don’t want to lose any of that, but I’d like to test the beta version and give feedback.
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.
I was wondering: What is the maximum speed you are gettting when using WiFi + wireguard? Is the promoted 900Mbits only via ethernet?
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.
Shouldn’t matter. As long as Wi-Fi is doing it’s job perfectly fine.
Thank you (and @admon) for your responses. I shall leave it alone 
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
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.
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.
@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.
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.
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.
Did this solve your problem?
Hopefully there will be finally some peace in this thread until the old bugs are fixed 
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.
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
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
Would be nice to have the changelog on that new beta @alex_zheng
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?
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
