I don’t have the ‘Accept Preview Plan’ option available.
That confirms the Accept Preview Plan control is not exposed on your Flint 4’s current firmware, so there is nothing you can enable from that page. The earlier instruction about enabling the switch does not apply to this build.
To install beta 3, download the official GL-BE14000 image from the GL.iNet Download Center and use System → Upgrade → Local Upgrade. Given the upgrade and configuration-retention reports in this thread, keep the LuCI backup but also record your DHCP reservations separately; restoring a 4.9.2 backup onto 4.11 may introduce incompatible settings.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Is it possible to only restore aspects of the config? For example, the reserved IP address config?
LuCI’s restore function restores the whole archive; it does not offer a supported GUI option to restore only selected settings. For a clean move from 4.9.2 to 4.11, do not restore the complete backup or overwrite the new /etc/config/dhcp.
Instead, extract the backup archive on your computer and inspect etc/config/dhcp. The reserved addresses are normally stored as config host sections containing the device name, MAC address, and IP address. Use those entries as a reference and recreate the reservations under LuCI → Network → DHCP and DNS → Static Leases after upgrading. This preserves 4.11’s new defaults while carrying over only the information you need. Keep the archive private because it may contain sensitive network details.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
I have the Flint4 with 2 VLANS. 1 and 15 for IOT but I can not manual change the IP Adress to fixed IP adress for the VLAN15 the DHCP is only able to change the VLAN1 DHCP settings. Is there a way to change this behavior ?
The GL.iNet Admin Panel currently supports address reservations only for the Main Network, not the IoT or other VLAN networks. For VLAN 15, configure the reservation through System → Advanced Settings → LuCI → Network → DHCP and DNS → Static Leases.
Add the device’s MAC address and an IPv4 address belonging to the VLAN 15 subnet, preferably outside its dynamic DHCP pool, then select Save & Apply. Reconnect the device or renew its DHCP lease afterward. If the device uses a randomized/private MAC address, disable that feature for this network or reserve the randomized MAC actually shown by the router.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
This does not work it still uses diffrent ips. this way the vlan feature is not usable
A static lease should work on VLAN 15 through LuCI, so receiving a different address means either the reservation does not match the client’s active MAC address or the firmware is not applying it correctly. Please first confirm that the MAC shown for the connected VLAN 15 client exactly matches the reserved MAC; phones and computers may use a private/randomized MAC per network. Then disconnect the client, delete its existing lease or reboot it, and reconnect so it performs a new DHCP request.
If it still receives another address, please provide the exact firmware version/build and a redacted screenshot of that single LuCI static-lease entry. Do not post the full DHCP configuration or other clients’ MAC addresses. This will determine whether the entry is malformed or whether this is a firmware-specific DHCP issue rather than expected VLAN behavior.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
Since beta 3 honors the five-minute lease time but ignores the reserved address despite the correct MAC, this is not expected DHCP behavior. The next check is whether LuCI saved the VLAN association for that static lease.
If this was the most recently created static lease, run the following by SSH and share the output after redacting most of the MAC address:
uci show dhcp.@host[-1]
Also state the logical interface name shown for VLAN 15 under LuCI → Network → Interfaces. If the host entry lacks an option network association, it can be bound explicitly to that interface; if the association and reserved IP are already correct, this points to a firmware-specific DHCP issue in 4.11 beta 3 rather than another client-side lease problem.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
dhcp.cfg29fe63=host
dhcp.cfg29fe63.mac='80:64:6F:53:81:D8'
dhcp.cfg29fe63.ip='192.168.5.158'
dhcp.cfg29fe63.leasetime='5m'
interface name iot. interface br-iot
The lease entry is missing its VLAN/network association. Bind it to the logical iot interface, then restart DHCP:
uci set dhcp.cfg29fe63.network='iot'
uci commit dhcp
/etc/init.d/dnsmasq restart
Ensure 192.168.5.158 belongs to the IoT subnet and is not already in use, then disconnect and reconnect the client to force a new DHCP request. If it still receives another address, share the new address and the output of uci show dhcp.cfg29fe63; that would indicate beta 3 is ignoring a correctly bound reservation. Please also edit the earlier post to redact most of the publicly displayed MAC address.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
I did a ‘dirty’ upgrade from v4.9.2 to v4.11 Beta 3 last night and it seems to be working nominally.
In case it’s useful, I use an FS.com 1Gb/s SFP BiDi module for my broadband, with a VLAN 100. Tailscale, a single Surfshark VPN client profile, AdGuard Home, IPv6, no-ip DDNS, and GL-iNet Utils. I don’t use the WiFi capability onboard.
The only issue I’ve seen, so far, is the zram swap functionality in the GL-iNet Utils doesn’t enable. It’s a known issue on this beta however.
I just installed v4.11 Beta 3, and it seems to work fine. I encountered only one bug: the connected SSD doesn't work properly. I found a workaround: switching the USB protocol to 2.0 and then back to 3.0 makes it work. However, I have to do this every time I reboot the router. Please address this.
The USB 2.0 → 3.0 toggle reinitializes the USB controller, so this points to a USB 3 initialization problem after boot rather than an SSD filesystem issue. On the next reboot, before applying the workaround, please run:
dmesg | grep -iE 'usb|uas|scsi|sd[a-z]|reset|error|fail' | tail -n 100
block info
Please share that output and the SSD/enclosure model, after removing any serial number shown. Also confirm whether the SSD is bus-powered. Testing once with the original Flint 4 power adapter and, if available, a powered USB hub will distinguish a beta 3 initialization issue from insufficient startup power.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
For the AI Bot……..
Yep that worked and I can login as user.
However this command
git clone https://github.com/jasonacox/Powerwall-Dashboard.git
Does not work and I get this response -
fatal: could not create work tree dir 'Powerwall-Dashboard': Permission denied
So what is the next step?
Thanks AI bot.
Good afternoon. I have a problem: I’m creating three Wi‑Fi networks. The first one is called the guest network, the second one is called “for everyone,” and the third one is called VPN. I need to send all traffic to the VPN network; users can only access the guest network without a VPN; and for the “for everyone” network, I need to set up routing for users based on a list of domains. I can’t figure out how to do all these settings in the GUI interface.
The permission error likely means that /home/powerwall does not exist or is not writable by powerwall. Please log in as root and run:
mkdir -p /home/powerwall
chown powerwall /home/powerwall
Then log in again as powerwall, explicitly change to the home directory, and retry:
cd /home/powerwall
git clone https://github.com/jasonacox/Powerwall-Dashboard.git
The OpenWrt guide covers creating a user's home directory and assigning its ownership:
Important: Powerwall-Dashboard is a third-party installation, so support is best effort.
BTW, we have disabled automatic AI Bot replies. If you still want to use the bot, please send it a private message.
I have a coupe of strange things in the Flint 4 MESH - Main and Flint 4 Node (Version 4.11.0 Firmware beta 3) that I do not understand.
I went back to year zero an did a firmware reset and went as far as reloading the beta 3 firmware.
I have now reconfigured it from scratch i.e. did not reload a saved setting file….
I also have MESH configured via the 10gig ethernet for the MESH backhaul to the second FLINT 4.
This all (seems) to work fine, but I cannot see the NODE Flint in the Clients section of the main router as I could with the previous Beta load I had. Under the MESH Menu I can see the node FLint and it does have an IP address (192.168.102) and I can log into the NODE OK on that IP address. What is going on there? Why is the NODE not showing as a client?
Update - deleted the bit about the TV
So am I missing a setting somewhere? What is going on here?
Hi @will.qiu
after installing the latest beta firmware 4.11 on my Flint 4, I noticed an unusually high number of system log entries.
Within a short period, the router generated almost 7,000 log entries (over 1 MB), most of them originating from the MediaTek MT7990 Wi-Fi driver (P4_DIAG, NOTICE.MLME, NOTICE.SEC, etc.).
The router seems to be working normally, but the excessive diagnostic logging makes it difficult to identify relevant system events.
Is this level of logging intentional, and are there plans to reduce it in a future firmware release?
Thanks!
BE14000_system.log (1.0 MB)