my system is a flint2 GL.iNet GL-MT6000. it was running OpenWrt 23.05.4 (r24012-d8dd03c46f), and i discovered i couldn't seem to upgrade any of the packages from within luci. so i decided i had better upgrade to the latest (openwrt-25.12.4-mediatek-filogic-glinet_gl-mt6000-squashfs-sysupgrade.bin) using sysupgrade from ssh.
after the upgrade, the access point seems to be up and running and serving all the various wifi networks i had configured (my laptop reports the correct BSSID for this access point when connecting to the various networks.) however, i can't ping the device, it doesn't seem to have issued a DHCP request to my router, and i can't ssh or log in with a web browser.
so the thing is not completely bricked, but something is very wrong. how do i proceed with troubleshooting this? thanks.
Keeping settings from 23.05 -> 25.12 is not supported. It is possible that there are some syntax changes in the configs that could be causing your issues.
You'll most likely need to reset to defaults using failsafe mode and then configure again from scratch. In most cases, this is pretty easy and quick. Hopefully you have a backup of your previous config -- use this only as a human readable reference as you reconfigure (do not attempt to restore this file).
thanks for the reply. yes i made a .tar.tz file from the shell using sysconfig and copied it to my desktop and also i used the web interface to download the settings. not sure if those two things are equivalent.
what's strange is that i upgraded two beryl routers from 23.05 to 25.12.3 (with substantially the same configurations as the flint2) immediately before trying the flint2, and the beryls worked fine.
is there any way to get to the console of the flint2, perhaps with USB-serial? it would be interesting to see what is going on before nuke&pave.
edit: also i have another flint2 which needs to be upgraded. is there a stepwise process, perhaps upgrading to 24.x first, which will let me preserve the settings? thanks.
They are the same.
There may have been one or more differences that are 'haunting' you in this particular situation.
Yes, you could theoretically open the device and connect to the serial port.
That said, since you have the backup -- expand archive file... inside, you'll find all of the config files. Of interest are the ones below:
Post the file contents here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
/etc/config/network
/etc/config/wireless
/etc/config/dhcp
/etc/config/firewall
ok thanks - here are the redacted files you asked for:
/etc/config/network:
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 'ffff:ffff:ffff::/48'
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'
option macaddr 'mac:addr:1'
config device
option name 'lan2'
option macaddr 'mac:addr:1'
config device
option name 'lan3'
option macaddr 'mac:addr:1'
config device
option name 'lan4'
option macaddr 'mac:addr:1'
config device
option name 'lan5'
option macaddr 'mac:addr:1'
config interface 'lan'
option device 'br-lan.100'
option proto 'dhcp'
config device
option name 'eth1'
option macaddr 'mac:addr:2'
config bridge-vlan
option device 'br-lan'
option vlan '100'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'
list ports 'lan5:u*'
config bridge-vlan
option device 'br-lan'
option vlan '1003'
list ports 'lan1:t'
list ports 'lan2:t'
list ports 'lan3:t'
list ports 'lan4:t'
list ports 'lan5:t'
config bridge-vlan
option device 'br-lan'
option vlan '1010'
list ports 'lan1:t'
list ports 'lan2:t'
list ports 'lan3:t'
list ports 'lan4:t'
list ports 'lan5:t'
config bridge-vlan
option device 'br-lan'
option vlan '1020'
list ports 'lan1:t'
list ports 'lan2:t'
list ports 'lan3:t'
list ports 'lan4:t'
list ports 'lan5:t'
config interface 'v1003_iot'
option proto 'dhcp'
option device 'br-lan.1003'
config interface 'v1010_hk'
option proto 'dhcp'
option device 'br-lan.1010'
config interface 'v1020_guest'
option proto 'dhcp'
option device 'br-lan.1020'
/etc/config/wireless:
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/18000000.wifi'
option channel '1'
option band '2g'
option htmode 'HT20'
option country 'US'
option cell_density '0'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/18000000.wifi+1'
option channel '36'
option band '5g'
option htmode 'HE40'
option country 'US'
option cell_density '0'
config wifi-iface 'wifinet0'
option device 'radio0'
option mode 'ap'
option ssid 'SSID_iot'
option encryption 'psk2'
option key ''
option network 'v1003_iot'
config wifi-iface 'wifinet1'
option device 'radio0'
option mode 'ap'
option ssid 'SSID'
option encryption 'psk2'
option key ''
option network 'v1010_hk'
config wifi-iface 'wifinet2'
option device 'radio1'
option mode 'ap'
option ssid 'SSID_guest'
option encryption 'sae'
option key ''
option network 'v1020_guest'
option ieee80211r '1'
option mobility_domain 'fade'
option ft_over_ds '0'
config wifi-iface 'wifinet3'
option device 'radio1'
option mode 'ap'
option ssid 'SSID2'
option encryption 'sae'
option key ''
option network 'lan'
option ieee80211r '1'
option mobility_domain 'beef'
option ft_over_ds '0'
option reassociation_deadline '4096'
/etc/config/dhcp:
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option cachesize '1000'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option ednspacket_max '1232'
option filter_aaaa '0'
option filter_a '0'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option dhcpv6 'hybrid'
option ra 'hybrid'
list ra_flags 'managed-config'
list ra_flags 'other-config'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
/etc/config/firewall:
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
these machines are just access points inside the lan, they are not connected to the WAN.
The firewall has become re-enabled and your management network is not explicitly specified for allowing input. This is why I recommend always leaving the firewall enabled and properly specifying the network in a firewall zone that allows input.
ah ok, i guess i just ignored the FW config since it's not a router. it is behaving like a firewall issue because traceroute seems to be working and ping is giving me a destination unreachable reply rather than no reply.
so hopefully if i fix the fw config on the other flint2 this same upgrade will succeed? i guess on this one there's no choice but to nuke and pave unless i want to open it up and hook up the serial port.
You can fix the issue by using failsafe. Once booted into failsafe and connected to the router via ssh, perform mount_root and then edit the /etc/config/firewall file to include a zone like this:
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
Replace the lan network above with the management network.
Meanwhile, you can also make the non-management network unmanaged by changing the proto to none -- this is desired because it helps secure your AP from the other (non-management) networks and untrusted devices.
nice, ok i will give that a try. just have to dig the router out from behind the TV to work on it. i'll check in when i get the chance to do that. thanks again.
so it's strange, i think i entered failsafe mode properly - the only weirdness is that lan2-lan5 must be bridged together and the FW is only listening on that interface. no response at wan and wan/lan1. maybe that's normal.
i can see the firmware upgrade banner at http://192.168.1.1 but there's no response on port 22 and nmap thinks only port 80 is open.
i followed the directions here: https://docs.gl-inet.com/router/en/4/faq/debrick/ for the flint2. i got 5 slow blinks of the blue light followed by the white light.
Make sure that you:
- Unplug this device from the upstream network.
- Connect a cable between one of the lan ports and your computer
- disconnect any other network cables from both the computer and the router.
- turn off wifi on your computer.
- manually configure the IP address on the computer.
- use ssh to connect to the router (username
root and no password).
If port 80 is open, you're either connecting to an unexpected device or you have not entererd failsafe properly. Do not follow the gl-inet guide. Use the one I posed here:
ok, i was not in failsafe mode per your link. i guess i was in "upload new firmware" mode if that has a name. hopefully i didnt erase the configuration by doing this.
should the device respond to pings in failsafe mode? no matter what port i connect to i get nothing, but the LED is in fast blink mode, so i assume i'm now properly in failsafe mode.
@joeblough
I could be mistaken, but isn't the OEM firmware is based on 23.05.4?
Did you flash 23.05.4 mainstream OpenWrt yourself?
I have found that failsafe mode did not seem to work properly, although factory reset does.
BUT, the uboot-webui provided is totally reliable for reflashing even if you think it is bricked by something you did wrong.
Now I rarely use anything else.
For the mt6000, always use the sysupgrade flash, no matter how you do it.
For details see uboot-webui
the device was already running openwrt - i had converted 2 flints and 2 beryls to openwrt a few years ago. at that time 23.05.4 must have been the lastest.
i logged into all 4 of my access points yesterday and found that although i could update the packages, i could not apply any updates. then i discovered i was 2 major versions behind so i decided i had better get up to date.
i sshd into one of the beryls and used sysupgrade to apply openwrt-25.12.3-mediatek-filogic-glinet_gl-mt3000-squashfs-sysupgrade.bin and that went fine, so i repeated that process on the other beryl and it also went fine.
this morning i downloaded openwrt-25.12.4-mediatek-filogic-glinet_gl-mt6000-squashfs-sysupgrade.bin for the flint2 and used the sysupgrade command to apply that firmware, and then there was no response from the flint2. i think @psherman is correct that the firewall is enabled because the device seems to be operating properly, i just can't talk to it.
so anyway it seems i have entered the uboot-webui on this one flint2 by using a wrong key sequence, so maybe i've already accidentally erased it. i am just trying to avoid having to reconfigure the device as there are a lot of VLANs and SSIDs and getting all the bridging right was a PITA as i recall. but since i have all those config files backed up, maybe i can just use them (with the exception of the firewall config). i need to reboot this thing in normal mode and see if it's still creating all of my networks.
Do you mean you flashed it yourself when you got it, or do you mean it was declaring itself as 23.05.4 when it was brand new?
You cannot enter the uboot-webui using a key sequence.
The instructions are in the link in my previous post.
Really, it will be much safer/reliable to just reflash with the 25.12.4 sysupgrade with the uboot-webui, check it now works, then from a good starting point, set up all the vlans etc. etc. you need.
Do not restore your config backups, instead use them as a guide for what you want to achieve (I think @psherman already mentioned this)
yes, i installed openwrt myself.
well i did something that caused this - i held down reset while applying power until the flashing sequence stopped. 100% sure i was looking at the uboot-webui banner.
understood but assuming all that went wrong was the firewall config was bad, it seems that this might work. if it doesn't all i have to do is start over again so i don't see the harm in trying. there was something really difficult about my configuration that i can't remember now, but i remember struggling a lot to get it working. i don't have faith that i can restore it from scratch.
So far so good!
Yes, that is correct - but it is not a key sequence!
Absolutely. But there is always the possibility that time taken trying could dramatically escalate (don't ask my how I know 
Thinks: seemed like a good idea at the time...)
Post the backup file contents here, @psherman is an ace at figuring out stuff like that (says this trying to dodge a bullet 
).
sorry, bad phrasing on my part. button sequence maybe.
i just had an idea - i have another flint2 sitting in the box that i intend to install at a relative's house. so i can make-before-break with this - i can flash that one with the latest openwrt and then try setting that one up from scratch with my configuration files as a reference and see if i can get it working. since the current one is working right but inaccessible, i'd hate to erase it and then take a week or something to get it back up and running.
Excellent idea.
I would recommend flashing using the uboot-webui method ( using the sysupgrade image ), that way you make sure everything is clean before you start with no prospect of anything being carried over inadvertently. On top of that the whole process of getting where you want to be will be a really good learning process.
If you mess up at any point, you will often find a quick uboot-webui reflash back to clean is often the quickest way to iterate, particularly if you make notes as you go.
The spare Flint2 is the safest path. I’d build the new one from clean 25.12.4 in small commits: first one plain management VLAN/SSID that you can always reach, then firewall zone with input ACCEPT for that management network, then add the remaining VLANs/SSIDs one at a time. Keep the old backup open only as a reference and write down which physical port is your recovery/management port. That way if a later VLAN/firewall change cuts you off, you know exactly which last change did it.