Swconfig dropping ethernet link on network reload, mt7628

On a VoCore2 on OpenWrt 23, running:

swconfig dev switch0 load network

Causes:

[ 1681.443310] rt3050-esw 10110000.esw: port 0 link down
[ 1681.449286] br0: port 1(eth0.1) entered disabled state

It'll come up again ~5 seconds later.

This is particularly annoying because this command is called on every network reload (see /etc/init.d/network), and when you apply multiple config changes it's possible network reload is called more than once (presumably some complex trigger situation). This means that the device reappears for a short time, allowing the frontend to find it, but often then disappears while the page is loading.

Is this a bug? Any nice workarounds? It seems like either swconfig or the network reload script should be smart enough not to reconfigure if the configuration is the same.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
root@OpenWrt:/# ubus call system board
{
	"kernel": "5.15.137",
	"hostname": "OpenWrt",
	"system": "MediaTek MT7628AN ver:1 eco:2",
	"model": "VoCore2",
	"board_name": "vocore,vocore2",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.2",
		"revision": "r23630-842932a63d",
		"target": "ramips/mt76x8",
		"description": "OpenWrt 23.05.2 r23630-842932a63d"
	}
}
root@OpenWrt:/# cat /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 'fde9:933b:d192::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0.1'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 2 6t'

As far as I can see swconfig has no checks for 'this configuration already exists', so it just goes straight through to esw_set_port_disable(esw, disable) in esw_apply_config(dev) in esw_rt3050.c, and swconfig is run every time on service network reload

To explain more clearly the user facing issue, this happens even if there are no config changes:

root@OpenWrt:/# service network reload && logread -f
[  435.781155] rt3050-esw 10110000.esw: port 0 link down
[  435.787158] br-lan: port 1(eth0.1) entered disabled state
'radio0' is disabled
'radio0' is disabled
Tue Nov 14 13:45:17 2023 daemon.notice netifd: bridge 'br-lan' link is down
Tue Nov 14 13:45:17 2023 daemon.notice netifd: Interface 'lan' has link connectivity loss
[  439.727314] rt3050-esw 10110000.esw: port 0 link up
[  439.732810] br-lan: port 1(eth0.1) entered blocking state
[  439.738312] br-lan: port 1(eth0.1) entered forwarding state
Tue Nov 14 13:45:20 2023 kern.info kernel: [  439.727314] rt3050-esw 10110000.esw: port 0 link up
Tue Nov 14 13:45:20 2023 kern.info kernel: [  439.732810] br-lan: port 1(eth0.1) entered blocking state
Tue Nov 14 13:45:20 2023 kern.info kernel: [  439.738312] br-lan: port 1(eth0.1) entered forwarding state
Tue Nov 14 13:45:20 2023 daemon.notice netifd: Network device 'eth0' link is up
Tue Nov 14 13:45:20 2023 daemon.notice netifd: VLAN 'eth0.1' link is up
Tue Nov 14 13:45:20 2023 daemon.notice netifd: bridge 'br-lan' link is up
Tue Nov 14 13:45:20 2023 daemon.notice netifd: Interface 'lan' has link connectivity
Tue Nov 14 13:45:20 2023 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.179 00:e0:4c:68:00:6b
Tue Nov 14 13:45:20 2023 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.179 00:e0:4c:68:00:6b mma-1375

I noticed this a long time ago, probably a year ago, with a problem connecting to wifi, perhaps it has something to do with my settings, I don’t know, but I solved this issue by adding commands to autostart, you can use Luci in system/startup - Starting packages and user services when the device is turned on
add this, save and reboot the router

sleep 10 && /etc/init.d/network restart
sleep 5 && /etc/init.d/firewall restart
exit 0

and I've never had anything like this ever again