| commit | f910893aff599cde36fb841f633854c248ed59ee | [log] [tgz] |
|---|---|---|
| author | Tomáš Pecka <tomas.pecka@cesnet.cz> | Tue Jun 01 10:19:36 2021 +0200 |
| committer | Tomáš Pecka <tomas.pecka@cesnet.cz> | Tue Jun 15 11:48:07 2021 +0200 |
| tree | 6bb0135c27c77f54164b6bf53eb748782c313a8e | |
| parent | 9fa5f6ae23572c1b7b14c5c7df7e70d6e8ecd0a3 [diff] |
system: Determine if link is a bridge from sysfs Determining whether link is a bridge via libnl seems to be tricky. There are functions like rtnl_link_get_family(rtnl_link*)[1] or (even better) rtnl_link_is_bridge(rtnl_link*)[2] but both of them seem to fail in certain situations[3]. I have encountered this while adding/removing interfaces to/from a bridge. When the interface is added/removed to/from the bridge the kernel (see /net/bridge/br_netlink.c) sends RTM_NEWLINK or RTM_DELLINK messages for the interface being added/removed. This is kind of confusing for libnl, because it can't differentiate whether the link was just updated or really added/removed [3,4] (in reality only information about changing the bridge vlan is sent) and it triggers NL_ACT_NEW/NL_ACT_DEL event for the interface (if nl cache manager is used). The nl cache manager considers the message to be an added/removed interface. And then is then flagged by rtnl_link_is_bridge as a bridge and this is wrong. That is why velia reports the interface as bridge even when it is not. So, let's replace this method of determining if link is a bridge. It seems that checking for the existence of /sys/class/net/<name>/bridge directory works everytime. A test is also added. Please note that receiving a libnl notification about a change in the bridge state might take some time, hence the longer waits. [1] https://www.infradead.org/~tgr/libnl/doc/api/group__link.html [2] https://www.infradead.org/~tgr/libnl/doc/api/group__bridge.html [3] https://github.com/thom311/libnl/issues/209 [4] https://github.com/thom311/libnl/issues/74 Fixes: 019748fbfe1dfd5d05efbd7204be99122cf54e34 Bug: https://github.com/thom311/libnl/issues/209 Change-Id: I90e2dcb099c4df4daac7cea3b141a1a152a4de47
Together with sysrepo, this software provides "general system management" of embedded devices. The target platform is anything that runs Linux with systemd. This runs in production on CzechLight SDN DWDM devices.
This component tracks the overal health state of the system, including various sensors, or the state of systemd units. As an operator-friendly LED at the front panel of the appliance shows the aggregated health state.
Firmware can be updated via RAUC, and various aspects of the system's configuration can be adjusted. This includes a firewall, basic network settings, and authentication management.
For a full list, consult the yang/ directory in this repository.