Support for Zyxel GS1920 series (GS1920-24HP)

h3krn · September 8, 2025, 8:28pm

The SFP is detected if a module is plugged in and a link is detected on the native copper port if a cable is connected. Neither ports on the RTL8214FC seem to forward any traffic though
(I don’t have any fiber cables at home, so was not able to test a fiber SFP. But a copper SFP did not forward traffic)

andyboeh · September 14, 2025, 6:51pm

I added support for the fan controller today. The additional i2c bus 4 is now available, at 0x20 is the PoE MCU, at 0x2E is the ADT7468. It's supported by the LM85 module and manual fan control is working.

h3krn · September 15, 2025, 5:25pm

Build tested and confirmed for the GS2210-24LP.
This makes the W.A.F. skyrocket and for me makes it bearable to run it in the same room where my desktop is.

Thnx!

h3krn · October 5, 2025, 5:12pm

Today at the my local hackerspace during “Weekend van de wetenshap” I’ve attached a logic analyzer to the I2C pins coming from the motherboard to the PoE board. After some data manipulation and filtering with pulseview, this is what Zynos writes to the PoE controller (address 20) on system boot. Maybe this is helpfull to get PoE working?

564230-564230 I²C: Address/Data: Start
564234-564266 I²C: Address/Data: Address write: 20
564266-564271 I²C: Address/Data: Write
564271-564276 I²C: Address/Data: ACK
564276-564311 I²C: Address/Data: Data write: 17
564312-564316 I²C: Address/Data: ACK
564317-564353 I²C: Address/Data: Data write: 00
564354-564358 I²C: Address/Data: ACK
564359-564395 I²C: Address/Data: Data write: 01
564394-564399 I²C: Address/Data: ACK
564399-564434 I²C: Address/Data: Data write: FF
564435-564439 I²C: Address/Data: ACK
564440-564475 I²C: Address/Data: Data write: FF
564475-564479 I²C: Address/Data: ACK
564481-564517 I²C: Address/Data: Data write: FF
564516-564521 I²C: Address/Data: ACK
564521-564556 I²C: Address/Data: Data write: FF
564557-564561 I²C: Address/Data: ACK
564562-564597 I²C: Address/Data: Data write: FF
564597-564601 I²C: Address/Data: ACK
564602-564639 I²C: Address/Data: Data write: FF
564638-564643 I²C: Address/Data: ACK
564643-564678 I²C: Address/Data: Data write: FF
564679-564683 I²C: Address/Data: ACK
564684-564720 I²C: Address/Data: Data write: FF
564719-564724 I²C: Address/Data: ACK
564724-564759 I²C: Address/Data: Data write: 10
564760-564764 I²C: Address/Data: ACK
564767-564767 I²C: Address/Data: Stop
568965-568965 I²C: Address/Data: Start
568970-569001 I²C: Address/Data: Address read: 20
569001-569006 I²C: Address/Data: Read
569006-569011 I²C: Address/Data: ACK
569011-569053 I²C: Address/Data: Data read: 17
569052-569058 I²C: Address/Data: ACK
569056-569096 I²C: Address/Data: Data read: 00
569097-569102 I²C: Address/Data: ACK
569101-569141 I²C: Address/Data: Data read: 00
569141-569146 I²C: Address/Data: ACK
569146-569186 I²C: Address/Data: Data read: FF
569186-569191 I²C: Address/Data: ACK
569190-569230 I²C: Address/Data: Data read: FF
569231-569236 I²C: Address/Data: ACK
569235-569275 I²C: Address/Data: Data read: FF
569275-569280 I²C: Address/Data: ACK
569280-569320 I²C: Address/Data: Data read: FF
569320-569325 I²C: Address/Data: ACK
569324-569364 I²C: Address/Data: Data read: FF
569365-569370 I²C: Address/Data: ACK
569369-569409 I²C: Address/Data: Data read: FF
569409-569414 I²C: Address/Data: ACK
569414-569454 I²C: Address/Data: Data read: FF
569454-569459 I²C: Address/Data: ACK
569458-569498 I²C: Address/Data: Data read: FF
569499-569504 I²C: Address/Data: ACK
569503-569543 I²C: Address/Data: Data read: 0F
569543-569548 I²C: Address/Data: ACK
569548-569588 I²C: Address/Data: Data read: FF
569588-569593 I²C: Address/Data: NACK
569595-569595 I²C: Address/Data: Stop
569608-569608 I²C: Address/Data: Start
569613-569644 I²C: Address/Data: Address write: 20
569644-569649 I²C: Address/Data: Write
569648-569653 I²C: Address/Data: ACK
569654-569690 I²C: Address/Data: Data write: 15
569689-569694 I²C: Address/Data: ACK
569694-569731 I²C: Address/Data: Data write: 01
569730-569735 I²C: Address/Data: ACK
569735-569770 I²C: Address/Data: Data write: 00
569771-569775 I²C: Address/Data: ACK
569776-569812 I²C: Address/Data: Data write: 01
569811-569816 I²C: Address/Data: ACK
569816-569851 I²C: Address/Data: Data write: FF
569852-569856 I²C: Address/Data: ACK
569857-569893 I²C: Address/Data: Data write: FF
569892-569897 I²C: Address/Data: ACK
569897-569932 I²C: Address/Data: Data write: FF
569933-569937 I²C: Address/Data: ACK
569938-569973 I²C: Address/Data: Data write: FF
569973-569977 I²C: Address/Data: ACK
569979-570015 I²C: Address/Data: Data write: FF
570014-570019 I²C: Address/Data: ACK
570019-570054 I²C: Address/Data: Data write: FF
570055-570059 I²C: Address/Data: ACK
570060-570096 I²C: Address/Data: Data write: FF
570095-570100 I²C: Address/Data: ACK
570100-570135 I²C: Address/Data: Data write: 10
570136-570140 I²C: Address/Data: ACK
570143-570143 I²C: Address/Data: Stop

I also made a dump of plugging in a PoE device. But that’s slightly more data (1620 lines).

hailfinger · October 5, 2025, 6:04pm

I have a spare Zyxel GS1920-48HP (first generation, it seems) at home. Don’t care if it is being temporarily bricked. Any tests/dumps I should run?

hailfinger · October 5, 2025, 6:10pm

Could you link to that I2C dump (or even a complete trace from poweron), please? The log above is surprisingly short for a PoE init during bootup.

andyboeh · October 5, 2025, 6:28pm

@h3krn @hailfinger
Before you invest more time in dumping the communication, could you check if this old PR still works? If yes, we just have to port it according to my question here.

hailfinger · October 5, 2025, 9:37pm

I’ll have to adapt the DTS to my 48-port model before testing POE.

h3krn · October 5, 2025, 9:59pm

@andyboeh I’ve pulled those two files from the PR and rebuild. But wont be able to test today as the current install does not seem to have i2c chardev enabled. I’ll try in the coming week though.

@hailfinger, sure I can share or even redo the capture if needed, in case it got truncated while exporting from the logicanalyzer. The whole “trying to use a logic analyzer and convert to i2c syntax with pulsview” has been a fun and interesting new experience. So I don’t mind redoing it.
But I’ll first try @andyboeh ‘s suggestion.

h3krn · October 6, 2025, 10:59am

Unfortunately PoE does not light up using realtek-poe build from that old PR

config global
    option budget	'180'
    option i2c_bus  '4'

config port
    option enable   '1'
    option id	    '1'
    option name     'lan01'
    option poe_plus	'1'
    option priority	'2'
root@OpenWrt:/etc/config# realtek-poe
realtek-poe: Failed to add object: Invalid argument
realtek-poe: Using I2C bus #4: /dev/i2c-4
realtek-poe: Setting I2C slave address to 20

Maybe the config I’m using is invalid? (The Invalid argument error it gives?)

andyboeh · October 6, 2025, 11:41am

You should be able to run realtek-poe with -d and check logread for details. The error message with invalid argument is from the ubus connect handler - it fails to connect to ubus. That shouldn't be a problem for the basic functionality.

h3krn · October 6, 2025, 12:17pm

root@OpenWrt:~# realtek-poe -d
realtek-poe: Failed to add object: Invalid argument
realtek-poe: Using I2C bus #4: /dev/i2c-4
realtek-poe: Setting I2C slave address to 20
realtek-poe: I2C TX -> 20 01 ff ff ff ff ff ff ff ff ff 18
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 17 02 02 ff ff ff ff ff ff ff ff 13
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 02 03 00 ff ff ff ff ff ff ff ff fd
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 18 04 00 07 08 00 b4 ff ff ff ff db
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 13 05 7f 02 ff ff ff ff ff ff ff 92
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 10 06 7f 03 ff ff ff ff ff ff ff 91
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 1a 07 00 02 ff ff ff ff ff ff ff 1c
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 1c 08 00 03 ff ff ff ff ff ff ff 20
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 11 09 00 01 ff ff ff ff ff ff ff 14
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 15 0a 00 01 ff ff ff ff ff ff ff 19
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 00 0b 00 01 ff ff ff ff ff ff ff 05
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 23 0c ff ff ff ff ff ff ff ff ff 26
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 28 0d 00 01 01 01 02 01 03 01 ff 3e
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 26 0e 00 ff ff ff ff ff ff ff ff 2c
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 30 0f 00 ff ff ff ff ff ff ff ff 37
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum

The last four TX/RX messages then keep repeating.
Logread outputs one line over and over again:

Thu Jan  1 01:25:18 1970 daemon.notice realtek-poe: Could not complete I2C send/receive, messages sent: -1
Thu Jan  1 01:25:20 1970 daemon.notice realtek-poe: Could not complete I2C send/receive, messages sent: -1
Thu Jan  1 01:25:22 1970 daemon.notice realtek-poe: Could not complete I2C send/receive, messages sent: -1

andyboeh · October 6, 2025, 1:30pm

Uh, that doesn't look good. It's only replying with 0xff's!?

bmork · October 6, 2025, 2:04pm

It probably fails to send the read message since this ioctl() fails:

nmsgs_sent = ioctl(i2c_file, I2C_RDWR, &rdwr);
if (nmsgs_sent != 2)
	ULOG_NOTE("Could not complete I2C send/receive, messages sent: %d\n", nmsgs_sent);

Maybe log errno too when this is negative?

I don’t know if it matters, but I noticed that the code behaves slightly different from the logic analyzer trace. The code tries to do a single write+read transaction, while the trace shows two distinct i2c transactions (if my interpretation of “Stop” is correct).

h3krn · October 6, 2025, 10:32pm

Sorry that log line was a red herring.
I didn't notice procd restarted a new copy of realtek-poe in the background after I killed it. Disabling the service makes those lines go away. Leaving these:

Thu Jan  1 11:35:26 1970 daemon.info realtek-poe: Using I2C bus #4: /dev/i2c-4
Thu Jan  1 11:35:26 1970 daemon.info realtek-poe: Setting I2C slave address to 20
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: I2C TX -> 20 01 ff ff ff ff ff ff ff ff ff 18
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: received reply with bad checksum
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: I2C TX -> 17 02 02 ff ff ff ff ff ff ff ff 13
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: received reply with bad checksum
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: I2C TX -> 02 03 00 ff ff ff ff ff ff ff ff fd
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: received reply with bad checksum
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: I2C TX -> 18 04 00 07 08 00 b4 ff ff ff ff db
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: received reply with bad checksum
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: I2C TX -> 13 05 7f 02 ff ff ff ff ff ff ff 92
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
Thu Jan  1 11:35:26 1970 daemon.debug realtek-poe: received reply with bad checksum
...

andyboeh · October 7, 2025, 5:16am

I would try to use i2c-tools now:

is the device detected via i2cdetect?
perform a transfer via i2ctransfer and/or i2cset/i2cset

Just to rule out the device/the i2c implementation.

h3krn · October 11, 2025, 5:29pm

i2cdetect, i2cset and i2cget seemed to give valid responses.
Based on @bmork 's suggestion I altered the poe_i2c_cmd_send function a bit to this.

static int
poe_i2c_cmd_send(struct cmd *cmd, unsigned char *reply, int len)
{
	log_packet(LOG_DEBUG, "I2C TX ->", cmd->cmd);

	if (write(i2c_file, cmd->cmd, 12) != 12) {
		ULOG_NOTE("Could not complete I2C send\n");
	}
	if (read(i2c_file, reply, len) != len) {
		ULOG_NOTE("Could not complete I2C receive\n");
	}
	return 0;
}

Now it looks like at least some commands are send and received:

root@OpenWrt:~# ./realtek-poe -d
realtek-poe: H3K filename: /dev/i2c-4
realtek-poe: Using I2C bus #4: /dev/i2c-4
realtek-poe: Setting I2C slave address to 20
realtek-poe: I2C TX -> 20 01 ff ff ff ff ff ff ff ff ff 18
realtek-poe: RX <- 20 01 02 18 00 e1 11 11 00 01 01 40
realtek-poe: I2C TX -> 17 02 02 ff ff ff ff ff ff ff ff 13
realtek-poe: RX <- ff ff ff ff ff ff ff ff ff ff ff ff
realtek-poe: received reply with bad checksum
realtek-poe: I2C TX -> 02 03 00 ff ff ff ff ff ff ff ff fd
realtek-poe: RX <- 17 02 00 ff ff ff ff ff ff ff ff 11
realtek-poe: received reply with bad command id
realtek-poe: I2C TX -> 18 04 00 07 08 00 b4 ff ff ff ff db
realtek-poe: RX <- 18 04 00 00 ff ff ff ff ff ff ff 15
realtek-poe: I2C TX -> 13 05 7f 02 ff ff ff ff ff ff ff 92
realtek-poe: RX <- 13 05 7f 00 ff ff ff ff ff ff ff 90
realtek-poe: I2C TX -> 10 06 7f 03 ff ff ff ff ff ff ff 91
realtek-poe: RX <- 10 06 7f 00 ff ff ff ff ff ff ff 8e
realtek-poe: I2C TX -> 1a 07 00 02 01 02 02 02 03 02 ff 2e
realtek-poe: RX <- 1a 07 00 00 01 00 02 00 03 00 ff 26

And as a cherry on top it does seem to recognize the PoE accesspoint I connected. It is not yet actually powering on though

root@OpenWrt:~# ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 180.000000,
	"consumption": 0.000000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Requesting power"
		},
		"lan2": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		"lan3": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},

andyboeh · October 11, 2025, 7:14pm

Yeah, seems like some commands are working and some aren't. We'll need an i2c trace to figure out what's required, but at least we have something to work on.

As a side note: the zynsig utility is now part of firmware-utils, so I'll submit a PR for the GS1920-24HP soon. PoE and SFP will be missing, but the rest seems rather complete now.

jonasj · October 11, 2025, 7:27pm

Great, thanks! My GS1920-24HP is sadly collecting dust here due to lack of time. But I’ll be available to test your PR then, and can hopefully use your work for another Zyxel device then.

andyboeh · October 12, 2025, 8:43pm

I think that the controller is slower than the read: Notice that the reply to the command starting with 0x17 is received when the next command is sent? So it seems as if it was basically working, but requires not only porting, but also fixing.