Upgrading/Debricking ZyXEL GS1900-8 V1

I have a ZyXEL GS1900-8 V1 running OpenWrt 21.02.1, r16325-88151b8303 on it.
In this state, for me it seems to be "bricked".

I have access to serial console, which shows me, that OpenWRT is booting and should be reachable via 192.168.1.1 but it is not.
I performed "firstboot && reboot", which did not help.

So I tried upgrading to a newer OpenWRT image over the serial connection.
This is something I already did successfully on a ZyXEL XGS1250-12 V1.
But in this case it fails.

python serio.py -s ~/openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v1-squashfs-sysupgrade.bin -d /tmp/openwrt.bin -p /dev/ttyUSB0

root@OpenWrt:/# sysupgrade -n /tmp/openwrt.bin 
Sun Oct 24 20:43:40 UTC 2021 upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.0->2.0).
Sun Oct 24 20:43:40 UTC 2021 upgrade: Dual firmware paritition merged due to size constraints. Upgrade requires a new factory install. Regular sysupgrade is not possible.
Image check failed.

That particular check can be circumvented by --force (so sysupgrade --force -n /tmp/openwrt.bin), just make very sure that the uploaded checksum is correct (compare the sha256sum!).

Alternatively you could tftpboot the 24.10.1 initramfs image and sysupgrade from there, see e.g. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=c4bfe68c83910e613f07350587a8709a16bd1ffa.

EDIT: While having serial console accessy you can also check the chipset revision of your switch to determine if you could use the v2 image or need to stick to the v1 image, see the discussion around https://github.com/openwrt/openwrt/issues/9534#issuecomment-2604471064, see https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7322d3266d84ec4062046254792d78ebca3ea26d for the advantages.

I did not force it, because I thought, it might brick the device even further. Sure this will work, even when coming from OpenWrt 21.02.1?

Sending the file over serial failed two times, only the third time it went through. Comparison of checksums was mandatory anyway, but seeing this made me doublecheck.

I am not sure if i could use the V2 image. How to determine if i have a RTL8380M rev. B or C?

You have serial console access, if you use that to tftpboot a 24.10.x image, you won't need to force anything.

The details for determining rev A or rev B/ C are laid out in the linked issue thread, yes, it's a tad longer, you should read it and ask again with the results you get from reading out the values. As you currently have serial console access, this is easy to determine right now.

And you did try this on vlan 100 on port lan1?

Don't remember exactly when that default changed but your OpenWrt is probably old enough to have the management interface on vlan 100

1 Like
RTL838x# mw.l bb000058 3
RTL838x# 
RTL838x# mw.l bb0000d8 a0000000
RTL838x# 
RTL838x# md.l bb0000d0 4
bb0000d0: 00000003 83806800 a0036275 00000016    ......h...bu....
R

According to this I have a Rev.C board.
So I will use the V2 image from now on.

No I did not try VLAN 100 on Port1. I must have used it a few years ago that way.
Because I can connect to LUCI after setting up my client accordingly.

I tried a sysupgrade with openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v1-squashfs-sysupgrade.bin and openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-squashfs-sysupgrade.bin while enforcing the upgrade and ignoring the warning.
Both attempts failed, but both times, the router came up as before.

Now I am trying to get the kernel image running via tftp. But this also fails for me.
I can ping the Switch (ping 192.168.1.1), the switch can ping my client (ping 192.168.1.2).

rtk network on
ping 192.168.1.2
host 192.168.1.2 is alive
tftpboot 0x84f00000 192.168.1.2:openwrt-24.10.1-realtek-
rtl838x-zyxel_gs1900-8-v2-initramfs-kernel.bin

On the client i use atftp:

atftp --trace --option "timeout 1" --option "mode octet" --put --local-file openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-initramfs-kernel.bin 192.168.1.2
Trace mode on.
Option timeout = 1
Option mode = octet
sent WRQ <file: openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-initramfs-kernel.bin, mode: octet <timeout: 1>>
timeout: retrying ...

The partition layout changed in 24.10., you cannot use the sysupgrade image directly from any previous release. You need to sysupgrade to an initramfs version (this needs to be enforced) and then flash the sysupgrade image from there. Or tftpboot the initramfs image and sysupgrade from there.

I have good experience with tftpd-hpa. However, it should also work with atftpd (note the d). The switch request the image via TFTP, i.e. it is the client. Your command assumes that the switch is the TFTP server (which it isn't).

Instructions: https://openwrt.org/docs/guide-user/troubleshooting/tftpserver#atftpd_on_linux

I managed to load openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-initramfs-kernel.bin to the switch with atftpd.
It booted, I used scp to transfer openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-squashfs-sysupgrade.bin over to the switch.

Then I ran sysupgrade /tmp/openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-squashfs-sysupgrade.bin

The switch boots up with the old firmware afterwards. What is going on?

Again I did not read/follow the instructions completely. Initially I did not change the boot partition. Now I tried again:

# Use atftpd to transfer a file over to the switch
https://openwrt.org/docs/guide-user/troubleshooting/tftpserver#atftpd_on_linux
$ doas cp openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-initramfs-kernel.bin /srv/atftp
$ doas atftpd --daemon --no-fork --group nobody --logfile - /srv/atftp

# Reset Switch and press Space to interupt boot process
RTL838x# setsys bootpartition 0
RTL838x# savesys
RTL838x# rtk network on
RTL838x# tftpboot 0x84f00000 192.168.1.2:openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-initramfs-kernel.bin
RTL838x# bootm
$ scp -O openwrt-24.10.1-realtek-rtl838x-zyxel_gs1900-8-v2-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/
openwrt-24.10.1-realtek

Now my Zyxel GS1900-8 V1 (Chipset Rev. C) works like expected with the brand new OpenWRT 24.10.1.
This is amazing.
Still I do not fully understand what some of those RTL838x commands are really doing.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.