Add pse poe control via netlink

[carlosz1986]

We are currently working on adding support for modern PSE/POE control. This will require linux 6.18 or some backports...

We have s working prototype. The details and some further discussions you find here: https://forum.openwrt.org/t/support-poe-on-hasivo-devices-s1100wp-8gt-se/244817/44?u=openwrtawesome

@bevanweiss suggested to move the logic from netifd to ubus. I tried it out by adding a ubusd_netlink module to ubus, which provides system_pse_get() and system_pse_set(). The issue is that "set" does not work, because it requires the CAP_NET_ADMIN permission, and ubusd runs not as root. I didn't find a workaround for this.

I'm not a professional kernel developer, so I appreciate some feedback from you guys :-)
Please take the code with a grain of salt...;-)

Where does this change belong? netifd or ubus?
best.

[carlosz1986]

Some further research, where this code belongs:

Another idea would be to move that to ubus, but ubus does not run as root and the CAP_NET_ADMIN is missing:
We could grant ubusd those permission, via:

setcap cap_net_admin+ep /usr/sbin/ubusd

It could work, but a) it requires setcap in the image and b) it looks to me somehow hacky. Besides more permissions are required, then really needed.

I researched some other methods, with help of google, forum and LLMs:

1) build a privileged helper daemon:

• runs with CAP_NET_ADMIN or as root
• registers own ubus objekt (pse)
• handles netlink PSE operations

cons: another binary, and more logic to review
pros: less privileges to ubusd

2) use rpcd

• add PSE control to a rpcd plugin
• runs already with more permissions

3) UCI + hotplug script

pros:

• privileges are existing
• simple and only scripts, but also not really native
  cons:
• not real time, requires reload

4) ethtool wrapper in init.d

• simple shell scrit

pros:

• easy
  cons:
• rather hacky and not deeply integrated

and last but not least the existing :
5) netifd variant
pros

• PSE controls power on phsyical ports, somehow similar to device/interface management
• it handles also link settings, MTU etc
• UCI integration simple
• runs already as root
• already exposes network.device + interface.* to ubus
• no extra daemon needed

cons:

• complex mature codebase ...
• add libnl dependency to netifd

Happy to get your thoughts... I am open to input :-)

[carlosz1986]

@systemcrash Would you share your thoughts on this? - As you helped a lot on the luci piece :)

[systemcrash]

It seems like netifd is the right place for this kind of thing. I'm not sure what opinion I can contribute here but the code looks like it does the right kind of things. Are you sure libnl is a dep?

[bevanweiss]

It seems like netifd is the right place for this kind of thing. I'm not sure what opinion I can contribute here but the code looks like it does the right kind of things. Are you sure libnl is a dep?

I'm pretty sure libnl is already included

netifd/CMakeLists.txt

Lines 44 to 51 in 777f594

	IF (NOT DEFINED LIBNL_LIBS)
	include(FindPkgConfig)
	pkg_search_module(LIBNL libnl-3.0 libnl-3 libnl nl-3 nl)
	IF (LIBNL_FOUND)
	include_directories(${LIBNL_INCLUDE_DIRS})
	SET(LIBNL_LIBS ${LIBNL_LIBRARIES})
	ENDIF()
	ENDIF()

I don't think carrying the extra attribute index defines here is correct though, since if the kernel netlink interface doesn't support the attribute indexes provided, then requesting them will have no benefit.
So, I think the PR would need to either:

• wait until OpenWRT targets kernel v6.17+, where these attributes are naturally supported; or
• have a matching backport of that PSE netlink support into the current OpenWRT kernel version (v6.12); or
• restrict which PSE attributes it exposes to align with the current OpenWRT kernel version (v6.12) so it's not defining 'non-existent' indexes (this would mean that it would want to be updated when OpenWRT does step up in kernel version though)

[carlosz1986]

Thanks guys, that helped a lot! It was still a draft and needs some rework & testing :) But next steps are clear now!

[carlosz1986]

1. libnl is included...
2. I cleaned up a little...
3. This PR is depending on the backport of pse-pd, which you find here: kernel: drivers: net: pse-pd: backport upstream commits from 6.19 openwrt#21810 , which is no merged!
4. I removed the defines https://github.com/openwrt/netifd/pull/65/changes#diff-86900f584da5eaf96a0cc82edf7470d205db9efed0419e457a8f717a05eac970R87-R94 ...

To make it work I needed to add a backport for PSE-port-priority support from 6.17

Another thing is that it requires to add the right ethtool headers via Makefile.

I would love to get feedback, how to proceed. I mean, what is the best order?

1. merge this?
2. another PR for changing the version and the Makefile inside of openwrt main repo? How to make sure this is then happening?
3. On top I wonder: If this PR requires different patches, what is the best approach. One PR for the patches to main repo first?

Some Input and a code review is appreciated!

[carlosz1986]

@systemcrash @robimarko @bevanweiss Sorry for bothering you again :-) Could you find some time till Saturday and share your thoughts to unblock me?
This would be highly appreciated :-)

[systemcrash]

What happens if this is merged, before the backports for openwrt? Nothing bad (like dependency wise)?

Could you elaborate on why the ethtool headers need to go in this way? They're a compile time thing right?

[bevanweiss]

What happens if this is merged, before the backports for openwrt? Nothing bad (like dependency wise)?

It should really wait for the OpenWRT backports. Otherwise the netlink attribute indexes might not align, which might result in incorrect values presented for PSE netifd requests (worst case), or errors when performing PSE netifd requests.

[carlosz1986]

it actually does not even compile...

so we need:

• backports from the other PR we discussed in the last 24
• some patching of the Makefile for headers and 1-2 smaller patches (take a look at my WIP branch)

I thought the order is:

1. Merge the PR for backports [done]
2. Open a PR for the smaller patches (netlink headers & ethtool adjustments) [done]
3. After getting (2) merged, Open a PR for the adjustments of the netifd package & Makefile [ready to review]
4. merge (3)
5. Merge this one - (this one should be proper already)

But regarding the approach I would love to get your input...

[carlosz1986]

Could anyone have a look at openwrt/openwrt#21918 ? From my point of view, this is required to merge this one...
The backports have been finished this weekend, thx to @hauke :-)
cheers

[carlosz1986]

I squashed the commits and cleaned up the commit message. I compiled it with current main branch and this PR which adapts the Makefile.
So if we finish the PR, we can merge this as well ...

[carlosz1986]

@robimarko or @systemcrash would you mind taking here the lead to get this done?
I don't know who else could help out....

This would move the needle for different other PRs that are depending on this...
thx in advanced

[systemcrash]

These changes look OK from where I am.