24 or 48 Port PoE+ Switch

you usually get the pre OS, boot loader access.

The only difference is the voltage. There is no RS232 level shifter here. You connect directly to 3.3V TTL IO pins. But that's one important difference to be aware of....

Never connect a regular RS232 port to a TTL header. Use a USB TTL UART cable.

1 Like

Exactly. Or rather this one, since we were talking specifically about the 24HPv2: https://wikidevi.wi-cat.ru/File:GS1900-24HPv2-Console-header.jpg

1 Like

Hah! I was wondering about the "front to back" in the commit message, thinking "Where is 'front' on a vertical connector?", thinking, you meant "board-side".

I had looked for a openwrt wiki page for the 24HPv2, but didn't find one, and assumed, the header was in the same orientation.

Yes, but it's still not very well tested. Which is why you might want to have simple access to console as a security net. You can always gamble that you won't need it, and delay buying a cable until it is necessary.

I have verified that installation from OEM works on the ZyXEL GS1900-10HP and the Netgear GS108Tv3. I am pretty sure the same method should work with any of the ZyXEL switches at least. The trick is to flash the OpenWrt initramfs image from the OEM web GUI, and then sysupgrade OpenWrt after booting from the initramfs.

Do not try to flash the sysupgrade image directly from the OEM web GUI. The OEM flasher will silently corrupt the image, leaving you with a soft brick. And then you need console - which will allow this to be easily fixed.

The ZyXEL sysupgrade images are supposed to be made so that they are rejected by the OEM firmware but don't trust this. It's not like that for other brands like the Netgear. They will accept and corrupt sysupgrade images.

So always do the two-step first time installation on the realtek switches. initramfs from OEM first, and then sysupgrade from OpenWrt.

But there is currently a bug in the image creation code for the ZyXELs, so installing from OEM web GUI is broken. This is fixed by https://patchwork.ozlabs.org/project/openwrt/patch/20210624210408.19248-1-bjorn@mork.no/ which ahs been stuck in patchworks for a while. Don't know why.

I have a GS308T, flashed a few weeks ago without serial, unopened.

Install must have worked painlessly on first try with whatever instructions for the 2-step-maneuver were on the Openwrt wiki at the time for that device (family?), because I don't remember details.

I am now wondering, what will happen if I flash a PoE switch with a supported Realtek chipset, but an unsupported poe chipset? Will POE still work and function, but we just won't have any control or reporting until added?

If it's built internally like this one

You could perhaps try running the switch with the POE disconnnected if you fear damage, or malfunction.

Personally though, my first intuition would be following default behaviour: No passive POE by default, unless port specifically marked as such. Active POE (= after negotiation) by default enabled on all supplied ports.

But I would still test that, before I hookup something valuable. :wink:

The PoE feature is unrelated to the realtek SoC. Most (all?) of these switches implement it using a standalone microcontroller with its own firmware, using a UART to communicate with the realtek SoC. So the SoC sees the PoE system simply as another serial port. This and the protocol used by many of these microcontroller firmwares is described in detail here: https://biot.com/switches/software/poe_management

So far, we've depended on userspace application(s) to talk to the microcontroller firmware. Without this, the microcontroller will just boot up with whatever defaults it has. We can assume these defaults are safe. That's probably one of the major reasons for this design, making PoE management work sanely regardless of SoC state and software.

Some of the switches, like the ZyXEL GS1900-10HP use a GPIO as a PoE "master control" switch. I have no idea how that is connected. Someone(tm) should figure it out, I guess. Could go to a microcontroller reset or a power relay or maybe something else. This GPIO is currently unconditionally enabled on the ZyXEL GS1900 using a "poe_enable" gpio-hog in the DTS.

Thanks for this link, awesome website. Who manages and maintains this biot.com website? On the site it lists: Broadcom PoE platform, you will need the rtl83xx-poe package in order to use PoE

From the sounds of it, RTL based switches with Broadcom PoE is fully supported in openwrt. The question is, are any of the other brands of PoE chipsets also supported by OpenWRT at this time, or being worked on?

That is good. So what you are saying is it doesn't really matter that openwrt does not support the poe chipset, it should still offer poe if that is the default setting on the poe controller. We just won't be able to see the poe output stats, disable Poe, or anything else until support is built for that poe microscontroller in openwrt right?

Well, sort of. There have been two userspace daemon implementations by @blogic - one wrtiten in lua and one in C. None of them are merged yet. So formally there is no support in OpenWrt. But you still run any of them on OpenWrt without too much trouble since they are just userspace software communicating with the hardware using a serial port exposed by the kernel.

I wouldn't describe it as "fully supported", though.

The current C code (which is most likely the code base whatever final version will be based on), does not implement dynamic on/off or any other control knobs. It configures the controller based on a static config file and provides statistics. That's all. The older lua version had dynamic on/off per port in addition.

Sample output from the C daemon:

root@gs1900-10hp-f:~# ubus call poe info
{
        "firmware": "v22.4",
        "mcu": "ST Micro ST32F100 Microcontroller",
        "budget": 77.000000,
        "consumption": 14.800000,
        "ports": {
                "lan1": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Searching"
                },
                "lan2": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Searching"
                },
                "lan3": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Searching"
                },
                "lan4": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Searching"
                },
                "lan5": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Searching"
                },
                "lan6": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Delivering power",
                        "consumption": 4.100000
                },
                "lan7": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Delivering power",
                        "consumption": 4.100000
                },
                "lan8": {
                        "priority": 0,
                        "mode": "PoE+",
                        "status": "Delivering power",
                        "consumption": 6.700000
                }
        }
}

More features can easily be added since the protocol is documented. But there is an ongoing discussion about the userspace API. This needs to be resolved before there is any point adding more features or merging anything.

1 Like