Support for RTL838x based managed switches

It's amazing seeing devices with more ports being supported and I've been watching the realtek board space closely for a while and waiting for a working 48 port with POE switch. Until now I've been using a D-Link DGS-1210-28 and it's worked flawlessly so far.

I was trying to understand the differences between the GS1900-48 and and the GS1900-48HP. Do you see much difference between the two boards? Would it be a case of me adjusting the image definition from the 24HP (adding more ports) and the 48HP and adding the "ZYXEL_VERS := AAHO"? Or would it be more complicated than that and I should wait before going out and picking up a used GS1900-48HP?

HP flavours are PoE switches. Do you want/need PoE?

I think if you don't need the PoE right away, then go for it.
If they've kept the hardware consistent, getting the extra 24 ports should be easy. It'll be just applying the change from the GS1900-24 to the GS1900-48 against the GS1900-24HP.

The PoE might be trickier. I'm unsure where it currently sits with the GS1900-24HP. Getting the 'first' 24 ports on the 48HP with PoE should be possible easily if the 24HP already has PoE working in OpenWRT.
The other 24 ports may be more challenging, depending on how those additional 24 ports have the PoE configured.
It might just be extensions from the existing PoE controller, in which case it should just work. Or it might be another PoE controller in parallel or similar, in which case it would be a bit of extra work to try to work out the mapping etc to communicate to it.

If you just want a PoE switch that works, stick with the stock firmware. If you want to be on the bleeding edge, and have something to troubleshoot, faultfind and potentially help develop, then jump in...

1 Like

@Borromini and @bevanweiss thanks for the feedback and a good point on moving over the POE ports (from a unifi edgeswitch with flaky autongotiation) as and when the POE side gets working. Worst case it's some hacking fun. Has anyone worked out the technical differences between the GS1900 v1 and v2 branded hardware?

Depends on the model, the 24HP v1 has only 64MB RAM whereas the v2 has 128MB. Usually, ZyXEL doesn't change much, we had a recent discussion on this regarding a possible v3 a few days ago in another thread - I can link it later.

1 Like

Just a short fyi: I would like to bring OpenWrt to the GS1920 series, so I created a separate thread for it here:


I saw earlier in this thread discussion of bonding and LACP but I don't know if setting up a bonded interface with a vlan trunk running on top of it between two openwrt devices is currently possible.

I defined the bonded interface and the bond vlans on the openwrt router (x86_64) like bond-bond0 and bond-bond0.x. On the switch (rtl838x) I just have the lan and bonded interface defined with device vlan filtering on the switch ports associated with the bond and other switch ports. It seems to sort of work but some vlans won't respond to ping. Anyone know how to set this up or know if this doesn't work yet?

The code for offloading bonds as part of a bridge is currently broken. Normally, it should be handled in the method rtl83xx_port_lag_join in the DSA driver, but it doesn't work due to a bug. In itself, this would just mean that LAGs are not be offloaded and forwarding for LAG ports is performed in software. However the driver actually has some code in another place that still configures the hardware without DSA knowing about it. In the end, it just doesn't work properly.

I looked into fixing this, and started by disabling all that LAG code in the drivers (WIP branch on Github), so it would actually run in software. That turned up several other bugs, so I worked on fixing those instead (and I haven't continued to work on the LAG stuff since then).


Excellent! Thanks for sharing your findings in regards to using LAGs with DSA and for fixing the layer 2 forwarding in the DSA driver.

While I haven't read all the latest posts; I was busy fixing some crap (which was my fault of course) on my WIP branch.

The new i2c dts stuff seems to work now, and I managed to get ALMOST 200Mbit in throughput :slight_smile:

[  5]   1.00-2.04   sec  23.8 MBytes   193 Mbits/sec    0    178 KBytes       
[  5]   2.04-3.03   sec  22.5 MBytes   189 Mbits/sec    0    188 KBytes       
[  5]   3.03-4.01   sec  22.5 MBytes   193 Mbits/sec    0    199 KBytes       
[  5]   4.01-5.04   sec  23.8 MBytes   195 Mbits/sec    0    199 KBytes       
[  5]   5.04-6.01   sec  22.5 MBytes   193 Mbits/sec    0    199 KBytes       
[  5]   6.01-7.05   sec  23.8 MBytes   193 Mbits/sec    0    199 KBytes       
[  5]   7.05-8.05   sec  23.8 MBytes   199 Mbits/sec    0    291 KBytes       
[  5]   8.05-9.05   sec  23.8 MBytes   199 Mbits/sec    0    291 KBytes       
[  5]   9.05-10.01  sec  22.5 MBytes   197 Mbits/sec    0    291 KBytes       

Dunno if the USB adapter I'm using has any negative impact here, or if I could have done better :wink:

I'll go read the thread next though :slight_smile: looks like I had already responded to pretty much everything other then the LAG stuff. My only thoughts there, @janh be careful with fixing stuff. Things quickly unravel :frowning:


Since 2021 the Zyxel XGS1210 /1010 got support on OpenWRT:

Last year for example yarrick wrote code to support also the SFP ports:

The Zyxel XGS1010 /1210/ 1250 is one family based on the same SoC.

Only few thinks are different. For example the firmware, reset-button, fan/ fanless and the implementation 10Base-T/ NBase-T are different. I think there is only another driver for the RTL8226 2.5 Gigabit PHYs instead Marvell Aquantia AQR113C necessary.

Unfortunately until now is only the XGS1250 supported:

Is there any reason?

I also own a xgs1010-12, and have support added for it 6 months ago. Meanwhile, I've been working a lot on this target.

Why isn't the support yet upstream? quite frankly, because it's almost impossible to get stuff merged in openwrt. Simple as that. If you want to help stuff move along, review stuff I offer in OpenWRT, and help push it through. I have about 230 patches, some from others, lots from myself, that improves and cleans up the mess that is realtek support.

My take on it? Don't let perfect be the good of evil. Every patch that doesn't make things worse, should go in :slight_smile: Realtek support needs to be fully re-written. Most of the already upstreamed stuff, all of the openwrt stuff. That's the sad reality. So if we can improve things little by little, we actually can start moving forward. Otherwise, don't expect support for the next 3 years.

My branches are: for the stuff I'm actively working on, often force-pushed, breaks probably daily. is the stuff that doesn't seem to be broken. Kind of like a 'stable snapshot' of wip. If I feel confident stuff works, and get reports on the WIP being 'okay' I'll push to -dev. is my branch where I try to keep things in sync with open MR's. E.g. if I offer a series as a MR, I put it there, and so if I have multiple open MR's then they are all in that branch. I try to heavily avoid multiple branches though; as it takes 6 - 8 weeks to get even simple stuff merged, anything serious would take 2 - 6 months probably :stuck_out_tongue:

P.S. on yarrick's branch, I only see brigers patches, nothing from yarrick himself or for the xgs1210/1010. So not sure what you mean by

Anyway, SFP works, -ish. E.g. a 1.5m DAC cable we have working, but anything beyond that in length, doesn't work. This is related to serdes training/calibration, that's a bit out of our scope/radar for the time being, as there's many other fishes to fry.



Please, do not burn yourself out !

That's a lot, how do you manage the stack (are they sorted in a way, fixes / support / WIP / etc.) ?

Is there something upstreamable (vanilla, not speaking of openwrt) ? That may be easier to get out and lighten the local load...

1 Like

I would also like to carry on the work on the T1600G-28TSv3, previously done by @johnd2. I have a basic DTS ready (RTL8382M) and image flashing works fine the same way as on the T1600G-52PS and the other TP-Links by grounding the CLK pin at the right time to trigger TFTP recovery.

Strangely enough, I'm unable to identify the reset GPIO and the LEDs controlled by the RTL8231 don't work. I'll have to investigate how the RTL8231 is connected to the SoC and how control works. I didn't fully understand the outcome of the investigation performed earlier in this thread by @svanheule.

1 Like

Don't I know it; actually I was able to do all this, because I was in exactly that situation. Being able to code without pressure was really nice (though the code base was frustrating to say the least). However, it now feels like a dead end ... ready to be abandoned/giving up on.

So, I started by adopting birger (topic starters) last big series of patches. Split them up, clean them up; add tons of defines for a lot of magic values. Then, kept on adding more of those. Also marcus's patches I've added. Cleaned those up, added more defines. Tons and tons of rebasing sessions, trying to more logically organize them. So most changes are grouped, more or less with what you said. Not everything is perfect, but, I feel like it's an improvement overall. I'd almost say "merge it as is :p". I don't think there's any place that makes things worse, only for the better. However, I produce more patches then there is review/merge capacity it seems on the openwrt side ...

Yes/no/yes. So, the problem with the current code base, is that its a friggin mess. Everything needs to be rewritten to be upstreamable. It's not a problem, and I have started that on a few small things, but the difficulty here is, a) testing, b) validation, c) the mess that is the realtek chip :slight_smile:

E.g. does it work as it is supposed to. For something small, like the i2c driver that I have rewritten (which is currently in testing/wip as it's not working, but probably something small), is am I using the peripherial as they are supposed to. The reference (SDK/openwrt) code often does weird things, which are not correct, but seem to work. But who is right? So in doing things that should be logical right, it turns out, there's some weirdness where it simply doesn't work.

But more importantly, it's understanding everything. We have no proper documentation. The datasheets contain register descriptions, but not how to use things. And then there's the whole network stack, it's a mess.

So I have started to untangle a lot of things, and with the earlier mentioned defines, things actually become much more readable now. With that in hand, it is also now feasible to start re-writing things.

But, going upstream first/only, is a tricky thing. Nobody is using upstream in its current form. So validating that a new driver is correct, is hard. It needs testing, from more then just 1. Hence, getting things in openwrt (first in its current form, that helps is learn and understand) and later in mainline is crucial.

Also, having it in openwrt, means people actually get to use it and report issues on it. Putting it in mainline, makes it just sit there, with no users.

And yes, putting it in mainline, and then backporting it to openwrt is certainly a goal for the mid-term future, however, subtle differences, extra work makes that troublesome too. And again, just because upstream accepts it and merges it, doesn't mean it actually works :slight_smile:

still over USB, but depends on the hour of the day :stuck_out_tongue:

[  5]   6.00-7.05   sec  23.8 MBytes   190 Mbits/sec    0    221 KBytes       
[  5]   7.05-8.04   sec  22.5 MBytes   191 Mbits/sec    0    221 KBytes       
[  5]   8.04-9.03   sec  22.5 MBytes   191 Mbits/sec    0    221 KBytes       
[  5]   9.03-10.01  sec  22.5 MBytes   192 Mbits/sec    0    221 KBytes  

:smiley: though I doubt 200Mbit is possible :frowning:


Take your time. Since those devices doesnt need to depend on an halfway modern wifi generation to be still valuable in longterm. Doesnt really matter if it needs months or years, its still pretty awesome and valuable. And a good counter against planned obsolescence from most network manufacturer. I already throwed away several tons of technological still relevant L2/L3 switches at work because firmware went eol or we didnt want to expend crappy licensing. Your work have the potential to save devices from the landfill and open a second market for private, small and medium businesses.

heh, but without the work, my switch is a paper weight, as i will not run the vendor-firmware on it :slight_smile: that's the whole reason I got it :stuck_out_tongue:

But thanks for your feedback :slight_smile: regardless, I want things to move forward :smiley:


@svanheule What's the current state of RTL8231 in SMI mode? I measured the pins and the RTL8231 on my T1600G-28TSv3 is definitely in SMI mode.

I have the same question about my cr1000a :slightly_smiling_face:

heh :slight_smile: so all the network leds are driven by the RTL3901?