Rpc/ubus way to get interface statistics?

For Developers
1

I am toying around with bandwidth indicators, LEDs and somesuch. In this process, I need to get the current bandwidth on an interface.

I expected to use rpc/ubus to get such statistics (current rx/tx bytes, for example). And my first instinct was to look into how the already existing software does gets those. However, when I looked into what LuCI does to display the realtime bandwidth, I found that it employs a tiny daemon (luci-bwc) that in turn simply looks into /sys/class/net/(interface)/statistics and aggregates the data.

So my question is: Is this still the current "standard" to get plain interface statistics or is there a better, ubus way?

2 
root@jj:~# ubus call network.device status '{ "name": "br-lan" }'
{
	"external": false,
	"present": true,
	"type": "bridge",
	"up": true,
	"carrier": true,
	"bridge-members": [
		"eth1",
		"eth2",
		"wlan0",
		"wlan0-1",
		"wlan1",
		"wlan1-1"
	],
	"mtu": 1500,
	"mtu6": 1500,
	"macaddr": "00:0d:b9:35:88:49",
	"txqueuelen": 1000,
	"ipv6": true,
	"promisc": false,
	"rpfilter": 0,
	"acceptlocal": false,
	"igmpversion": 0,
	"mldversion": 0,
	"neigh4reachabletime": 30000,
	"neigh6reachabletime": 30000,
	"neigh4gcstaletime": 60,
	"neigh6gcstaletime": 60,
	"neigh4locktime": 100,
	"dadtransmits": 1,
	"multicast": true,
	"sendredirects": true,
	"statistics": {
		"collisions": 0,
		"rx_frame_errors": 0,
		"tx_compressed": 0,
		"multicast": 0,
		"rx_length_errors": 0,
		"tx_dropped": 0,
		"rx_bytes": 40267652971,
		"rx_missed_errors": 0,
		"tx_errors": 0,
		"rx_compressed": 0,
		"rx_over_errors": 0,
		"tx_fifo_errors": 0,
		"rx_crc_errors": 0,
		"rx_packets": 175027896,
		"tx_heartbeat_errors": 0,
		"rx_dropped": 1902,
		"tx_aborted_errors": 0,
		"tx_packets": 261192674,
		"rx_errors": 0,
		"tx_bytes": 287106181175,
		"tx_window_errors": 0,
		"rx_fifo_errors": 0,
		"tx_carrier_errors": 0
	}
}
1 Like
3

Thank you, @jow, I suspected there is an ubus way. Is there any benefit of going through ubus (which I have to parse), or is it in turn just collecting rx_bytes/tx_bytes from the device (that I could just as well access directly for the straight-up numerical value)?

4

While some device types implemented by netifd might provide custom statistic reporting logic, the generic fall back used by most devices simply reads the sysfs.

So unless you're already solely using ubus, there likely is no point in chosing it over parsing the sysfs manually.

1 Like
5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.