Support for RTL838x based managed switches

I just pushed my support branch from a few months ago. Looks like I intended to submit two patches: One for the device and one for the PHYs. The one for the device should still apply with only little changes, but the PHY patch needs more attention.

Both are clearly based on @janh's excellent work on the HPE series, I just made a few small changes to the PHY code.

I'm pretty sure I won't have much time to work on this for the next weeks, feel free to port this forward.

3 Likes

Any update?

I know this function is present in TP-Link switches, even not expensive ones.

I may have also seen this in similarly priced Netgear switches.

Actually yes; I've managed to add support for L2 port isolation to the rtl83xx DSA driver.

You can find my PR here - testing much appreciated :slight_smile:

5 Likes

Once the patch is applied, will the function be available through Luci?

How do we get it in a snapshot form as far as the repository (firmware-selector) to get more testers onboard?

Create a PR, build an image off recent main with the PR applied, share images, collect feedback and bug the devs.

Yes - in fact, the option exists without my patch, it just doesn't do anything.

The setting can be found on the configuration page of each switch port:
(Network > Interfaces > Devices > Configure...)

2 Likes

Needs to be entered as a PR to get merged into master, then it will be available as a SNAPSHOT build.
I'll try testing this now, been a busy few days but should have more time soon.

EDIT - just taking the commit https://github.com/openwrt/openwrt/compare/main...andyboeh:openwrt:hpe1920-48g seems to be the trick. The other commits added with this must have broken boot on the 1920-48G.
I have busybox now on the switch, will continue experimenting.

I also cherry-picked that commit onto 23.05.3 and it works fine, running it right now.

EDIT2 - 23.05.3 has been running without glitches for a day and VLAN mapping is working as well as LLDP using the updated LLDP package from master.
Only artifact visible is that phantom link status on port lan50 which claims to be up but is not connected, guess it's due to SFP driver issues.

Overall happy with the switch and the ~23MB of overlay space is a relief compared to the situation on the Zyxel GS1900-48.

1 Like

Great to know about your success on this, I guess you went further than the rest.

What does it take for the merge to take place?

Thinking about getting few 1920-48G

You can now create two PRs: One for "main" to get it into snapshot and once this is done, a cherry-pick on this very commit to backport it to 23.05.

If you are happy for me to do this then I will go ahead. I will report back with the PR details.

Sure - just keep in mind that my commit is mostly (or even entirely?) @janh's version without proper credit. Please make sure to credit him for his work.

Absolutely, this is one of the reasons I hadn't opened a PR so far - I want to credit the right people.

@janh and @andyboeh PR submitted, I have credited you both as my only role here has been to test the code on HPE 1920-48G:

Once that is merged I'll do a backport to the 23.05 branch.

4 Likes

While testing this patch, I noticed an unrelated issue in current main branch: Untagged ports with a VLAN other than 1 can't communicate with the CPU.

It looks like this is a regression caused by pull request Fix rtl930x VLAN, LEDs and status (#14221). The two commits "rtl83xx: dsa: Do nothing when vid 0" and "rtl83xx: dsa: reset PVID to 1 instead of 0" appeared to me like the most likely culprits, and a quick test has confirmed that.

The issue occurs on RTL838x and RTL839x. Has anyone else seen this? Does it also happen on RTL93xx (which seems to have been the primary target of this pull request)?

3 Likes

Yes, I had noticed that too, thanks for bringing that up. I have seen that on (at least) gs1900-8POE and GS110TPP.

Thanks a lot too for finding the time to also dig up the reason. That commit being tagged RTL93XX probably was the reason I did not spot it the quick look when I noticed the issue a month after the patch when master was at r0-5e395f0c2.

Because I stopped making new builds at that point for realteks, I'm a bit out the loop w.r.t kernel dev:
Is the status of kernel-version 6.1. still "Boots, but no ethernet"?
And what about 6.6? realtek seems to be last of the targets in use here still stuck on 5.15.

1 Like

Can confirm this on my Zyxel GS1900-24E (RTL8382M).

1 Like

What is the status of SFP port support on this devices, especially the JG924A.

I have a DACable to connect to my main switch, but it only negotiates 10Mbit/s. Haven't hat time to check with another SFP module yet.

Is there someway to force 1000Mbit/s for this port? Haven't found any knob to turn.

Have you checked that you actually only get 10 Mbit/s? The link speed is not reported correctly for the SFP ports on this device. In my case it is reported as 100 Mbit/s with a fiber SFP module, but the link is actually running at full Gigabit speed.

However, there was some discussion in this thread about DAC cables not being fully supported. But it is also possible that things are different for these devices, as the SFP ports are connected to a RTL8214FC PHY instead of the internal SerDes of the SoC.

For manual configuration you could try using ethtool.

@janh

ethtool reports:

ethtool lan27
Settings for lan27:
	Supported ports: [ TP MII FIBRE ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 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 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 10Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 26
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: d
	Wake-on: d
	Link detected: y

Link is about 100Mbit/s as far as I could measure.

Setting it with ethtool to anything else does not work, as the port becomes disabled.