Any experts here who could help with a build for Zyxel GS1900-16 please?
@RaylynnKnight has worked on device support for this model at https://github.com/RaylynnKnight/openwrt/tree/ZyXEL_GS1900-16, but it's not yet merged into OpenWrt/ master (nor submitted as PR/ patch series on the mailing list) yet. That means you'll have to build it from source, pulling in the changes from that branch into master, and start testing it. You probably (really) want serial console access at this point and the ability to fine-tune/ rebuild on the source level as needed.
1 Like
Thanks. I've been in touch with @RaylynnKnigh but he is (understandably) busy with life. I am looking for someone with build skills and who can help debug/fix issues when we run into them.
Have a go with
just replace/ augment steps 2.1 and 2.2 with
$ git clone https://git.openwrt.org/openwrt/openwrt.git
Cloning into 'openwrt'...
remote: Enumerating objects: 567392, done.
remote: Counting objects: 100% (567392/567392), done.
remote: Compressing objects: 100% (149334/149334), done.
remote: Total 567392 (delta 395908), reused 565238 (delta 394532)
Receiving objects: 100% (567392/567392), 167.21 MiB | 24.78 MiB/s, done.
Resolving deltas: 100% (395908/395908), done.
$ cd openwrt/
$ git pull https://github.com/RaylynnKnight/openwrt/ ZyXEL_GS1900-16
remote: Enumerating objects: 44, done.
remote: Counting objects: 100% (24/24), done.
remote: Total 44 (delta 23), reused 23 (delta 23), pack-reused 20
Unpacking objects: 100% (44/44), 9.66 KiB | 824.00 KiB/s, done.
From https://github.com/RaylynnKnight/openwrt
* branch ZyXEL_GS1900-16 -> FETCH_HEAD
Merge made by the 'recursive' strategy.
package/boot/uboot-envtools/files/realtek | 7 ++++---
target/linux/realtek/dts/rtl8380_zyxel_gs1900-16.dts | 36 ++++++++++++++++++++++++++++++++++++
target/linux/realtek/image/Makefile | 7 +++++++
3 files changed, 47 insertions(+), 3 deletions(-)
create mode 100644 target/linux/realtek/dts/rtl8380_zyxel_gs1900-16.dts
Select realtek/ zyxel_gs1900-16, add luci and enable TARGET_ROOTFS_INITRAMFS (as you will need the initramfs image for testing over the serial console).
Feel free to use this config:
##### realtek.init: start #####
### Use "make defconfig oldconfig" to expand this to a full .config
CONFIG_TARGET_realtek=y
CONFIG_TARGET_realtek_generic=y
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_allnet_all-sg8208m=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_allnet_all-sg8208m=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_d-link_dgs-1210-10p=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_d-link_dgs-1210-10p=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_d-link_dgs-1210-16=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_d-link_dgs-1210-16=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_d-link_dgs-1210-28=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_d-link_dgs-1210-28=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_inaba_aml2-17gp=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_inaba_aml2-17gp=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_netgear_gs108t-v3=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_netgear_gs108t-v3=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_netgear_gs110tpp-v1=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_netgear_gs110tpp-v1=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_netgear_gs308t-v1=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_netgear_gs308t-v1=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_netgear_gs310tp-v1=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_netgear_gs310tp-v1=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_zyxel_gs1900-10hp=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_zyxel_gs1900-10hp=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_zyxel_gs1900-16=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_zyxel_gs1900-16=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_zyxel_gs1900-8=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_zyxel_gs1900-8=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_zyxel_gs1900-8hp-v1=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_zyxel_gs1900-8hp-v1=""
CONFIG_TARGET_DEVICE_realtek_generic_DEVICE_zyxel_gs1900-8hp-v2=y
CONFIG_TARGET_DEVICE_PACKAGES_realtek_generic_DEVICE_zyxel_gs1900-8hp-v2=""
### Enable per device rootfs
CONFIG_TARGET_MULTI_PROFILE=y
CONFIG_TARGET_PER_DEVICE_ROOTFS=y
### Debugging options
# CONFIG_KERNEL_DEBUG_INFO is not set
# CONFIG_KERNEL_DEBUG_KERNEL is not set
# CONFIG_KERNEL_KALLSYMS is not set
### Per-package build logs in <buildroot>/logs
CONFIG_DEVEL=y
CONFIG_BUILD_LOG=y
### Include package list in build
CONFIG_INCLUDE_CONFIG=y
### Longer waiting for failsafe button push
CONFIG_IMAGEOPT=y
CONFIG_PREINITOPT=y
CONFIG_TARGET_PREINIT_TIMEOUT=5
### Minify lua
CONFIG_LUCI_SRCDIET=y
### build kmod-mtd-rw, so it is available for installing later
CONFIG_PACKAGE_kmod-mtd-rw=m
### display and edit the uboot environment
CONFIG_PACKAGE_uboot-envtools=y
### luci
CONFIG_PACKAGE_uhttpd=y
CONFIG_PACKAGE_uhttpd-mod-ubus=y
CONFIG_PACKAGE_luci-mod-admin-full=y
CONFIG_PACKAGE_luci-app-firewall=y
CONFIG_PACKAGE_luci-app-opkg=y
CONFIG_PACKAGE_luci-app-uhttpd=y
CONFIG_PACKAGE_luci-app-wol=y
CONFIG_PACKAGE_luci-proto-ipv6=y
CONFIG_PACKAGE_rpcd-mod-rrdns=y
CONFIG_PACKAGE_luci-theme-bootstrap=y
### luci-ssl (mbedtls)
CONFIG_PACKAGE_px5g-wolfssl=y
### disable signed packages
CONFIG_PACKAGE_opkg=y
# CONFIG_PACKAGE_openwrt-keyring is not set
# CONFIG_PACKAGE_usign is not set
# CONFIG_SIGNED_PACKAGES is not set
##### realtek.init: stop #####
Given that you really, really want to test the initramfs image (using tftpboot over the serial console) first, there's little danger of doing anything wrong, even if you'd somehow mess up the building.
Obscure SFPs are supported too, in case anyone wondered.. This is a BX-U SFP "donated" by my ISPs CPE. I am using a ZyXEL GS1900-10HP paired with an RPi4 to replace that CPE for this fibre access::
root@gs1900-10hp-f:~# ethtool -m lan10
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x01 (SC)
Transceiver codes : 0x00 0x00 0x00 0x40 0x12 0x00 0x01 0x00 0x00
Transceiver type : Ethernet: BASE-BX10
Transceiver type : FC: long distance (L)
Transceiver type : FC: Longwave laser (LC)
Transceiver type : FC: Single Mode (SM)
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 10km
Length (SMF) : 10000m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 1310nm
Vendor name : Tsuhan
Vendor OUI : 00:00:00
Vendor PN : THMPRS-3511-10A
Vendor rev : A
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : F19021506991
Date code : 190409
Optical diagnostics support : Yes
Laser bias current : 19.530 mA
Laser output power : 0.3220 mW / -4.92 dBm
Receiver signal average optical power : 0.1778 mW / -7.50 dBm
Module temperature : 49.00 degrees C / 120.20 degrees F
Module voltage : 3.2446 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : Off
Laser output power high warning : Off
Laser output power low warning : Off
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : Off
Laser rx power high warning : Off
Laser rx power low warning : Off
Laser bias current high alarm threshold : 65.000 mA
Laser bias current low alarm threshold : 1.000 mA
Laser bias current high warning threshold : 55.000 mA
Laser bias current low warning threshold : 3.000 mA
Laser output power high alarm threshold : 1.2589 mW / 1.00 dBm
Laser output power low alarm threshold : 0.0447 mW / -13.50 dBm
Laser output power high warning threshold : 0.5012 mW / -3.00 dBm
Laser output power low warning threshold : 0.1122 mW / -9.50 dBm
Module temperature high alarm threshold : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold : -10.00 degrees C / 14.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold : -5.00 degrees C / 23.00 degrees F
Module voltage high alarm threshold : 3.6000 V
Module voltage low alarm threshold : 3.0000 V
Module voltage high warning threshold : 3.5000 V
Module voltage low warning threshold : 3.1000 V
Laser rx power high alarm threshold : 1.2589 mW / 1.00 dBm
Laser rx power low alarm threshold : 0.0050 mW / -23.01 dBm
Laser rx power high warning threshold : 0.5012 mW / -3.00 dBm
Laser rx power low warning threshold : 0.0126 mW / -19.00 dBm
Works perfectly. Extra bonus is that the switch is powering the RPi (with a PoE hat) as well as two APs. The RPi is set up as a router-on-a-stick, using different VLANs as WAN and LAN.
2 Likes
Is there any way to see which firmware slot (on, e.g. the GS308T) corresponds to which image1/image2 (for the purpose of setting boot partition via fw_setsys)? I'd like to flash the original netgear image into image2 and be able to boot from it, but I don't know where to point mtd.
Update: found the answer at biot.com. It's mtd6
image1 is "firmware" and image2 is "runtime2" in OpenWrt. Just use the "runtime2" name with mtd, or look at /proc/mtd to see the mapping.
Note that the bootpartition variable is zero-based and the OEM partition names are one-based. So "bootpartition = 1" means "image2". Somewhat confusing...
2 Likes
Hmm, does the GD308T firmware need to be stripped before flashing?
(from https://openwrt.org/docs/guide-user/installation/generic.uninstall#via_openwrt_cli)
I'm not sure what that page means by "stripped". That part definitely needs some more explanation and examples.
But I'm guessing that it is about additional firmware headers which should not end up in flash, used by the original firmware to verify/validate the image before flashing. This depends on vendor/device, and I have no experience with the GS308T. But the realtek devices I have tested does not use such headers. They come with firmware which can be written directly as-is. The ZyXEL firmware has a trailer, but writing that to flash is harmless.
You can try to verify the theory by comparing the start of a partition with the start of an image, using e.g hexdump. Checksums and sizes etc will of course be different, but you should recognize the pattern in the header. In particular the magic number in hte first 4 bytes.
1 Like
It looks like the GS-1900-8HP offers the same elegant access integrated into one of the "grills" that let air in and out on the sides (at least the B1 revision).
Overall openwrt has been working great on my GS1900-8HP.
One weirdness I have noticed is that traffic destined for the switch itself seems to be leaked/broadcast to different ports unexpectedly. Steps to reproduce on openwrt master:
- Start from stock config (management VLAN 100 on port 1 tagged)
- Set port 2 to VLAN 100 untagged
- Run wireshark on a machine connected to port 1
- Access the openwrt web interface on a different machine connected to port 2
- Observe the HTTP packets sent out port 1. (Only the packets to the switch, not from the switch.)
This does not happen with the stock firmware.
Has anyone seen this behavior?
Hi looi,
could you use tcpdump to look at the traffic on the outgoing interface for port 2 (lan2) on the GS1900-8HP? If you see the "mirrored" packet to the device, then there is an issue with the interaction between driver and kernel and the kernel somehow forwards the packets. If you do not see these packets, then it is the the switch hardware forwarding them. There could be two mechanisms at switch level: an issue with MAC learning (and we are seeing flooding as a result) or the packet inspection engine doing something weird and wonderful. The router's forwarding DB with the MACs learned can be displayed using "bridge fdb show".
Kobi
I would also suggest to paste the full /etc/config/network. Yes, you have described your changes well, but having the full config makes it easier to reproduce or spot eventual (syntax or semantical) issues.
Do you mean lan1? (which is the machine running wireshark)
When accessing the openwrt web interface from port 2, tcpdump -i lan2 on the switch shows HTTP packets, but tcpdump -i lan1 does not. (even though a device physically connected to port 1 receieves the packets)
So it seems like the switch hardware is forwarding?
Here is the contents of /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdbb:a873:ee80::/48'
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr 'xx:xx:xx:xx:xx:xx'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
list ports 'lan6'
list ports 'lan7'
list ports 'lan8'
config bridge-vlan 'wan_vlan'
option device 'switch'
option vlan '1'
list ports 'lan1'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
list ports 'lan6'
list ports 'lan7'
list ports 'lan8'
config device
option name 'switch.1'
option macaddr 'xx:xx:xx:xx:xx:xx'
config interface 'wan'
option device 'switch.1'
option proto 'dhcp'
config interface 'wan6'
option device 'switch.1'
option proto 'dhcpv6'
config bridge-vlan 'lan_vlan'
option device 'switch'
option vlan '100'
list ports 'lan1:t'
list ports 'lan2'
config device
option name 'switch.100'
option macaddr 'xx:xx:xx:xx:xx:xx'
config interface 'lan'
option device 'switch.100'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
Yes, this looks like the switch hardware forwarding. What does bridge fdb show? Has the MAC of the router been properly learned for vlan 100?
I think I observed the same behaviour on early days, however I build a config from scratch and been solid since.
ditch VLAN 100 and make your management untagged VLAN 1
I use PVID 1 in all ports then tagged on all other ports for any VLAN I use
option device 'switch'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan10:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'
list ports 'lan5:u*'
list ports 'lan6:u*'
list ports 'lan7:u*'
list ports 'lan8:u*'
list ports 'lan9:u*'
config bridge-vlan
option device 'switch'
option vlan 'Any VLAN ID'
list ports 'lan1:t'
list ports 'lan10:t'
list ports 'lan2:t'
list ports 'lan3:t'
list ports 'lan4:t'
list ports 'lan5:t'
list ports 'lan6:t'
list ports 'lan7:t'
list ports 'lan8:t'
list ports 'lan9:t'
In case you want to do untagging for other VLAN than 1
config bridge-vlan
option device 'switch'
option vlan '20'
list ports 'lan1:u*'
list ports 'lan2:t'
list ports 'lan3:t'
list ports 'lan4:t'
list ports 'lan5:t'
list ports 'lan6:t'
list ports 'lan7:t'
list ports 'lan8:t'
Works great for me
Here is the output of bridge fdb.
The MAC addresses of lan1-8 are 5e:xx:xx:xx:xx:2c-33
The MAC address of switch.100 (LAN) is 5e:xx:xx:xx:xx:2c
The MAC address of the machine on port 1 is a8:xx:xx:xx:xx:xx
The MAC address of the machine on port 2 is 70:xx:xx:xx:xx:xx
5e:xx:xx:xx:xx:2c dev eth0 self permanent
5e:xx:xx:xx:xx:2d dev eth0 self permanent
5e:xx:xx:xx:xx:2e dev eth0 self permanent
5e:xx:xx:xx:xx:2f dev eth0 self permanent
5e:xx:xx:xx:xx:30 dev eth0 self permanent
5e:xx:xx:xx:xx:31 dev eth0 self permanent
5e:xx:xx:xx:xx:32 dev eth0 self permanent
5e:xx:xx:xx:xx:33 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:00:00:00:02 dev eth0 self permanent
33:33:00:00:00:01 dev eth0 self permanent
33:33:ff:xx:xx:2c dev eth0 self permanent
33:33:ff:00:00:00 dev eth0 self permanent
a8:xx:xx:xx:xx:xx dev lan1 vlan 100 master switch
5e:xx:xx:xx:xx:2c dev lan1 vlan 100 master switch permanent
5e:xx:xx:xx:xx:2c dev lan1 vlan 1 master switch permanent
5e:xx:xx:xx:xx:2c dev lan1 master switch permanent
a8:xx:xx:xx:xx:xx dev lan1 self
70:xx:xx:xx:xx:xx dev lan2 vlan 100 master switch
5e:xx:xx:xx:xx:2d dev lan2 vlan 100 master switch permanent
5e:xx:xx:xx:xx:2d dev lan2 master switch permanent
70:xx:xx:xx:xx:xx dev lan2 self
5e:xx:xx:xx:xx:2e dev lan3 vlan 1 master switch permanent
5e:xx:xx:xx:xx:2e dev lan3 master switch permanent
5e:xx:xx:xx:xx:2f dev lan4 vlan 1 master switch permanent
5e:xx:xx:xx:xx:2f dev lan4 master switch permanent
5e:xx:xx:xx:xx:30 dev lan5 vlan 1 master switch permanent
5e:xx:xx:xx:xx:30 dev lan5 master switch permanent
5e:xx:xx:xx:xx:31 dev lan6 vlan 1 master switch permanent
5e:xx:xx:xx:xx:31 dev lan6 master switch permanent
5e:xx:xx:xx:xx:32 dev lan7 vlan 1 master switch permanent
5e:xx:xx:xx:xx:32 dev lan7 master switch permanent
5e:xx:xx:xx:xx:33 dev lan8 vlan 1 master switch permanent
5e:xx:xx:xx:xx:33 dev lan8 master switch permanent
5e:xx:xx:xx:xx:2c dev switch self permanent
33:33:00:00:00:01 dev switch self permanent
33:33:00:00:00:02 dev switch self permanent
01:00:5e:00:00:01 dev switch self permanent
33:33:ff:00:00:01 dev switch self permanent
33:33:ff:xx:xx:2c dev switch self permanent
33:33:00:01:00:02 dev switch self permanent
33:33:00:01:00:03 dev switch self permanent
33:33:ff:00:00:00 dev switch self permanent
5c:xx:xx:xx:xx:2c dev switch vlan 100 master switch permanent
5c:xx:xx:xx:xx:2c dev switch vlan 1 master switch permanent
5c:xx:xx:xx:xx:2c dev switch master switch permanent
33:33:00:00:00:01 dev switch.1 self permanent
33:33:00:00:00:02 dev switch.1 self permanent
01:00:5e:00:00:01 dev switch.1 self permanent
33:33:ff:xx:xx:2c dev switch.1 self permanent
33:33:ff:00:00:00 dev switch.1 self permanent
33:33:00:00:00:01 dev switch.100 self permanent
33:33:00:00:00:02 dev switch.100 self permanent
01:00:5e:00:00:01 dev switch.100 self permanent
33:33:ff:00:00:01 dev switch.100 self permanent
33:33:ff:xx:xx:2c dev switch.100 self permanent
33:33:00:01:00:02 dev switch.100 self permanent
33:33:00:01:00:03 dev switch.100 self permanent
33:33:ff:00:00:00 dev switch.100 self permanent
A HW entry for 5e:xx:xx:xx:xx:2c with vlan 100 is definitely missing, it would have the "self" attribute and would be "permanent" if it was set by the kernel telling the driver about it.
Can you try adding an entry manually using "bridge fdb add" with vlan 100?
If this works, then I still don't know how to implement this to be automatic. Normally entries are learned by receiving packets with a certain VLAN on a port. Evidently this does not work for the CPU-port. One solution is likely to implement vlan offloading in the Ethernet driver, so when the kernel sends packets on VLAN 100, the HW can learn the sending MACs. For this the CPU-tag needs to be filled out, the HW is not able to look into the packets that are sent.
The other option is to somehow tell the kernel to make the HW aware of the the CPU port being on vlan 100 the moment this is being configured.
My suspicion is that this issue was introduced when the forwarding DB was changed to be vlan-sensitive for the multicast support.