MikroTik RB5009UPr+S+IN — PoE not usable under OpenWrt despite hardware support

For Developers
1

Hi everyone,
I would like to draw attention to a situation that personally frustrates me and that I consider factually wrong.

After a long effort, hardware support for the MikroTik RB5009UPr+S+IN was recently merged into OpenWrt. That is good news — the device is now officially supported.

At the same time, the corresponding package mtpoe-ctrl, which controls the PoE ports of the device, was closed and rejected by the maintainer. The reasoning: there would be a better solution via the PSE-PD Linux kernel framework, and only a small number of users would be interested in the package.

I consider neither argument convincing.

The PSE-PD framework is, to my understanding, still a draft with no concrete timeline. And user interest simply cannot be measured — until now, no owner of this device could use the PoE ports under OpenWrt because the software was missing. Now that hardware support is in place, real interest is only just beginning to emerge.

The result is: the hardware is in, but the feature many users buy this device for — namely PoE — is not usable. That is not complete support.

I will step back after this post. My contribution was to bring the unfinished work of prudy and carlo2007 to a clean conclusion and submit it to OpenWrt. The actual code and foundational work come from adron-s, prudy and carlo — I brought it together, documented it and saw it through.

If anyone is also affected or misses the package: a comment in the closed PR #28731 would be the right way to signal interest.

Thanks to everyone who helped, especially adron-s, prudy and carlo2007

2

The PSE-PD framework "was agreed upon" by the kernel community.

This is not complete (is any kernel interface ?) but this interacts with ethtool and supports AF_NETLINK, later I suppose.

I saw some post (here ?) to support PSE-PD with UCI/LuCI and this is already in the build system.

Also the realtek switch people here are working on PSE-PD support.

So this is not a draft.

But anyway ..
The sources are a mess.
The real protocol (was) hidden mk_com.[ch], this transfers 10 bytes.

3

I was unaware that POE was not working for some people. POE in and POE out both work on mine and have been for over a year. Not sure what your issue could be.

4

The Pull request for device support can be found in OpenWrt Main PR #23698 (merged and closed).

  • The Pull request for adding mtpoe-ctrl package mentioned by OP can found in OpenWrt package PR #28731.

  • A separate effort to add PoE support using Linux PSE-PD framework on another Mikrotik device can be found in OpenWrt Main PR #23975 (in Draft phase).

5

The merged code brings nothing more than the support for the rejected code (maybe it shows the different model name). But it does not help, neither blocks the PSE-PD.

I do not know what is behind the decision to merge only half of the feature, which makes it zero usable. Was there no technical understanding of the feature in a whole, some internal conflict or whatever else? The arguments for rejecting the full working feature were complaining on:

  • cyrylic comments - yes, it's mtpoe author languge,
  • hardly readable code - it is not golden example of formatting, but all people making updates to it had no problems with reading and understanding,
  • openwrt does not want yet another POE handling solution because there already are 500 others - so I read it that those hundreds are sadly there, but no more!

Actually, there is no argument saying the code is wrong by functionality.

My clean proposition heading towards the users, not against them, was the nature ability of the development - taking the existing full working feature now and remove it when anything better is ready. If that ever happens before the router EOL, because who would spend time on it if mtpoe is working.

Summarising:

  • device supportis for mtpoe is merged,
  • 25.12 does not seem to include it yet,
  • there is no willing for mtpoe, even it works,
  • there is no alternative solution available now,
  • when/if the new relese includes abovementioned device support, then someone can publish mtpoe module built, matching that exact release version - this is quite nice as it brings the POE for the router and still mkes happy those who do not want it out of the box in openwrt.
6

So, at least, I suppose that if I apply the closed PR on top of my local OpenWrt repo and then I compile a build then the PoE is going to work, right.

7

POE in doesn't work on my RB5009UG+S+IN either, running OpenWrt 25.12.5 r33051. My Switch provides PoE++, so it should definitely work (but I haven't tested it when ROS7 was still installed..)

8

Your last point would mean that general users could use the device with full POE support very soon, which would be pretty nice! I see 5009upr is in snapshot currently, I imagine it makes sense to wait for the next service release before someone makes a build of mtpoe-ctrl available.

I haven't much experience in compiling from source, so this seems a good opportunity to do some learning and see if I can get it working myself in the meantime.