Improve get node status results

[selankon]

Improve get node status results with following improvements:

• Split and refactor the code to be more atomic and redeable
• Add chain information to the result:

"signal":  -14,
"chains": [
    -17,
    -16
],

• It also add information of the switch status (port, role, interface and link up or down).

To get the switch status it combine the parsing of /etc/board.json to get the roles and swconfig dev switch0 show to get if they are up or not. The switches connected directly yo the cpu doesn't have a role attribute on the /etc/board.json so they are discarded.

Using ubus call lime-utils get_node_status '{}'

{
	"ips": [
		{
			"version": "4",
			"address": "10.219.123.10/16"
		},
		{
			"version": "6",
			"address": "fddb:f81c:47ba::a7b:be00/64"
		},
		{
			"version": "6",
			"address": "fe80::c24a:ff:febe:7b0a/64"
		}
	],
	"hostname": "lapastoramesh-c",
	"switch_status": [
		{
			"device": "eth0.1",
			"num": 2,
			"role": "lan",
			"link": "up"
		},
		{
			"device": "eth0.1",
			"num": 3,
			"role": "lan",
			"link": "down"
		},
		{
			"device": "eth0.1",
			"num": 4,
			"role": "lan",
			"link": "down"
		},
		{
			"device": "eth0.1",
			"num": 5,
			"role": "lan",
			"link": "down"
		},
		{
			"device": "eth0.1",
			"num": 0,
			"role": "cpu",
			"link": "up"
		},
		{
			"device": "eth0.2",
			"num": 1,
			"role": "wan",
			"link": "down"
		},
		{
			"device": "eth0.2",
			"num": 0,
			"role": "cpu",
			"link": "up"
		}
	],
	"status": "ok",
	"uptime": "3186.15",
	"most_active": {
		"rx_short_gi": true,
		"station_mac": "C0:4A:00:DD:69:1C",
		"tx_bytes": 13809119,
		"rx_vht": false,
		"rx_mhz": 40,
		"rx_40mhz": true,
		"tx_packets": 31706,
		"tx_mhz": 40,
		"rx_packets": 97813,
		"rx_ht": true,
		"tx_mcs": 15,
		"noise": -90,
		"rx_mcs": 15,
		"chains": [
			-17,
			-16
		],
		"rx_bytes": 19464143,
		"tx_ht": true,
		"iface": "wlan1-mesh",
		"tx_rate": 300000,
		"inactive": 30,
		"tx_short_gi": true,
		"tx_40mhz": true,
		"expected_throughput": 59437,
		"tx_vht": false,
		"rx_rate": 300000,
		"signal": -14
	}
}

[codecov-commenter]

Codecov Report

Merging #974 (28d7b41) into master (8de4eb1) will increase coverage by 1.10%.
The diff coverage is 82.95%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##           master     #974      +/-   ##
==========================================
+ Coverage   77.71%   78.82%   +1.10%     
==========================================
  Files          52       53       +1     
  Lines        4362     4415      +53     
==========================================
+ Hits         3390     3480      +90     
+ Misses        972      935      -37     

Impacted Files	Coverage Δ
...-lime-utils/files/usr/lib/lua/lime/node_status.lua	82.14% <82.14%> (ø)
...s/ubus-lime-utils/files/usr/lib/lua/lime-utils.lua	44.44% <100.00%> (+10.56%)	⬆️
...i-unstuck-wa/files/usr/lib/lua/wifi_unstuck_wa.lua	100.00% <0.00%> (ø)
...kages/lime-system/files/usr/lib/lua/lime/utils.lua	85.79% <0.00%> (+0.29%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ilario]

Hey @selankon I was going to compile an image including these commits but I just wanted to make you notice that some unit tests are failing: https://github.com/libremesh/lime-packages/actions/runs/4083046792/jobs/7038111305

[selankon]

Hi @ilario , I forgot to add tests, now everything works fine!

@G10h4ck requested changes are done

[selankon]

I want to change the:

{
   "signal": "-18 [-22, -21] dBm"
}

To

{
"signal": -18,
"chains": [-22, -21] 
}

I'm working on the regex to fix this

[ilario]

What happens if DSA is in place rather than swconfig?
This is the situation already in place with many targets, and very likely this will happen also to ath79 with the next OpenWrt release.
(I can give you a router already supported by DSA, if this can help the development)

[selankon]

Hi Ila!

What happens if DSA is in place rather than swconfig?

Won't be a problem, the code will be updated easily. At the time DSA is implemented and we can test it, I will write the needed code to use it. When it arrive we'll check.

At first moment we thought to use DSA directly, but this implementation will work on any router right now. And probebly, when DSA comes in, we can add an if to preferentially use DSA if available.

I can give you a router already supported by DSA, if this can help the development

If you do that I could start playing and preparing a PR to advance work :)

[ilario]

Hi Ila!

Helooo!

What happens if DSA is in place rather than swconfig?

Won't be a problem, the code will be updated easily. At the time DSA is implemented and we can test it, I will write the needed code to use it. When it arrive we'll check.

Well, I would say that DSA is already here:
https://forum.openwrt.org/t/dsa-target-list-cumulative/151087/2

If you check the modern routers, for example from here https://openwrt.org/toh/views/toh_extended_all?datasrt=target&dataflt%5BAvailability%2A~%5D=2023 and compare with the DSA targets list you will see that most of them already have DSA.

I can give you a router already supported by DSA, if this can help the development

If you do that I could start playing and preparing a PR to advance work :)

Yesss! I can give you one or two YouHua WR1200JS :)

[ilario]

Also, next week I will try to compile images using the branch from this PR: openwrt/openwrt#4622 so that, if you want, you should be able to test with DSA even on LibreRouter.

[ilario]

Maybe is better to merge this and then fix the case of DSA.
Would you say that this PR creates new problems for DSA users or is it neutral?
Do you expect problems with the code if the swconfig command is not present?
If it does not introduce any bad behavior, I would propose to merge it and then think to the DSA case.

[selankon]

Maybe is better to merge this and then fix the case of DSA. Would you say that this PR creates new problems for DSA users or is it neutral?

It should be almost neutral, with no errors but either without information. I would like to test it a little bit more in a DSA router if possible.

Do you expect problems with the code if the swconfig command is not present? If it does not introduce any bad behavior, I would propose to merge it and then think to the DSA case.

As implemented on other parts, we can create a classic if else structure which is preferred to use DSA, or else swconfig or else return an empty array. Should not be a problem (right now, if swconfig is not available should return just an empty array)

[ilario]

Ok, I will try to give you a DSA supported router.

For the if/else statements, you can use the DSA checker that I am proposing in #959

[ilario]

Just tested calling the node_status.switch_status() function on a DSA-supported router with OpenWrt 19.07 and 22.03.
In the first case it gave a table with the expected content, while in the second case it returned an empty table.
In my opinion we can merge this both in the new https://github.com/libremesh/lime-packages/tree/OpenWrt_19.07_compatible branch and in the master branch.
Then, with DSA routers will not show switch information (but will give other information) and will need to be improved.
@G10h4ck @spiccinini opinions?

[G10h4ck]

Just tested calling the node_status.switch_status() function on a DSA-supported router with OpenWrt 19.07 and 22.03. In the first case it gave a table with the expected content, while in the second case it returned an empty table. In my opinion we can merge this both in the new https://github.com/libremesh/lime-packages/tree/OpenWrt_19.07_compatible branch and in the master branch. Then, with DSA routers will not show switch information (but will give other information) and will need to be improved. @G10h4ck @spiccinini opinions?

I'll merge this only into the development branch

I think we should merge into the OpenWrt 19 compatibility branch only critical little fixes