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!
I did test the first 1-8 ports, but like borro mentionend your ufo code is not in yet.
BTW I also tested with a "real 802.3af" Netgear wndap360 instead of the pseudo POE devices from Mikrotik/Ubiquiti.
Can you try with the the package from the github link below? I'm not sure if passive PoE devices will work with the way we are configuring the PSE. If that's something that works with the vendor firmware, but not with realtek-poe, then I'd consider it a bug.
I've also tried to make IPKs build automatically.
2 Likes
Those passive Mikrotik and UBNT do work out of the BOX on ZyXEL stock firmware.
Right now it shows Requesting power instead of unknown for 1st-8th port with Netgear WNDAP360 POE device connected with your github released package and default poe config file. Will try other ports above 8 soon!
$ md5sum realtek-poe_1_mips_4kec.ipk
2fe4225e2e08b193f21227756b103c50 realtek-poe_1_mips_4kec.ipk
$ opkg install realtek-poe_1_mips_4kec.ipk
Installing realtek-poe (1) to root...
Configuring realtek-poe.
$ ubus call poe info
{
"firmware": "v17.1",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 170.000000,
"consumption": 0.000000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
}
}
}
$ ubus call poe info
{
"firmware": "v17.1",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 170.000000,
"consumption": 0.000000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Requesting power" <------------------- :-D
}
}
}
EDIT: port 9-16
ubus call poe info
{
"firmware": "v17.1",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 170.000000,
"consumption": 0.000000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"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": "Searching"
},
"lan7": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan8": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan9": {
"priority": 2,
"mode": "PoE",
"status": "unknown" <--- With or Without POE device attached
},
"lan10": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan11": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan12": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan13": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan14": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan15": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan16": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
}
}
}
Notice port9 status unknown like earlier reported that port 9 just behaves differently Other Fault... The other ports just stay at status Disabled.
EDIT2:
Port 9 flaps quickly from Requesting power to Delivering power to unknown to fault instead of other fault to Disabled the POE device however won't turn on! By the way the PoE and LNK/ACT leds on ZyXEL switch for those corresponding ports also stay off while this status flapping is happening.
It does seem that port 9 does more than ports1-8 except that these ports above 8 stay disabled except for 9...
EDIT3
Also notice that ports 9-24 show POE instead of POE+ although the config states Poe+...
$ ubus call poe info
{
"firmware": "v17.1",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 170.000000,
"consumption": 0.000000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"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": "Searching"
},
"lan7": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan8": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan9": {
"priority": 2,
"mode": "PoE",
"status": "Delivering power" <--- Sadly doesn't power only flaps
},
"lan10": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan11": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan12": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan13": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan14": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan15": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan16": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan17": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan18": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan19": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan20": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan21": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan22": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan23": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan24": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
}
}
}
After installing Hurricos commits up to 29may in my own poe distro the total consumption now calculates the total power sum right.
So that bug seems to have been handled😃
1 Like
That is still a known bug. The following commit might fix it.
I'm still clueless as to why it's not delivering power.
https://github.com/Hurricos/realtek-poe/actions/runs/2524492350
Just tried your last package and the status on port 9 and higher is broken as in no change when connecting PoE device.
However port 19 now continously reports Requesting power although no PoE device connected, and port 24 shows Searching (also nothing connected) all the other 8+ ports show Disabled.
$ md5sum /tmp/realtek-poe_1_mips_4kec.ipk
b17280183ca65add8bf7a5a833b1d9ae /tmp/realtek-poe_1_mips_4kec.ipk
$ ubus call poe info
{
"firmware": "v17.1",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 170.000000,
"consumption": 0.000000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"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": "Searching"
},
"lan7": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan8": {
"priority": 2,
"mode": "PoE+",
"status": "Searching"
},
"lan9": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan10": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan11": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan12": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan13": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan14": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan15": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan16": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan17": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan18": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan19": {
"priority": 2,
"mode": "PoE",
"status": "Requesting power"
},
"lan20": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan21": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan22": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan23": {
"priority": 2,
"mode": "PoE",
"status": "Disabled"
},
"lan24": {
"priority": 2,
"mode": "PoE",
"status": "Searching"
}
}
}
EDIT:1
Also tried your package from 5 hours ago with same outcome as above.
I was hoping to use get_port_overview command to get status for ports > 8, but that obviously doesn't work. Your switch has the same PSE chips and MCU as mine, so I'm not sure what's going on.
Next step would be to get a serial dump of the commands the vendor firmware sends to the MCU.@hurricos, are you any closer to an update on that?
BTW, here's a support matrix of what's going on so far:
The get_port_overview command is marked as deprecated though, if only I had added why...
If the overview command working for you with high port numbers? Otherwise you could try the get_all_port_status command.
1 Like
@mrnuke Could you adapt the GitHub wiki to include the PSE chips for the following ZyXEL models?
- GS1900-8HP v1: 2x BCM59111KMLG (so BCM59111)
- GS1900-10HP: 1x BCM59121B0KMLG (so BCM59121)
1 Like
Tried your recent cleanup code round1 realtek-poe CI11 package on GS1900-24HPv1 with the same results as before.
No regressions for ports 1-8 as status concerns, same with abscent detection for ports 8+ till 24, with port 9 still being the strange one reporting Delivering Power and the other states when a PoE AP is connected.
The cleanup PR doesn't have bug fixes. However, I have something we can test There are three new commands in the image below, corresponding to the different ways to poll ports.
Can you let me know if any of the poll methods work correctly for your switch?
ubus call poe poll-with-21
ubus call poe poll-with-28
ubus call poe poll-with-2a
Usage example:
# ubus call poe poll-with-28
# sleep 2
# ubus call poe info