I was able to fix this issue by updating the drivers on my computer. Apparently it didn't like connecting at 100mb for the port speed. Manually setting it to 10mb in windows allow it to link.
I was running a 10/100 port on a old laptop and just by updating the driver fixed the issue.
I'm suffering from the same issue on a Xiaomi 4a Gigabit. Tried the release version and the current snapshot (r18343-60881f657d). The problem occurs rather randomly, but it eventually ends up being exceedingly disruptive to a point where the LAN port isn't available for minutes.
Can't really figure out what's wrong. The ethtool fix didn't mitigate the issue. It's a gigabit connection, so this 10/100 switching issue appears to be unrelated.
daemon.notice netifd: Network device 'lan1' link is down
kern.info kernel: [39735.113301] mt7530 mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx
kern.info kernel: [39735.120825] br-lan: port 1(lan1) entered blocking state
kern.info kernel: [39735.126082] br-lan: port 1(lan1) entered forwarding state
daemon.notice netifd: Network device 'lan1' link is up
I am also having the same messages and issues.
It seems to me that I have been starting to see those issues with win11 as I don't recall having those issues with win10. Might that be related?
It is quite troublesome, I have tried to unplug the ports and reboot the router or reset the network but nothing worked.
Any other possible clues?
I'm starting to see system logs from when my PC is in Standby mode. Doesn't make much sense. Is that WoL related? Also one random fallback to 100MBits/s.
Tue Dec 21 03:40:51 2021 daemon.notice netifd: Network device 'lan1' link is down
Tue Dec 21 03:40:53 2021 kern.info kernel: [23045.356606] mt7530 mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
Tue Dec 21 03:40:53 2021 kern.info kernel: [23045.363955] br-lan: port 1(lan1) entered blocking state
Tue Dec 21 03:40:53 2021 kern.info kernel: [23045.369200] br-lan: port 1(lan1) entered forwarding state
Tue Dec 21 03:40:53 2021 daemon.notice netifd: Network device 'lan1' link is up
Tue Dec 21 03:40:54 2021 kern.info kernel: [23046.396121] mt7530 mdio-bus:1f lan1: Link is Down
Tue Dec 21 03:40:54 2021 kern.info kernel: [23046.400948] br-lan: port 1(lan1) entered disabled state
Tue Dec 21 03:40:54 2021 daemon.notice netifd: Network device 'lan1' link is down
Tue Dec 21 03:40:56 2021 kern.info kernel: [23048.476498] mt7530 mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control off
Tue Dec 21 03:40:56 2021 kern.info kernel: [23048.483848] br-lan: port 1(lan1) entered blocking state
Tue Dec 21 03:40:56 2021 kern.info kernel: [23048.489092] br-lan: port 1(lan1) entered forwarding state
Tue Dec 21 03:40:56 2021 daemon.notice netifd: Network device 'lan1' link is up
Tue Dec 21 03:40:58 2021 kern.info kernel: [23050.555969] mt7530 mdio-bus:1f lan1: Link is Down
Tue Dec 21 03:40:58 2021 kern.info kernel: [23050.560794] br-lan: port 1(lan1) entered disabled state
Tue Dec 21 03:40:58 2021 daemon.notice netifd: Network device 'lan1' link is down
Tue Dec 21 03:40:59 2021 kern.info kernel: [23051.596380] mt7530 mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control off
Tue Dec 21 03:40:59 2021 kern.info kernel: [23051.603901] br-lan: port 1(lan1) entered blocking state
Tue Dec 21 03:40:59 2021 kern.info kernel: [23051.609144] br-lan: port 1(lan1) entered forwarding state
Tue Dec 21 03:40:59 2021 daemon.notice netifd: Network device 'lan1' link is up
Tue Dec 21 07:02:50 2021 user.info : luci: accepted login on / for root from 192.168.1.xxx
Like I said, the target isn't even powered on. Yet the log is getting flooded.
I'm on Win10. Might try hooking my Laptop to the LAN port to see if it's OS related.
I tried:
Meanwhile I did what @torkcm mentioned and reduced the bandwidth manually in windows from 1g to 100mb and it did reduce the disconnection frequencies but I still do have some kern.info kernel: [656536.874007] mt7530 mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control rx/tx
Will keep updates on my issues, though I have checked the router specs and the port is supposed to be 1gbit port, same with the cable (cat7) and the network card on the my computer motherboard.
Though I never had that issue for like months since I used OpenWRT when my computer was on win10 before I changed to win11 few weeks ago...
I was going to chime in that I have these lines every 2-3 seconds on my Ubuntu laptop with GbEth:
[ 1155.885691] mt7530 mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[ 1155.893352] br-lan: port 1(lan1) entered blocking state
[ 1155.898609] br-lan: port 1(lan1) entered forwarding state
[ 1157.934219] mt7530 mdio-bus:1f lan1: Link is Down
[ 1157.939095] br-lan: port 1(lan1) entered disabled state
If I switch the port or use a different cable, it still happens. But not on my home server (BananaPi), but also on a different laptop with same OS and same ethernet port driver (r8169). I think it's the driver not being quite right for the hardware. I have installed r8168-dkms and it seems to have fixed the problem.
(This can never explain any problems with Windows machines of course...)
This could be targeting the issue:
After trying out several snapshot builds and a plethora of settings regarding my ethernet adapter I switched out the Cat6 flat cable to a new Cat7 one. I had some slight suspicion after seeing that a fixed 1GBit link rate would cause very frequent port flapping. I'm at 7 days uptime now without having a single issue.
It never occured to be that something as trivial as the cable could be the cause of issues in my case. Especially since that very same cable worked flawlessly for years with my previous router (TL-WDR3600). Would appear my router model is more sensitive towards cable quality and shielding.
I'll keep an eye on the logs regardless, but at least for me the problem wasn't induced by the mt7530 bridge nor OpenWRT.
Same thing for me. Had this issue for months and it was from a really long cable going through the house. Changed to better cabling and issue gone. One way to test if the issue exists is with iperf3, i noticed when i do an iperf test the wan resets with the bad cable.
If that's the solution you may mark it as such.
I wouldn't know if it's a universal solution for an actual problem (the mt7530 switch has been the target of numerous patches) or if it's just a solution for my specific case and router model.
I use OpenWRT 21.02 on Xiaomi 3g. I tried replacing LAN cable with cat7 and updating ethernet drivers, its not helping...
I switched out all mu lan cable to cat7 ones, i spent decent money and issue is still here. Any updates on the problem?
I experienced similar messages on a different piece of hardware and found that switching the patch cable with another one seemingly solved the issue. Over 1 h of uptime now and no messages using iperf3 to through gigs of data back and forth.
I am having the similar issue on ubnt x-SPF; The wan port keeps flapping up and down and causes not being able to complete PPPoE.
at Feb 19 22:20:26 2022 daemon.notice netifd: Network device 'eth4' link is up
Sat Feb 19 22:20:26 2022 daemon.notice netifd: Interface 'dsl_wan' has link connectivity
Sat Feb 19 22:20:26 2022 daemon.notice netifd: Interface 'dsl_wan' is setting up now
Sat Feb 19 22:20:26 2022 daemon.notice netifd: Interface 'wan_modem' has link connectivity
Sat Feb 19 22:20:26 2022 daemon.notice netifd: Interface 'wan_modem' is setting up now
Sat Feb 19 22:20:26 2022 daemon.notice netifd: Interface 'wan_modem' is now up
Sat Feb 19 22:20:26 2022 daemon.err insmod: module is already loaded - slhc
Sat Feb 19 22:20:26 2022 daemon.err insmod: module is already loaded - ppp_generic
Sat Feb 19 22:20:26 2022 daemon.err insmod: module is already loaded - pppox
Sat Feb 19 22:20:26 2022 daemon.err insmod: module is already loaded - pppoe
Sat Feb 19 22:20:26 2022 daemon.info pppd[7568]: Plugin rp-pppoe.so loaded.
Sat Feb 19 22:20:26 2022 daemon.info pppd[7568]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
Sat Feb 19 22:20:26 2022 daemon.notice pppd[7568]: pppd 2.4.8 started by root, uid 0
Sat Feb 19 22:20:26 2022 daemon.debug pppd[7568]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Sat Feb 19 22:20:26 2022 daemon.debug pppd[7568]: dst ff:ff:ff:ff:ff:ff src xx:xx:xx:xx;xx
Sat Feb 19 22:20:26 2022 daemon.debug pppd[7568]: [service-name] [host-uniq 90 1d 00 00]
Sat Feb 19 22:20:27 2022 daemon.notice netifd: Network device 'eth4' link is down
Sat Feb 19 22:20:27 2022 daemon.notice netifd: Interface 'dsl_wan' has link connectivity loss
Sat Feb 19 22:20:27 2022 daemon.notice netifd: Interface 'wan_modem' has link connectivity loss
Sat Feb 19 22:20:27 2022 daemon.notice netifd: Interface 'wan_modem' is now down
Sat Feb 19 22:20:27 2022 kern.info kernel: [ 146.505755] mt7530 mdio-bus:1f eth4: Link is Down
Sat Feb 19 22:20:27 2022 daemon.err pppd[7568]: select (waitForPADO): Interrupted system call
Sat Feb 19 22:20:27 2022 daemon.warn pppd[7568]: Timeout waiting for PADO packets
Sat Feb 19 22:20:27 2022 daemon.err pppd[7568]: Unable to complete PPPoE Discovery
I also tried to disable eee, and had no difference;
=======
The interesting parts are that
--> This is from kernel log:
Port flapping:
[ 202.825891] mt7530 mdio-bus:1f eth4: Link is Up - 100Mbps/Full - flow control off
[ 203.849763] mt7530 mdio-bus:1f eth4: Link is Down
Workaround that works
[ 219.209984] mt7530 mdio-bus:1f eth4: Link is Up - 1Gbps/Full - flow control rx/tx
[ 219.427297] pppoe-dsl_wan: renamed from ppp0
Just resolved the issue of the flapping WAN interface (100Mb/s at boottime) on my Xiaomi Mi Router 3G router by upgrading to latest firmware 21.02.2. just released. WAN interface on Xiaomi router no longer showing this issue on my router with this new firmware.
Edit:
Spoken to soon: problem seems be be reduced (no more issues during boottime), however some what later the WAN interface starts to flapping again.
I was experiencing this LAN bouncing issue with 18.x 19.x and ultimately 21.x on all D-Link DIR-860L B1 routers I own, mainly when the LAN connections were 100Mbit.
I did a lot of experiments and diagnostics and came to the conclusion that the mt7530 switch driver is faulty. I f i started the router without any LAN cables connected and then gradually plugging them one by one, everything was OK (link got initialized properly). However, if i started the router with the cables already fitted in, then the bouncing would take place.
My conclusion was that the mt7530 switch driver doesn't properly initialize the links when first loaded (might be some racing or timing issue) and the workaround was to reset the links immediately after the router boots.
The best way to achieve this on OpenWRT, which is not a standard Linux installation, where I could simply unload/reload the driver, was to bring down the switch interfaces (LAN). Well, again, it's OpenWRT and I didn't know how to do it without messing up the whole system and found that restarting the network would do the job (also reload the configuration).
/bin/sleep 10
/bin/ubus call network restartProblem solved - no more interfaces bouncing.
Just a update here, after I have changed my cable to new cables, this problem is no longer existing, I didn't nothing change another than cables only.
I managed to find my issue after all.
In my case I changed the cable from cat.7 to cat.6 but kinda make it worse.
I noticed that manually reducing the speed duplex of the PC board to 100mbs made me avoid the disconnections from the internet but I was still getting the down/up from the router.
I found out after browsing for a while on the internet that it was either:
1- ipv4 PPPoE protocol and ipv6 DHCP protocols were not stable together.
2- or that my Dual-Stack protocol and the ipv4 PPPoE protocols were not stable together.
As I kinda did the changes at the same time I don't know which one was wrong but since now it's working for 2 days without issue I won't touch it back 
if 1- was the issue I changed the DCHP setup for the LAN interface to change the settings to relay modes and ensure it wasn't designated as ipv6 master
if 2- I did the same thing as 1 + removed my old wan ipv4 PPPoE protocol so I only have my Dual-Stack and my ipv6 protocols (though Dual-Stack is a tunnel interface for ipv6)
hope it may help some ppl out.
(sorry @Knarf is not an answer to you but to the topic in general)
When I experimented this kind of disconnects, I was connected through wifi, and changing the wifi beacon interval helped in my case (that's why I am proposing it as a default Proposal to change the default wifi beacon interval from 100 ms to 50 ms )
