lime-config fails if the device doesn't have a network device named 'eth0'

[a-gave]

Found trying to run libremesh on a tplink-eap650-outdoor-v1 which have a physical interface named 'lan'

The device is currently unsupported (see openwrt/openwrt#23056) but the issue should be valid for other routers without a network device named 'eth0' like the tplink-eap610-outdoor-v1 which is currently supported.

Details:
When configuring the network lime-config expects that lime-autogen contains a config network.primary_interface else it will use 'eth0'
If eth0 is not present the first lime-config fails to run.
The strange fact is that it is not sufficient to modify the lime-defaults network.primary_interface to 'auto' or 'lan'
The workaround I found was to copy also the file lime-defaults to lime-autogen.
It seems that the function 'network.primary_interface()' requires a lime-autogen with a config network.primary_interface to be present before it's first run.
The device remains in a sort of bricked state, recoverable via serial interface.
I'll add some more details and the error log once I reproduce the issue.

lime-packages/packages/lime-system/files/usr/lib/lua/lime/network.lua

Line 68 in aebe482

local ifname = config.get("network", "primary_interface", "eth0")

function network.primary_interface()
	local ifname = config.get("network", "primary_interface", "eth0")
	if ifname == "auto" then
		local board = utils.getBoardAsTable()
		ifname = board['network']['lan']['device']
	end
	network.assert_interface_exists(ifname)
	return ifname
end

[ilario]

Ooh!
Do you think that we could solve setting the value to auto both in lime-system's lime-defaults file and in the config.get fallback value?

[a-gave]

Ooh! Do you think that we could solve setting the value to auto both in lime-system's lime-defaults file and in the config.get fallback value?

This works for the device in question! But will break for sure all other devices which have a more common 'eth0'. Tested changing the code and lime-defaults as you suggested and loading an initramfs on the device with the lan port renamed from lan to eth0.

I imagine that eth0 could be left as default value in lime-defaults. But I still need to figure out which could be a better fallback mechanism in case an eth0 port doesn't exist

This was the error messages

Executed hook:	sh -c 'ACTION=init /etc/hotplug.d/lime-config/babeld-auto-gw.lua'	0
Executed hook:	sh -c 'ACTION=pre /etc/hotplug.d/lime-config/babeld-auto-gw.lua'0
/usr/bin/lua: /usr/lib/lua/lime/network.lua:63: network.primary_interface() eth0 doesn't exists!
stack traceback:
	[C]: in function 'assert'
	/usr/lib/lua/lime/network.lua:63: in function 'assert_interface_exists'
	/usr/lib/lua/lime/network.lua:73: in function 'primary_interface'
	/usr/lib/lua/lime/network.lua:78: in function 'primary_mac'
	/usr/lib/lua/lime/config.lua:205: in function 'main'
	/usr/bin/lime-config:55: in main chunk
	[C]: ?

[ilario]

This works for the device in question! But will break for sure all other devices which have a more common 'eth0'. Tested changing the code and lime-defaults as you suggested and loading an initramfs on the device with the lan port renamed from lan to eth0.

This was the error messages

/usr/bin/lua: /usr/lib/lua/lime/network.lua:63: network.primary_interface() eth0 doesn't exists!
stack traceback:
	[C]: in function 'assert'
	/usr/lib/lua/lime/network.lua:63: in function 'assert_interface_exists'
	/usr/lib/lua/lime/network.lua:73: in function 'primary_interface'
	/usr/lib/lua/lime/network.lua:78: in function 'primary_mac'
	/usr/lib/lua/lime/config.lua:205: in function 'main'
	/usr/bin/lime-config:55: in main chunk
	[C]: ?

You renamed the interface? Fancy!
Can you check if your renaming also renamed the entry in /sys/class/net/? The error you reported above is complaining about the fact that the detected interface does not exist in that directory. Could it happen because the renaming did not change the name also there?

It seems that the detected primary interface only gets used for extracting its MAC address by network.primary_mac()

I tested what interface got detected by network.primary_interface() when the ifname was auto:

• TP-Link WDR3600: eth0.1, whose MAC address is the same as eth0
• PlasmaCloud PA1200: ethernet1, whose MAC address is the same as eth0
• TP-Link : eth0.1, whose MAC address is the same as eth0
• YouHua WR1200JS: nil

Clearly, the latest is no good... But eth0 could be used as a fallback if nil is detected...

Just for reference, here you are the contents of the /etc/board.json of the YouHua WR1200JS with installed OpenWrt 24.10:

{
	"model": {
		"id": "youhua,wr1200js",
		"name": "YouHua WR1200JS"
	},
	"led": {
		"internet": {
			"name": "INTERNET",
			"sysfs": "green:wan",
			"type": "netdev",
			"device": "wan",
			"mode": "link tx rx"
		}
	},
	"network": {
		"lan": {
			"ports": [
				"lan1",
				"lan2",
				"lan3",
				"lan4"
			],
			"protocol": "static"
		},
		"wan": {
			"device": "wan",
			"protocol": "dhcp"
		}
	},
	"system": {
		"compat_version": "1.1"
	},
	"wlan": {
		"phy0": {
			"path": "1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0",
			"info": {
				"antenna_rx": 3,
				"antenna_tx": 3,
				"bands": {
					"2G": {
						"ht": true,
						"max_width": 40,
						"modes": [
							"NOHT",
							"HT20",
							"HT40"
						],
						"default_channel": 1
					}
				},
				"radios": [
				]
			}
		},
		"phy1": {
			"path": "1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0",
			"info": {
				"antenna_rx": 3,
				"antenna_tx": 3,
				"bands": {
					"5G": {
						"ht": true,
						"vht": true,
						"max_width": 80,
						"modes": [
							"NOHT",
							"HT20",
							"VHT20",
							"HT40",
							"VHT40",
							"VHT80"
						],
						"default_channel": 36
					}
				},
				"radios": [
				]
			}
		}
	}
}

And the nil value derives from the lack of board['network']['lan']['device'].