[GL-MT6000 (Flint 2), Firmware 4.9.0/4.9.1] Windows Creates a New Inactive LAN Profile After Each Router Reboot over Ethernet

softhive · August 8, 2026, 5:32pm

I’ve found an annoying bug in both mt6000-4.9.0_release1-1015-0605-1780626850 and mt6000-4.9.1_release1-1079-0804-1785826264 stable firmware.

Every time I reboot my router through the web interface or by power-cycling it, Windows creates a new inactive LAN network profile leaving a mess.

The bug seems to occur only when the router is connected via Ethernet cable; I haven’t observed it when connected over Wi-Fi.

To see the mess of inactive profiles, go to Setup→Network→Network Connections in ESET Endpoint Antivirus v13.0.2044 for example.

gfondeur · August 8, 2026, 10:21pm

Question, any of those build are op24 or op25?
Just asking

softhive · August 10, 2026, 7:42am

Maybe someone could test Op24/Op25 to see if they have the same issue. The bug mentioned above was found in the latest stable releases.

gfondeur · August 10, 2026, 10:42am

Still believe you on the wrong thread but alright mate.....

will.qiu · August 11, 2026, 3:13am

Hi,

Since this issue does not appear to be strongly related to the OP firmware, we have split it into a separate thread for further investigation.

We tested locally with MT6000 v4.9.0/v4.9.1, but were unable to reproduce the issue.

Whether rebooting the router through the Web interface or by power cycling it, Windows did not create any new inactive network profiles.

function Get-InactiveProfileCount {
    $nlm = [Activator]::CreateInstance(
        [type]::GetTypeFromCLSID(
            [guid]'DCB00C01-570F-4A9B-8D69-199FDBA5723B'
        )
    )

    @($nlm.GetNetworks(2)).Count
}

$before = Get-InactiveProfileCount
"Before reboot: $before"
# Reboot the Router
$after = Get-InactiveProfileCount
"After reboot:  $after"
"Difference:    $($after - $before)"

Could you please clarify:

Does this issue only affect a specific Windows device, or does it happen on all Windows devices?
Normally, Windows creates a new network profile based on the router's MAC address of the connected network. Therefore, please check whether the MT6000's LAN MAC address changes before and after reboot.

You can SSH into the router and run the following command to check:
```
ip -br link show br-lan
```
If you confirm that the MT6000 LAN MAC address changes after reboot, please note that we should do not have any feature to randomize the LAN MAC address. In this case, please check whether any third-party plugins are installed that may cause this behavior.

You can also try resetting the device to factory defaults and only configuring the settings required for internet access, then check whether the issue still occurs.

softhive · August 11, 2026, 7:11am

flint2_bug1.zip (2.5 MB)

Thank you Will for your answer.

“Does this issue only affect a specific Windows device, or does it happen on all Windows devices?”
It affects all Windows devices connected to the Flint 2 via UTP cable.

”ip -br link show br-lan”
I haven’t seen any MAC address changes before or after rebooting. I also don’t use any third-party plugins.

”You can also try resetting the device to factory defaults and only configuring the settings required for internet access, then check whether the issue still occurs.”
I’m using a clean installation of mt6000-4.9.1_release1-1079-0804-1785826264 with a factory reset.
I’d also like to provide you with a real-time video showing how to reproduce the bug. I’ve attached the video to this message.

I hope this will help fix the issue in the next release.
Best regards.

will.qiu · August 12, 2026, 7:16am

Hi,

Thank you for providing the video showing the issue.

Have you had a chance to use the PowerShell command and steps we provided earlier to check whether the Windows network profile itself is also changing in a similar way?

Additionally, does the issue still occur if ESET is completely disabled, including its kernel-level components?

softhive · August 12, 2026, 8:42am

I used ESET Endpoint Antivirus only to visually demonstrate, in real time, how inactive network profiles are created and stored in the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

The antivirus is not related to this issue. With my previous router, the TP-Link TD-W8968 v5, this problem does not occur when connecting via a UTP cable. The problem occurs only when connecting the Flint 2 via a UTP cable. Could U-Boot be creating inactive profiles before loading the main firmware?

I assume your developers should be able to reproduce the bug using the reproduction steps I provided and investigate the issue themselves, since it can be reproduced consistently. Moreover, my friend has a Flint 2 router with exactly the same problem, so this is not an isolated case.

brushertr · August 12, 2026, 10:59am

I have same situation. It was 32 before reboot and 33 after.

And I see this popup during reboot. It increase with every reboot. (It ask something about Pc can be found on this network)

will.qiu · August 14, 2026, 2:03am

Hi,

Thank you for the updates and for providing the PowerShell test results.

Since we have been unable to reproduce the issue locally, could you please help run the following PowerShell script? This will allow us to compare the Network Profiles created by Windows before and after the router reboot and identify what changed — for example, GatewayMac, DNS suffix, FirstNetwork, or whether all fields remain the same but Windows still generates a new GUID.

(Please note that administrator privileges are required to access the relevant registry entries.)

function Get-NetworkSignatureSnapshot {
    $sigRoot = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged'
    $profileRoot = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles'

    Get-ChildItem $sigRoot | ForEach-Object {
        $sig = Get-ItemProperty $_.PSPath
        $profile = if ($sig.ProfileGuid) {
            Get-ItemProperty (Join-Path $profileRoot $sig.ProfileGuid) -ErrorAction SilentlyContinue
        }

        [pscustomobject]@{
            Signature         = $_.PSChildName
            ProfileGuid       = $sig.ProfileGuid
            ProfileName       = $profile.ProfileName
            DefaultGatewayMac = if ($sig.DefaultGatewayMac) {
                [BitConverter]::ToString([byte[]]$sig.DefaultGatewayMac)
            } else { '' }
            DnsSuffix         = $sig.DnsSuffix
            FirstNetwork      = $sig.FirstNetwork
            Description       = $sig.Description
        }
    }
}

$before = @(Get-NetworkSignatureSnapshot)
Read-Host 'Reboot the router, wait for Internet access to return, then press Enter'
$after = @(Get-NetworkSignatureSnapshot)

Compare-Object $before $after `
    -Property Signature,ProfileGuid,ProfileName,DefaultGatewayMac,DnsSuffix,FirstNetwork,Description `
    -PassThru |
    Where-Object SideIndicator -eq '=>' |
    Format-List *

Alternatively, you can directly compare the differences in the Network Profiles under the following two registry locations before and after the router reboot:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

Additionally, if possible, please install Wireshark on the Windows device and capture traffic starting before the router reboot until the network connection has fully recovered. You can then send the capture file to us via private message for further investigation.

softhive · August 14, 2026, 4:58pm

Hi. I have sent you the necessary network profile data via PM. It seems that the MAC addresses are different, which is strange for the same Flint 2 router. Probably we need the latest U-Boot update to avoid confusion?

softhive · August 17, 2026, 9:08am

Hi Will. I did some research and found an interesting screenshot on the Internet showing a U-Boot UART log that clearly explains why the inactive profiles are created. Please take a look at the “Upgrading Firmware” section in the screenshot, where U-Boot attempts to find the openwrt-gl-mt6000.bin file via TFTP on every normal boot of the GL-MT6000 Flint 2 router, before loading the main firmware. This is what causes the inactive profiles with a random MAC address to be created.

As far as I understand, this is unsafe and creates a vulnerability that could allow hacker attacks on the device - there's no need to do this on every normal boot. This behavior is acceptable only when the reset button is held down for an extended period. So we are now waiting for an updated version of U-Boot from GL.iNet with this dangerous issue fixed.

will.qiu · August 18, 2026, 8:31am

Hi,

Thank you for providing the PowerShell results and registry records.

After checking them, it does indeed appear that, as you mentioned, the issue is caused by a difference in the DefaultGatewayMac.

However, what is strange is that, by default, U-Boot should not have a DHCP server running to provide a default gateway.

So, if possible, could you please help us check the following:

If you disconnect all devices connected to the other Ethernet ports on the MT6000, including the WAN port, does the issue still occur?
If possible, as mentioned previously, please capture the traffic while rebooting the router. This will allow us to check the MAC address associated with the DefaultGateway of the newly created profile and help determine where it is coming from.

Regarding the issue of U-Boot retrieving updates via TFTP during the boot/reboot process, please allow us to investigate it locally and consult with our R&D team.

will.qiu · August 20, 2026, 2:24am

Thank you to brushertr for providing the packet capture.

We have now confirmed that this issue occurs when the router's LAN IP is configured as 192.168.1.1, which is the same IP address used by U-Boot.

For now, if changing the LAN IP is acceptable for your setup, the temporary workaround is to use a different LAN IP, such as the default 192.168.8.1.

We will also continue discussing this with our R&D team to see how this behavior can be improved or fixed in the future.

brushertr · August 20, 2026, 7:25am

I have too keep it as 1.1 because I have many static ips on my network but I can live with this untill fix. Thank you.

softhive · August 20, 2026, 5:44pm

I’m also using 1.1 as the router’s LAN IP. Thank you for confirming.

will.qiu · August 21, 2026, 6:53am

Hi,

Thank you for the confirmation.

We have investigated this further. If changing the LAN IP is currently not practical, another possible workaround is to modify the U-Boot environment variables and set its MAC address to match br-lan, which should avoid this issue.

Please follow the steps exactly as provided. Modifying other U-Boot environment variables incorrectly may prevent the device from booting properly, and this cannot be recovered using the Reset button.

LAN_MAC="$(tr 'A-F' 'a-f' < /sys/class/net/br-lan/address)"
{
    printf '%s\n' \
        "bootcmd mtkboardboot" \
        "bootdelay 2" \
        "baudrate 115200" \
        "ipaddr 192.168.1.1" \
        "serverip 192.168.1.2" \
        "netmask 255.255.255.0" \
        "loadaddr 46000000" \
        "env_fdt_path /config/environment" \
        "ethaddr $LAN_MAC" \
        "lf mtkupgrade fw openwrt-gl-mt6000.bin" \
        "lu mtkupgrade fip uboot-gl-mt6000.bin"
} > /tmp/u-boot-env-mac-fix.txt

fw_setenv -s /tmp/u-boot-env-mac-fix.txt

fw_printenv

To restore the factory U-Boot environment variables, you can use:

grep '^PARTNAME=u-boot-env$' /sys/class/block/mmcblk0p1/uevent || exit 1

dd if=/dev/zero \
   of=/dev/mmcblk0p1 \
   bs=512 count=1024 conv=fsync

reboot

brushertr · August 21, 2026, 1:41pm

Done and it works. Thank you.

softhive · August 21, 2026, 1:57pm

Thank you, Will, but this is only a temporary solution. U-Boot can still download malicious code via TFTP on every router reboot, disguised as a file named openwrt-gl-mt6000.bin. U-Boot needs to be fixed so that TFTP recovery/boot is only possible when the reset button is held down, for example.

will.qiu · August 21, 2026, 3:37pm

We are aware of this.

The previous workaround was mainly intended to address the issue where Windows creates a new Network Profile after every reboot.

Regarding the issue of enabling TFTP during the normal boot process, this would require changes to the U-Boot boot functions. Therefore, it may take more time to evaluate, coding, test, and release, and there may not be much progress on this in the short term.