GL-MT6000 dmesg spammed with Link down/up messages

Installing and Using OpenWrt
1

I just flashed a snapshot built from a few hours ago and noticed several thousand entries in my dmesg output relating to lan5 going up and down. Any thoughts to troubleshoot?

I currently do not have physical access to the device but can remote in. What I see in LuCI's status page is the port status for lan5 going from "no link" to "1 GbE" which co-insides with the dmeg output.

The device connected to lan5 is current gen 4k Apple tv. Once the Apple tv is awake from sleep, the device stays connected consistently.

Could be some Apple TV network keep alive or something that happens when the device is sleeping?

Example:

[   21.810857] mt7530-mdio mdio-bus:1f lan5: Link is Up - 1Gbps/Full - flow control rx/tx
[   21.810887] br-lan: port 5(lan5) entered blocking state
[   21.824029] br-lan: port 5(lan5) entered forwarding state
[   33.947078] br-lan: port 5(lan5) entered disabled state
[   33.947196] mt7530-mdio mdio-bus:1f lan5: Link is Down
[   44.178748] mt7530-mdio mdio-bus:1f lan5: Link is Up - 1Gbps/Full - flow control rx/tx
[   44.178773] br-lan: port 5(lan5) entered blocking state
[   44.191881] br-lan: port 5(lan5) entered forwarding state
[   48.131050] br-lan: port 5(lan5) entered disabled state
[   48.131171] mt7530-mdio mdio-bus:1f lan5: Link is Down
[   50.751919] mt7530-mdio mdio-bus:1f lan5: Link is Up - 1Gbps/Full - flow control off
[   50.751943] br-lan: port 5(lan5) entered blocking state
[   50.764882] br-lan: port 5(lan5) entered forwarding state
[   51.503265] br-lan: port 5(lan5) entered disabled state
[   51.503384] mt7530-mdio mdio-bus:1f lan5: Link is Down
[   54.528009] mt7530-mdio mdio-bus:1f lan5: Link is Up - 1Gbps/Full - flow control rx/tx
[   54.528034] br-lan: port 5(lan5) entered blocking state
[   54.541137] br-lan: port 5(lan5) entered forwarding state
...
/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 'fd99:97d2:a14e::/48'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'
	option peerdns '0'
	list dns '1.1.1.1'
	list dns '1.0.0.1'

config interface 'lan'
	option device 'br-lan.10'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option delegate '0'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'lan5'
	option ipv6 '0'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	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 '3'

config bridge-vlan
	option device 'br-lan'
	option vlan '4'

config device
	option name 'br-lan.10'
	option type '8021q'
	option ifname 'br-lan'
	option vid '10'
	option ipv6 '0'

config device
	option name 'br-lan.3'
	option type '8021q'
	option ifname 'br-lan'
	option vid '3'
	option ipv6 '0'

config device
	option name 'br-lan.4'
	option type '8021q'
	option ifname 'br-lan'
	option vid '4'
	option ipv6 '0'

config device
	option name 'eth0'
	option ipv6 '0'

config device
	option name 'eth1'
	option ipv6 '0'

config device
	option name 'lan1'
	option ipv6 '0'

config device
	option name 'lan2'
	option ipv6 '0'

config device
	option name 'lan3'
	option ipv6 '0'

config device
	option name 'lan4'
	option ipv6 '0'

config device
	option name 'lan5'
	option ipv6 '0'

config device
	option name 'wg0'

config device
	option type 'bridge'
	option name 'lxcbr0'
	option bridge_empty '1'
	option ipv6 '0'

config interface 'guest'
	option proto 'static'
	option device 'br-lan.3'
	option ipaddr '192.168.3.1'
	option netmask '255.255.255.0'

config interface 'iot'
	option proto 'static'
	option device 'br-lan.4'
	option ipaddr '192.168.4.1'
	option netmask '255.255.255.0'

config interface 'lxc'
	option device 'lxcbr0'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.0.4.1'

config interface 'wg0'
	option proto 'wireguard'
...
<<< omitted wireguard specific stuff >>>
2 
ubus call system board
ethtool -S lan5 | grep -v :0$
ethtool lan5
3 
# ubus call system board
{
	"kernel": "6.6.62",
	"hostname": "powermousetrap",
	"system": "ARMv8 Processor rev 4",
	"model": "GL.iNet GL-MT6000",
	"board_name": "glinet,gl-mt6000",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"revision": "r28123+6-90f0be8521a8",
		"target": "mediatek/filogic",
		"description": "OpenWrt SNAPSHOT r28123+6-90f0be8521a8",
		"builddate": "1731872177"
	}
}

And

# ethtool -S lan5 | grep -v :0$
NIC statistics:
     tx_packets: 322761
     tx_bytes: 438486770
     rx_packets: 40818
     rx_bytes: 5849268
     TxDrop: 0
     TxCrcErr: 0
     TxUnicast: 320350
     TxMulticast: 1884
     TxBroadcast: 549
     TxCollision: 0
     TxSingleCollision: 0
     TxMultipleCollision: 0
     TxDeferred: 9
     TxLateCollision: 0
     TxExcessiveCollistion: 0
     TxPause: 0
     TxPktSz64: 1103
     TxPktSz65To127: 3555
     TxPktSz128To255: 1360
     TxPktSz256To511: 2763
     TxPktSz512To1023: 596
     Tx1024ToMax: 313406
     TxBytes: 439799074
     RxDrop: 0
     RxFiltering: 4
     RxUnicast: 37864
     RxMulticast: 2172
     RxBroadcast: 797
     RxAlignErr: 0
     RxCrcErr: 0
     RxUnderSizeErr: 0
     RxFragErr: 0
     RxOverSzErr: 0
     RxJabberErr: 0
     RxPause: 0
     RxPktSz64: 1149
     RxPktSz65To127: 35309
     RxPktSz128To255: 881
     RxPktSz256To511: 1433
     RxPktSz512To1023: 842
     RxPktSz1024ToMax: 1219
     RxBytes: 5851212
     RxCtrlDrop: 0
     RxIngressDrop: 0
     RxArlDrop: 0

And

# ethtool lan5
Settings for lan5:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 3
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: d
	Wake-on: d
	Link detected: yes

Note that I edited my first post with some more details, in summary:

The device connected to lan5 is current gen 4k Apple tv. Once the Apple tv is awake from sleep, the device stays connected consistently.

4

Now show

 ethtool --show-eee lan5
 ethtool -a lan5
5 
#  ethtool --show-eee lan5
EEE Settings for lan5:
	EEE status: disabled
	Tx LPI: 30 (us)
	Supported EEE link modes:  100baseT/Full 
	                           1000baseT/Full 
	Advertised EEE link modes:  Not reported
	Link partner advertised EEE link modes:  100baseT/Full 
	                                         1000baseT/Full

And

# ethtool -a lan5 
Pause parameters for lan5:
Autonegotiate:	on
RX:		off
TX:		off
6

One : disable 10mbps lor fix at 1000mbps

Two : rather wrong that pause is disabled and still advertised and negotiated.

7

This is actually a common issue/report for ATV's connected over ethernet...

It's power-saving mode on the device itself...

It likely won't get much attention from Apple as they're more focused on WiFi for those devices...

Some more insight...

https://discussions.apple.com/thread/8150492

1 Like
8

Apple does not restart openwrt firewall on dsa cable event.

9

Hmm do you run these mac devices through multiple switches?

I got something like this with my tv which has 2 switches behind, when dhcp renews also netifd bugs out my tv then also reports really short that the cable was disconnected.

But lately i don't see this anymore on my tv, but i wonder if something like this trigger netifd?

Can you check if you see a similar pattern? :+1:

10

Set advertised modes to match EEE modes and try agan

ethtool -s lan5 advertise 0x028
ethtool -r lan5
# check again
# ethtool lan5
11

Thank for you posting the link. Glad I am not the only one.

No, this is a simple setup with the MT6000 serving as the router/firewall/access point. The Apple TV is connected directly to it/nothing in between.

12 
# ethtool -s lan5 advertise 0x028
# ethtool -r lan5
# ethtool lan5 
Settings for lan5:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 3
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: d
	Wake-on: d
	Link detected: yes

The difference in the output before vs after:

--- before	2024-11-18 17:09:47.149899979 -0500
+++ after	2024-11-18 17:09:26.253270139 -0500
@@ -6,10 +6,9 @@
		Supported pause frame use: Symmetric Receive-only
		Supports auto-negotiation: Yes
		Supported FEC modes: Not reported
-		Advertised link modes:  10baseT/Half 10baseT/Full 
-		                        100baseT/Half 100baseT/Full 
+		Advertised link modes:  100baseT/Full 
		                        1000baseT/Full 
-		Advertised pause frame use: Symmetric Receive-only
+		Advertised pause frame use: No
		Advertised auto-negotiation: Yes
		Advertised FEC modes: Not reported
		Link partner advertised link modes:  10baseT/Half 10baseT/Full 
@@ -28,4 +27,3 @@
		Supports Wake-on: d
		Wake-on: d
		Link detected: yes

But the disconnection every 7-8 sec or so continues

13

Make it 0x020 or 0x08 and try again. Next to try is to restore original 0x2F and disable EEE.

Edit: -r is to force speed re-negotiation, it is in ethtool -h , the large list of modes is in man ethtool on any linux.

14

I am not seeing a difference in behavior switching the modes from 0x020 to 0x08 to 0x2F. I am seeing the link establishing itself at either 1 GbE or 100 M accordingly. I do have EEE disabled. Running a simple ethtool -r lan5 also has no change in behavior.

15

ethtool -r is meant to renegotiate link after setting negotiation registers.

Now:

ethtool --set-eee lan5 eee off advertise on
ethtool -r eth5

Also try with advertise off

16

I tired them both/no change :frowning:

17

Now -a/-A :wink:

18 
# ethtool -a lan5
Pause parameters for lan5:
Autonegotiate:	on
RX:		off
TX:		off
RX negotiated:	off
TX negotiated:	off

And

# ethtool -A lan5
no pause parameters changed, aborting
19

It is tx off rx off
then autoneg off

20

I'm not seeing in the log snippets that OP provided that suggests the FW is being reloaded..