Maybe it has something to do with how the port status is requested? A port index of 0xff isn't valid, but there still appears to be a reply. The all-zero reply from from port 0 is also odd (if the port isn't actually set as disabled, that is)
Current findings are inline with @hurricos except I didn't read anything about how port 9 or higher functions in his situation.
I do have to say that I use "pseudo" POE devices currently a Mikrotik Hex-POE(rb960pgs) or Ubiquite AC MESH(uap-ac-m) which commonly work with dumb/passive POE and lower voltage as well. They do however auto power on by POE and work by running the ZyXEL OEM 2.70 firmware.
Later today I try a real 802.3af POE device Netgear WNDAP360.
Maybe @bmork his findings on enabling POE on 1900-10HP which uses slightly different BCM59121 vs BCM59111 (24HP/8HP) may give insight, however the GPIO pins he mentions are not available anymore:
That's because there is a gpio-hog in the dts, which just enables the poe by default now. But maybe they have used a different pin or somehting like that?
1 Like
Whipped up a little script to loop over all the lanX interfaces to populate /etc/config/poe, since by default only lan1 is set:
#!/bin/sh
# Scriptlet to populate /etc/config/poe based on available lanX port naming.
# Drawback: SFP ports are included too if they are named lanX.
for _PORT in $(uci get network.lan_vlan.ports)
do
uci add poe port
uci set poe.@port[-1].enable='1'
uci set poe.@port[-1].id="${_PORT/lan/}"
uci set poe.@port[-1].name="$_PORT"
uci set poe.@port[-1].poe_plus='1'
uci set poe.@port[-1].priority='2'
done
uci commit poe
Might help if we rename SFP ports to something else than lanX so for PoE purposes we can make an easy distinction. But that involves DTS changes as well AFAIK.
With @mrnuke's latest code, it seems to work okay here on my GS1900-8HP v1 with 22.03 HEAD, 2 PoE+ clients. @walterav My GS1900-8HP v1 has two older BCM59111KMLG controllers, my GS1900-10HP has the newer BCM59121B0KMLG.
# ubus call poe info
{
"firmware": "v17.1",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 65.000000,
"consumption": 6.700000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.500000
},
"lan2": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan3": {
"priority": 2,
"mode": "PoE+",
"status": "Disabled"
},
"lan4": {
"priority": 2,
"mode": "Legacy",
"status": "Searching"
},
"lan5": {
"priority": 2,
"mode": "PoE+",
"status": "Disabled"
},
"lan6": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan7": {
"priority": 2,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.300000
},
"lan8": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
1 Like
If building and running a custom OpenWrt build with this gpio-hog removed from the DTS will this automatically bring back a list of GPIO pins you had and worth triggering by manually echo 1 to it?
compatible = "realtek,rtl8231-gpio";
#gpio-cells = <2>;
gpio-controller;
indirect-access-bus-id = <0>;
poe_enable {
gpio-hog;
gpios = <13 GPIO_ACTIVE_HIGH>;
output-high;
};
};
Nice to see your progress on the 8HP but are you still using your earlier released realtek-poe package or already a newer compiled one?
md5sum Downloads/realtek-poe_2022-05-29-b07fbee9-1_mips_4kec.ipk
4d1978aea888b73f6ff45b4e3a36001a
This is the one I compiled this morning and have put up for download.
# opkg list-installed|grep realtek-poe
realtek-poe - 2022-05-29-b07fbee9-1
1 Like
That request looks okay to me:
- Hey, can I have request=0x2a, sequence id = 0x16, port = 0x00 ?
- Sure, here's request=0x2a, sequence id = 0x16, port = 0x00:
- port 0 is 0x11
- port 1 is 0x10
- et cetera.
Right, I should learn to read my own documentation:
Return the short status for eight ports, starting at the requested port.
The reply format was apparently documented incorrectly. Fixed that, and also updated the name of the first byte to first_port to make the sequence more obvious.
3 Likes
I think I figured out why the status shows as "unknown". It fixes the reporting, but not the power delivery aspect:
I've spotted found a few more realtek-poe bugs for devices with more than 8 ports. I would advise only testing the first 8 ports for the time being
@hurricos, should we start a matrix of which devices work/don't work, and what version of realtek-poe makes them happy?
1 Like
FWIW, the "get port status" command has enum status value 0x3 listed as "Test mode". If wonder if that corresponds to the classification stage, if that isn't already covered by "Searching".
Tested with the latest commits on the GS1900-8HP v1. Output below. Seems a bit hit and miss though, with the package I compiled this morning, the switch (which I powercycled multiple times today) came up with just one PoE+ client out of two. Seems all good again now.
Updated 2022-06-15-b07fbee9 package here.
# ubus call poe info
{
"firmware": "v17.1",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 65.000000,
"consumption": 7.100000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.400000
},
"lan2": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"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": "Disabled"
},
"lan7": {
"priority": 2,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.900000
},
"lan8": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
}
}
}
Do you know how to make github build packages automatically?
No, I don't. I just upload the packages from my local 22.03 buildroot. There should be a few community members familiar with GitHub's actions though...
Tested on my production GS1900-10HP in the meantime as well, only has PoE+ enabled on the first four ports. Looking good there as well.
Using your latest package I still get unknown in the POE status is that correct that its missing @mrnuke his patches?
Which ports show "unknown" ?
Like previous logs the port(s) that have a POE device connected 1-8. Should that be something like training or test-mode? Although the POE devices stay off.
I wouldn't expect ports with option id greater than 8 to show correct status. It's a known bug that we're not querying the status correctly. As to why ports don't output power, I'm not sure at this point.
This loop reads past the end of the packet:
for (i = 0; i < MAX_PORT; i++)
state.ports[i].status = GET_STR((reply[3 + i] & 0xf), status);
Looks like it does... The link pointed to the mrnuke-ufo-bug branch, and the newer package still got built from the default branch which does not have those extra commits.
Sorry!