Support for RTL838x based managed switches

With which repo and which branch did you get all link modes on SFP?

this is with the SFP fixes I posted a link to earlier, and this patch in addition:

These are now submitted to the ML, so hopefully in master soon.

You also get SFP hotplug and other nice features of the sfp driver.

1 Like

@bmork , thanks for the clarificaton. That sounds like there are more "user"-friendly devices than the Netgear GS108T v3 and the D-Link DGS-1210-16 rev. G, which are the switch devices I own. For both of them you can't (currently) install OpenWrt via web interface and need to access the unpopulated headers.

I was not complaining about anything, if it sounded like that. I'm very thankful for for the developers' effort that lets me use OpenWrt all across my network.

@sven For what it's worth, I have no soldering skills, no solder iron either (although I have my first on the way). I 'rescued' my GS108T v3 by fiddling with the serial contacts and pressing a set of male headers against it with one hand while using minicom with the other.

If you use my images (linked to earlier), you don't even need the serial, they don't use the VLAN 100. They do use a static for provisioning, so you need to change your subnet, but no fiddling with VLANs or whatever. From there you can reconfigure and flash vanilla OpenWrt images (while keeping your config of course) and keep up with master or 21.02, if you'd like.

@Borromini haha, I did the same (pressing unsoldered multi pin connector onto the board while using the other hand to type). Although I prefer screen over minicom. :grin:

I always build from source, because I omit and include some packages which I want to have available from the first boot. My build has a modified /etc/board.d/02_network that configures WAN on lan1 and LAN on all remaining ports, so even when doing "sysupgrade -n" or "firstboot", I won't need the serial cable any more, I hope. :slightly_smiling_face:

1 Like

I have added some UCI defaults:

# Source the necessary UCI functions
. /lib/functions/

# Revert default OpenWrt realtek target settings from /etc/board.d/02_network [1]
uci -q delete network.lan_switch_100_dev
uci -q delete network.wan
uci -q delete network.wan_vlan
uci -q delete network.wan_switch_1_dev
uci -q delete network.wan6

# Set up LAN with bridge across all ports and VLAN ID 1. Stick with the explicit
# switch.1 declaration so we don't run into issues later on when we need VLANs.
uci -q set network.lan_switch_1_dev=device
uci -q set'switch.1'
uci -q set network.lan_switch_1_dev.macaddr="$(mtd_get_mac_ascii u-boot-env ethaddr)"
uci -q set network.lan.ifname='switch.1'
uci -q set network.lan_vlan.vlan='1'
uci -q set network.lan_vlan.ports='lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8'
uci -q set network.lan.dns=''
uci -q set network.lan.gateway=''

I also have an GS108Tv3 and have been testing stock UI flashing on it. This works. I just verified that using unmodified images from

But you absolutely have to do it in two steps:

  1. flash the OpenWrt initramfs to "image1" and reboot into it
  2. log in (remember odd network config!) and use sysupgrade to install OpenWrt properly.

WARNING: Trying to flash a sysupgrade image directly from stock UI will softbrick the device. Easily fixed with console access. But console will be required. Which means soldering on the GS108Tv3.

Don't write the OpenWrt initramfs to "image2". It will boot fine from there, but OpenWrt doesn't currently support switching images. So you won't be able to boot into the real system after sysupgrading, unless you use the console to switch images. Leaving "image2" alone will also let you keep a fully functional stock firmware installed, supporting "dual-boot" between OpenWrt and stock.

Except for:

Supporting image switching is pretty simple, but the necessary patches have been stuck in patchworks for a few months.

bmork, I added your 7 patches to master and compiled it.

On my 1000Base-T SFP I see now "TP" as supported and can set the modes supported by the module:

root@OpenWrt:~# ethtool -s lan9 speed 10 duplex full
Cannot set new settings: Invalid argument
  not setting speed
  not setting duplex
root@OpenWrt:~# ethtool -s lan9 speed 1000 duplex full
root@OpenWrt:~# ethtool lan9
Settings for lan9:
	Supported ports: [ TP MII ]
	Supported link modes:   1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 22
	Transceiver: external
	Auto-negotiation: on
	Supports Wake-on: d
	Wake-on: d
	Link detected: yes

Installed poe package. Now I can also see power consumption:

root@OpenWrt:/tmp# ubus call poe info
        "ports": [
        "power_budget": "77W",
        "power_consumption": "2.2W"

That's awesome. Thanks to all for support!

I see official support for Zyxel GS1900-8 has been merged. Any plans to do the same for GS1900-16 please? Thank you.

I am not aware that anyone among the developer who has that device already. If you got one yourself, then we can help you get it supported. You should go to and add a description of the device. Important would be a photo of the interior, plus the output of the "show tech-support" command in the OEM shell, which gives the complete PHY and GPIO mapping of the device. Finally, to build an image the layout of the flash as shown in u-boot. With this information it is usually only about half an hour's work to make a .dts.

1 Like

Many thanks for the explanation, @bmork ! Didn't know that.

It's documented in the device's wiki page.

As is seems there are a lot of devs here, I'd like to ask for your ideas on how to find the reason for my lan1 not being accessible from the device directly connected to it.


  • D-Link DGS-1210-16 rev. G running OpenWrt master r16153
  • 4 VLANs (1=internal, 2=IoT, 3=guest, 4=internet-only), switch itself bound to VLAN 1
  • Internet router (192.168.[1-4].1) serving these 4 VLANs connected to lan1
  • WLAN-AP (Netgear R7800) with 4 SSIDs corresponding to the 4 VLANs) connected to lan5
  • Desktop computer connected to WLAN-AP on untagged port with PVID 1


  • Everything works as intended, with one exception: I cannot access the DGS-1210-16 from the router. It does not answer pings or SSH login requests, instead runs into timeouts.

Fun facts:

  • lan1 seems to work because traffic is flowing through it. I can reach the router through lan1, browse the internet and so on. Only packets coming in on lan1 targeted for the switch itself are ignored.
  • When plugging the router from lan1 to any other port of lan2..lan8 on the DGS-1210-16, the problem disappears. I don't understand that because lan1..lan8 are using the same configuration in my setup (see below).

What should not be the the reason for this:

  • iptables (firewall, ip6tables and iptables are omitted from my build)
  • ebtables (not installed)
  • different configuration of lan1 (which does not work) and lan2..lan8 (which do work)

See below the output of uci show network.

I'd be very thankful for any hint on how to track down the problem.

network.lan_vlan.ports='lan1:t lan2:t lan3:t lan4:t lan5:t lan6:t lan7:t lan8:t lan9 lan10 lan11 lan12 lan13 lan14 lan15 lan16 lan17 lan18 lan19 lan20'
network.iot_vlan.ports='lan1:t lan2:t lan3:t lan4:t lan5:t lan6:t lan7:t lan8:t'
network.guest_vlan.ports='lan1:t lan2:t lan3:t lan4:t lan5:t lan6:t lan7:t lan8:t'
network.inetonly_vlan.ports='lan1:t lan2:t lan3:t lan4:t lan5:t lan6:t lan7:t lan8:t'

That not the case with ALL-SG8208M, right?

The ALLNET ALL-SG8208M is supported as Proof of Concept:
To install, upload the sysupgrade image to the OEM webpage.

1 Like

I stand corrected. I have no experience with the ALLNET switches.

What I do know is that the Netgear GS108Tv3 will allow you to flash any image with a matching U-Boot image header, but will cut off the file at the size given by that header. Which means that it will write only the kernel part of an OpenWrt sysupgrade image, silently dropping the rootfs, and therefore brick the device.

The ZyXEL GS1900-10HP on the other hand, will only accept images with a ZyXEL specific trailer indicating that it is intended for that specific hardware (using a ZyXEL version number with a 4 letter hardware code). It cuts off the file like the Netgear firmware, so it can't write a kernel+rootfs sysupgrade image either. But it cuts the file before validating the trailer. Which means that we have to include the trailer in the kernel part of the image (inside the size covered by the U-Boot header). This should only be done for the initramfs images, thereby preventing the sysupgrade images from being flashed directly from stock firmware.

I'm totally confused on how to actually access the switch after getting the initial image installed! I've started with a GS108Tv3. Uploaded the initramfs image via the OEM Web access. I can see from the serial port access that OpenWrt is running, but I can't seem to access it from any of the Ethernet ports! From what I've read it should be available at from ports 2-8.

After using Borromini's posted UCI defaults above I was successful in connecting to the switch. Perhaps the default should be changed to something similar so that initial login won't be a crap shoot if you don't have serial access!

Currently, the management interface (luci, ssh, etc.) is only available on port 1 and VID 100, so you need to connect your computer to port1 and configure your computer's network card to use (tag all packets with-) VLAN ID 100 (then you can connect to

Certainly not my favourite either, but it works. I'd be very much in favour of changing the defaults as well, but it is a bit more complex to get this 'right', as it's still a switch and not really a router with routing, NAT, and a DHCPd running - somehow I don't think change this in the last minute (for 21.02.0) would be the best idea (personally I'd favour it to be configured for DHCP-client, but then it gets very special, with even more default assumptions that might go wrong…).

How many people are going to know how to set up their computer's network card to tag all packets with a specific VLAN ID? It would make more sense to set up all ports to the same IP address just like most of the OEM firmware does.

1 Like