During router boot up my clients are obtaining an IP from my upstream router, requiring a DHCP release/renew once the router is fully booted. I guess there is a gap when internal switch (rt-305x) is not yet configured (5 sec or so) and that causes some traffic to bypass the router. What can i do with that? How to fix that?
Your insight is spot on. This is a common, effectively unresolvable problem with consumer-grade switches in all-in-one routers. In contrast to an enterprise-grade switch, the phys are active on power-up, so they bleed until configured. Changing network topology to avoid the problematic leak is one of the few ways that this can be resolved. If you have a sophisticated, managed switch, you may be able to block the upstream DHCP from the GL-MT300N-V2 (running that “WAN” as static). This could be done at L2 by blocking the MAC of the DHCP server to the GL-MT300N-V2, or with L3 filtering.
Ok, so is it more hardware-related issue, or it could be fixed with the software patch?
Hardware issue, common to virtually all consumer-grade SoCs.
At least from what I’ve read from the data sheets to which I have access is that the switch comes up in a pre-configured mode at power-on that is “leaky” in this way. Potentially one could write a custom U-Boot that pre-configured the switch differently, closing the window somewhat, but there would still be the problem during any subsequent reconfiguration. This class of SoC is designed for home use where DHCP leakage is generally not a problem, nor are users aware of it when it is (“Oh, you’re having problems? It’s your equipment, not ours. Please reboot your router.”). There is little incentive for the SoC manufacturers to complicate the silicon with power-controlled phys and the resulting boot code required to “carefully” bring up the switch subsystem.
Well, as i recall Ubiquiti had the same issue on their Edgerouter X - Also with a mediatech chipset.
They fixed it long ago with a bootloader update - and in the newer firmware the fixed bootloader is “baked-in”
so issue should be fixable 
but please do not attempt to run the ubnt code on your GL-inet router - who knows what happens
give the guys at gl-inet time to fix this!
links to ubiquiti forumpost regarding this issue
and
Hi thanks for the provided links! Hope that GLinet team will fix that in the near future!
This has been fixed in both uboot and firmware.
Uboot binary is here uboot-source-for_mtk/bin at master · gl-inet/uboot-source-for_mtk · GitHub
To upgrade uboot, first enter uboot failsafe mode, then use http://192.168.1.1/uboot.html directly to upload the binary.
1 Like
Am I going mad or is this still an issue? When the router boots, any LAN connected devices seem to pick up an IP address from the WAN interface, while WWAN connected devices will only ever be issued LAN IP addresses.
Is there no way to fix this? Surely the switch can block all traffic until it has finished booting? Its supremely annoying as it means any devices on the LAN connection may not swap over to the correct network/IP until the lease expires on the WAN IP address. It also means that multiple MAC addresses appear to be connected to a single port on the WAN connection.
I tried it does still have this problem.
Asked developer to fix asap.
Thank you, do you have any indication of how long this might take? Are we talking weeks or months?
Thanks
I hope it could be 1 or 2 weeks.
Thanks for this, do you have an update by any chance? This IP error causes a MAC table confusion in the network which is preventing us rolling out these devices.
We will upgrade firmware next week.
Do you have an update on this please? I have tested the latest beta version on your website but it didn’t help
Sorry I’m not sure I follow, that refers to a different technology and not related to the problem here as far as I can tell?
Sorry I just replied a wrong thread.
Pls wait a few days. It should be fixed soon.
https://dl.gl-inet.com/?model=mt300n-v2&type=snapshot
This firmware fixed the bug that bridges wan and lan during boot.