Hi!
I'm wondering what the status of PoE support is on the ZyXEL GS1900-24HP v2 Switch (v2) these days when running OpenWrt?
I'm having some difficulty keeping a couple of PoE powered WAPs powered on plugged into this switch. If I do a hard reboot of the switch they seem to power on but eventually one drops out and then the other seems to come and go.
I have installed the realtek-poe package but I was unable to find much in the way of documentation for the /etc/config/poe file and when running the ubus call poe info command I don't seem to get valid data back:
{
"firmware": "v0.0",
"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"
}
}
}
I'm currently running OpenWrt 23.05.2 on this switch.
Thanks!
-Ben
That looks like it's probably the same problem that exists on the GS1900-10HP v2 (Rev. B1) and some of the other newer revision devices. They appear to have changed the connections in hardware, so the old settings for talking to the PoE system no longer work properly.
Although I've seen reports of people working on it, no working solution has yet made it into the release.
If you're having issues keeping PoE devices running, I recommend removing the manually installed realtek-poe package, gracefully shutting down the switch via ssh, and then unplugging the switch and performing a cold reboot. At least on the 10HP v2, warm reboots won't properly undo whatever the realtek-poe package does and it takes a full cold boot for things to stabilize.
Everything is working fine on mine. It's in daily use for over a year, none of the PoE devices ever had an outage that I remember.
However, this is what ubus call poe info reports (truncated):
{
"firmware": "v16.1",
"budget": 170.000000,
"consumption": 43.000000,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.300000
},
"lan2": {
"priority": 2,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.500000
},
"lan3": {
"priority": 2,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 1.700000
},
This is how my /etc/config/poe file looks like (truncated):
config global
option budget '170'
config port
option enable '1'
option id '1'
option name 'lan1'
option poe_plus '1'
option priority '2'
config port
option enable '1'
option id '2'
option name 'lan2'
option poe_plus '1'
option priority '2'
config port
option enable '1'
option id '3'
option name 'lan3'
option poe_plus '1'
option priority '2'
config port
option enable '0'
option id '4'
option name 'lan4'
option poe_plus '1'
option priority '2'
config port
option enable '1'
option id '5'
option name 'lan5'
option poe_plus '1'
option priority '2'
I have a GS1900-24HP v1 and five GS1900-24HP v2 switches. Identical /etc/config/poe on both models (the one shown by @andyboeh ).
The v1 switch works perfectly and "ubus call poe info" returns useful info.
The v2 switches have the problem mentioned by @BenFranske where the firmware version is shown as "v0.0". Enabling debugging in realtek-poe shows that the PoE controller never replies to the 0x20 "Get system info" command as listed in https://svanheule.net/switches/software/broadcom_poe_control_protocol#get_system_info . I tried both OpenWrt 23.05.2 and 23.05.3 with no difference.
The v2 switches were delivered with OEM firmware version 2.70. I flashed one with OpenWrt directly and upgraded the other one to OEM firmware 2.80. Both exhibit the same problem. The OEM firmware changelog mentions that downgrading the firmware to an older version will result in non-working PoE.
Multiple Ideas what the root cause of the problem may be:
- Newer OEM firmware updates the PoE controller firmware to a version incompatible with the command set or UART settings used by OpenWrt
- Maybe there are multiple GS1900-24HPv2 variants? Mine is labeled "Rev. B1".
- Maybe I'm not using the same OpenWrt version as @andyboeh
Is there an easily accessible set of pins I can use to sniff the traffic between RTL8382M and the PoE controller? Preferably without requiring fine-pitch soldering (I'd have to ask a colleague to do that).
As an alternative, does anyone know which component in the original firmware takes care of PoE controller communication so I can trace/disassemble that?
@andyboeh do you remember the stock firmware version you had prior to flashing OpenWrt? Do you know which pins carry the serial line between the RTL838x and the PoE microcontroller?
No, sorry, I didn't pay attention to the stock firmware at all.
As for the Pins: According to this, it's Pins 21 and 22 on the STM32 controller. You should be able to trace these pins to one of the connectors, but I never had the need to do so.