Bringing support for realtek-poe to mainline OpenWrt

walterav · June 23, 2022, 2:54pm

Testing fixed ports CI13 package and running all three commands ...21-28-2a in seperate batches with sleep while testing PoE device on different ports killed the strange behaviour for port 9 as in its status now always shows Disabled like ports 9-24 did before no matter connecting a PoE device. Also no Searching or Requesting power states for all these ports 9-24.

However ubus call poe poll-with-2a shows only for port 19 (although no PoE device connected) the Fault status and sometimes unknown but mostly Fault other ports 9-24 stay Disabled.

The first 8 ports keeps working the same as before, Searching and when PoE device connected it will jump to Requesting power.

hurricos · June 24, 2022, 6:06am

I have attached a PulseView recording of the serial line of a GS1900-24HPv1 running stock:

https://paste.c-net.org/DrivingBanish

mrnuke · June 24, 2022, 2:13pm

That trace taught me two things

I need to update the decoding script
I'm beginning to speak broadcom. Let me show you:
- 20 00 : "How are you?"
- 18 03 00 07 08 00 00: "Here's some money"
- 15 0D 03 01: "Don't spend it all in one place"

@walterav If you try to send the following packet, do you get any power from ports 1-4 ?

ubus call poe sendframe '{"frame" : "18 00 00 07 08 00 00"}'

walterav · June 24, 2022, 4:37pm

Tried this ubus call poe sendframe '{"frame" : "18 00 00 07 08 00 00"}' both on previous and current realtek-poe CI14 package but won't power on any of the PoE devices tried all 8 ports and some ports above. Also no 'other' status change in the ubus call poe info command besides the usual Searching / Requesting Power nor any lights led up on front of switch also dmesg stays empty of status changes.

However from the latest CI14 package the ubus call poe poll-with-XX commands are removed correct?

ubus call poe poll-with-21 #28/2a
Command failed: Method not found

walterav · June 24, 2022, 5:01pm

Also some info about cold-boot realtek-poe I haven't posted earlier.

Although the realtek-poe packages is installed and /etc/init.d/poe is started by default on coldboot it will most of time ~~always~~ show status unkown for all ports with ubus call poe info, no matter a PoE device is (re)connected or disconnected after coldboot. The status is frozen.

#cold boot default starts /etc/init.d/poe

ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 170.000000,
	"consumption": 0.000000,
	"ports": {
		"lan1": {
			"priority": 2,
			"status": "unknown"
		},
		"lan2": {
			"priority": 2,
			"status": "unknown"
		},
		"lan3": {
			"priority": 2,
			"status": "unknown"
		},
		"lan4": {
			"priority": 2,
			"status": "unknown"
		},
		"lan5": {
			"priority": 2,
			"status": "unknown"
		},
		"lan6": {
			"priority": 2,
			"status": "unknown"
		},
		"lan7": {
			"priority": 2,
			"status": "unknown"
		},
		"lan8": {
			"priority": 2,
			"status": "unknown"
		},
		"lan9": {
			"priority": 2,
			"status": "unknown"
		},
		"lan10": {
			"priority": 2,
			"status": "unknown"
		},
		"lan11": {
			"priority": 2,
			"status": "unknown"
		},
		"lan12": {
			"priority": 2,
			"status": "unknown"
		},
		"lan13": {
			"priority": 2,
			"status": "unknown"
		},
		"lan14": {
			"priority": 2,
			"status": "unknown"
		},
		"lan15": {
			"priority": 2,
			"status": "unknown"
		},
		"lan16": {
			"priority": 2,
			"status": "unknown"
		},
		"lan17": {
			"priority": 2,
			"status": "unknown"
		},
		"lan18": {
			"priority": 2,
			"status": "unknown"
		},
		"lan19": {
			"priority": 2,
			"status": "unknown"
		},
		"lan20": {
			"priority": 2,
			"status": "unknown"
		},
		"lan21": {
			"priority": 2,
			"status": "unknown"
		},
		"lan22": {
			"priority": 2,
			"status": "unknown"
		},
		"lan23": {
			"priority": 2,
			"status": "unknown"
		},
		"lan24": {
			"priority": 2,
			"status": "unknown"
		}
	}
}

However doing a /etc/init.d/poe restart after coldboot the poe info status responses will get active again as in the earlier posted Searching / Requesting power info.

Sadly this is not yet fixed CI14 package but happens inconsequent. Coldboot and reboot now initiate poe with current status with sometimes still the need to restart the service.

EDIT:
Although the PoE devices are powered on right now (see post 107)... the status can still be unknown after boot for all the ports and devices...

mrnuke · June 24, 2022, 5:58pm

poll-with-xx was only intended as a test, so we can quickly swap out poll methods. I thought it would be easier than testing 3 different packages.

The only other suggestion I can think of at this time is to try all the PSE budget commands with ubus call poe sendframe.

18 00 00 07 08 00 00
18 00 01 07 08 00 00
18 00 02 07 08 00 00
18 00 03 07 08 00 00
18 00 04 07 08 00 00
18 00 05 07 08 00 00
18 00 06 07 08 00 00
18 00 07 07 08 00 00

walterav · June 24, 2022, 6:36pm

@mrnuke @hurricos
OMG!!! Ports 1-2 with PoE device just powered on!!!

ubus call poe sendframe '{"frame" : "18 00 07 07 08 0
0 00"}'

ubus call poe info | head -n 45
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 170.000000,
	"consumption": 9.200000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Delivering power",
			"consumption": 4.200000
		},
		"lan2": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Delivering power",
			"consumption": 4.500000
		},
		"lan3": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan4": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan5": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan6": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan7": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan8": {
			"priority": 2,

However the PoE leds on the switch front panel are both off for port 1&2. Will try other ports 3-8.

EDIT:
Tested both a real 802.3af device a Netgear WNDAP360 and a passive Mikrotik HeX POE (rb960gsp).

mrnuke · June 24, 2022, 6:39pm

walterav · June 24, 2022, 6:48pm

Just tested ports 2-8 and (re)connecting the PoE devices on these ports also power on the devices !

However the ubus call poe status won't update the correct info status per port anymore after a couple of device swaps so it shows ports 1&6 are connected although port 2 and port 7 have a PoE device connected!

Will try higher ports 8-24 now.

EDIT:
Ports 8-24 stay on disabled, this means no PoE on connected device.

However another interresting find is doing a reboot of the switch will power off the PoE, but re-enables (turns them back on) very early just after all LNK/ACT/POE leds reset. Then the PoE devices will poweroff again during OpenWrt boot and then will turn on again without reapplying the sendframe command!

EDIT2:
Running /etc/init.d/poe restart although connected PoE devices were powered on, but status reporting is unknown for all ports (this happen sometimes after cold/re-boot), will poweroff and poweron all connected PoE devices but in this case won't fix the status reporting.

Will try a cold boot now...

EDIT3:
Just verified 2 cold-boots and the PoE on ports 1-8 really turn on only when running ubus call poe sendframe '{"frame" : "18 00 07 07 08 00 00"}' not the other 0-6 values!

walterav · June 24, 2022, 8:06pm

For the other 9-24 ports having PoE support, may we need 2 extra gpio-hog definitions in dts or does the info status reporting also has to be fixed?

mrnuke · June 25, 2022, 1:43pm

@svanheule What do you make of this packet with a pse_ctrl index of 7? There should only 6 BCM5911's on this switch.

I'm not sure if there could be more than one GPIO line. You could try toggling all GPIOs to one, but this might break other stuff. Here's the script that I used:

gist.github.com

https://gist.github.com/mrnuke/8911e9442de578822ab64f076d6ac7d4

unrealteg-gpio-test.sh

set_gpios() {
        local start="$1"
        local end="$2"
        local value="$3"

        for gpio_num in $(seq $start $end); do
                gpio="/sys/class/gpio/gpio$gpio_num"

                if [ ! -d "$gpio" ]; then
                        echo "$gpio_num" > /sys/class/gpio/export

This file has been truncated. show original

svanheule · June 25, 2022, 3:43pm

I got into the attic, wiped the dust off some boxes, and got out my old Ghidra projects.

From the kernel modules, it looks like stock FW will unconditionally loop over pse_ctrl values 0...7, sending the same value with each command. Can't find my decompiled MCU FW projects though, so not sure what I got from those.

The PoE disable GPIO goes to the MCU, so there should only be one line.

mrnuke · June 26, 2022, 9:06pm

That is very interesting. The vendor FW on my Engenius EWS2910P only uses `pse_ctrl' 0. It looks like we might have to use quirks.

github.com/Hurricos/realtek-poe

realtek-poe: Add PSE ID quirk for Zyxel GS1900-24HP-v1

Hurricos:realtek-poe ← Hurricos:mrnuke-more-power

opened 09:00PM - 26 Jun 22 UTC

mrnuke

+124 -115

The "set global power budget" command contains a PSE controller in its argument… list. This was hardcoded to 0. On some switches, commands to PSE 0 do nothing. In those cases, the set budget command won't stick. The power budget remains at its default value, usually 0. Because of this, ports remain stuck in the "Requesting power" state. To solve this, send the budget command to the correct PSE ID or set of IDs. Use a mask to encode which PSE IDs neet the set budget command. When the "compatible" devicetree string matches Zyxel GS1900-24HP-v1, set the mask to 0xff, to command PS ID's 0->7. The vendor firmware also uses ID's 0->7. This enables power delivery to PoE sinks. ![image](https://user-images.githubusercontent.com/2610559/175833634-515c98e6-65f3-45d5-a348-a4e7ef509a93.png) Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

walterav · June 27, 2022, 5:22pm

While still using CI14 realtek-poe package I can confirm that just a ubus call poe reload changes the port status for ports 9-24 from Disabled to Searching and after running ubus call poe sendframe '{"frame" : "18 00 07 07 08 00 00"}' (since I just cold-booted the switch) it shows status Delivering power and starts powering PoE devices on port 9-24 !

EDIT: just quickly tested all ports from 1-24 and they all power on PoE and show correct status for connected devices.

mrnuke · June 27, 2022, 5:35pm

Yup, it's a bug. I see it now. We configure the ports before we parse any replies, so we're configuring with the assumption that there are 8 config.ports. With poe reload, We've parsed a sysinfo packet, and we know we have more than 8.

walterav · June 28, 2022, 6:55am

Great progress CI22 realtek-poe package now has port 1 working out of the box after install (because default config file only has single port reference) and when adding the other 2-24 ports to the config file and doing a ubus call poe reload will start the other PoE devices without interrupting the first and shows correct poe info status. No need for the ubus call poe sendframe anymore !

Also doing a coldboot/reboot makes PoE devices on port 1&24 comeback on powered without the need for any service restarts or ubus reloads, although most of the time the status for all the ports is reported unknown while they do deliver PoE... Doing multiple ubus call poe reload or /etc/init.d/poe reload won't fix the status reports from unknown, however doing a /etc/init.d/poe restart will kill / reset power on all devices and fix the status info again from unkown to searching/delivering.

Individual PoE port leds on the switch itself are still off although delivering PoE power, but that may also be a problem for the 8/10 port models @bmork ?

bmork · June 28, 2022, 9:49am

Could very well be. Haven't checked. I'm mostly doing remote access to these switches. Will try to remember to take a look the next time I am close to one.

But I wouldn't be surprised if these LEDs need to be configured somewhere and we don't

EDIT: I was wrong. The PoE LEDs are working on the GS1900-10HP. They are all green on the active ports, indicating at power delivered. Which is correct.

tmomas · June 28, 2022, 6:40pm

9 posts were split to a new topic: DGS-1210 GPIO support

hurricos · July 3, 2022, 10:27pm

This is now fixed (as of commit 3fd90e7047473).

Go and try out CI#25!

walterav · July 4, 2022, 1:28pm

I think that issue was already fixed somewhere between CI14 and CI22 that the port status of 9-24 came up after the first 8 with an extra /etc/init.d/poe reload.