Support for RTL838x based managed switches

Status update:

I was wondering why PoE doesn't work. I tried original firmware AND a second Zyxel with original firmware but PoE didn't work on my Alfa routers. Hence the issue is with the routers which obviously don't support "standard" PoE (for which they are well known). :open_mouth: Need to postpone this until I have compliant devices.

bmork, I started compiling your branch. And meanwhile I took the latest snapshot and flashed it and I was really surprised that my 1000Base-T SFP module did suddenly work! Did an upstream merge happen?
Hence I didn't tested your realtek-fixes branch image (which meanwhile was successfully built). If it makes sense for you then I can test it.

That is surprising. I could not get mine to work with at least the MODE_NA fix and the Marvell 88E1111 phy driver.

What does your log look like? Can you install ethtool and play with it? Does speed and duplex negotioation work? I am ready for more suprises :slight_smile:

No need to test my branch, BTW. I bit the bullet and tested myself. The only thing that failed was the SX SFP. Which was a bummer for me, since that was my only link to that switch and all the connected devices....

Anyway, I went out there and reconnected the console so I can di some testing again. And used the opportunity to test hotplugging of a 1000Base-T SFP.. Which worked fine. Pretty weird. But it did eventually ring a bell: I saw this before when link state interrupts were failing. And looking at my GS108Tv3 running the same image, I see that this is now the problem again. Even after disconnecting and reconnecting a cable I have zilch here:

root@OpenWrt:/# grep link-state /proc/interrupts 
 20:          0   RTL83xx  20  rtl838x-link-state

How does that look for you? Do you see link-state interrupts? Funny thing is that anything with a phy will still work. But the fibre SFPs fail to come up. Do you have any fibre SFP to test with as well? Would be good to have someone else verify my findings, as I tend to jump to conclusions :wink:

What PoE standard do those use then?

That is what I meant earlier on. I tried SFP Fibre modules on both a DGS1210-10P and a GS1900-10HP with a recent snapshot and SFP just worked for me.

1 Like

Yes, fibre sfps should work on master. They fail for me because I re-enabled the sfp, without noticing that the link-state irq is still broken. I thought I bugged you about that a long time ago? :slight_smile:

Anyway, will verify my fix on the GS108Tv3 and then do another attempt on the GS1900-10HP.

Still don't understand how the copper SFPs works with current master. I thought they would need some interface setup?

Oops, I have that fixed in my development branch, I think it got accidentally broken by some work on the IRQ driver. It's not obvious when this is broken since phylink polls the MDIO bus also for link changes and triggers the necessary updates even in absence of an IRQ. But then I really rely on that IRQ to trigger printing of debug output during development :wink: I am away from my gear at the moment, next weekend I am back and will submit a patch.
BTW: I am still working on the L3 routing support, it is just that it has so many hardware tables for next hops, interfaces, source macs of interfaces, MTUs for interfaces, L2 forwarding database entries and finally routes which all need to be correctly linked to each other that it is very easy to get something wrong upon which these devices show their usual informative and graceful fail behavior: the router just does nothing. Also the kernel integration is a bit of work since one needs to send ARP requests and wait for answers to update the next-hop entries with the proper macs of e.g. a gateway IP. But that part is written and actually works, in contrast to the hardware part...

Yup, that was it. Bet you can't do this on master:

root@gs1900-10hp:~# ethtool -s lan9 speed 10 duplex full

and see on the other end:

root@iznogood:/tmp# ethtool enp0s25 
Settings for enp0s25:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

or vice versa:

root@iznogood:/tmp# ethtool -s enp0s25 speed 100 duplex half

root@gs1900-10hp:/# [  677.871165] RTL8380 Link change: status: 1, ports 1000000
[  677.878784] rtl83xx-switch switch@bb000000 lan9: Link is Down
[  677.885452] switch: port 7(lan9) entered disabled state
[  677.897630] rtl83xx_phylink_mac_link_state: link state: 0
[  678.686652] rtl83xx_phylink_mac_link_state: link state: 0
[  679.516773] RTL8380 Link change: status: 1, ports 1000000
[  679.524477] rtl83xx_phylink_mac_link_state: link state: 1000000
[  680.734612] rtl83xx_phylink_mac_link_state: link state: 1000000
[  680.741377] rtl83xx-switch switch@bb000000 lan9: Link is Up - 100Mbps/Half - flow control off
[  680.753594] switch: port 7(lan9) entered blocking state
[  680.759564] switch: port 7(lan9) entered forwarding state
root@gs1900-10hp:/# ethtool lan9
Settings for lan9:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
                                1000baseX/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 
                                1000baseX/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  100baseT/Half 
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 22
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: yes

I found a lot of hits with "G" about "can PoE". But almost everything was PR stuff.
I searched for technical specs. But all I found was "PoE passive 12V". :frowning:

snapshot 2021-03-08:

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

realtek-fixes branch:
I saw boot messages up to "hit enter" but no key did show any reaction, console was dead. SFP did not work, led was off.

You're probably going to hate me now, but I just fired what I have to the mailing list. These features are something I actually use, and one of the reasons I like open source is that I can stuff the things I use upstream...

And I just submitted @blogic's PoE daemon too. Can't see any valid reason for keeping it hidden like that. It can always be dropped if there ever is a replacement. For now, new users need to find the package.

4 Likes

@Borromini I've had the exact same experience with my D-Link DGS-1210-16 rev. G. The switch sits between my computer and my router. I can ping and ssh the switch from my computer, but not from the router. But traffic passes through.

To make it even weirder, this happens only when my router is connected to Port 1 (lan1) of the DGS-1210-16. When I plug the router into Port 2 (lan2) instead, I can immediately ping and ssh it without problems. Both ports are configured the same way. No iptables, ebtables or the like in place. I even flushed arp tables and rebooted all systems (DGS-1210-16, router, computer) without any change.

I have no idea what's the root cause for this.

The default configuration of the switch has a management vlan with ID 100 configured for port 1 which uses DHCP to get an IP address. All other ports have VLAN ID 1, and are reachable at 192.168.1.1. These ports offer DHCP. Port 1 is so to say set up as a WAN port which cannot be reached via ssh. Have a look at /etc/config/network after installation. There was a lot of discussion about how the default configuration of the switches should look like, this was the outcome.

Many thanks for the hint, @kobi . I stumbled upon that when flashing the device, but luckily I had a serial console to investigate. I then removed the WAN parts from /etc/config/network and added lan1 to LAN. That's why I wrote that lan1 and lan2 are configured identical. The packages ppp, dnsmasq, firewall, ip6tables, iptables and odhcpd-ipv6only are omitted from my build because I just want pure switching, no routing. :slight_smile:

This is what bridge vlan shows:

root@switch1:~# bridge vlan
port              vlan-id  
lan1              1
                  2
                  3
                  4
lan2              1
                  2
                  3
                  4
lan3              1
                  2
                  3
                  4
lan4              1
                  2
                  3
                  4
lan5              1
                  2
                  3
                  4
lan6              1
                  2
                  3
                  4
lan7              1
                  2
                  3
                  4
lan8              1
                  2
                  3
                  4
lan9              1 PVID Egress Untagged
lan10             1 PVID Egress Untagged
lan11             1 PVID Egress Untagged
lan12             1 PVID Egress Untagged
lan13             1 PVID Egress Untagged
lan14             1 PVID Egress Untagged
lan15             1 PVID Egress Untagged
lan16             1 PVID Egress Untagged
lan17             1 PVID Egress Untagged
lan18             1 PVID Egress Untagged
lan19             1 PVID Egress Untagged
lan20             1 PVID Egress Untagged
switch            1
                  2
                  3
                  4

From my perspective, ports lan1 to lan8 should behave identical.

Have been following this thread, at least sporadically, from its inception.

Is this software ready for use by non-dev level of user?

(Please please pretty please????!!!??)
TIA

1 Like

@ajoeiam , it depends on what you call a "non-dev level of user".

You need to open the case, connect to a (non-populated) serial header, provide the initial file on a TFTP server, boot it via the bootloader, stop the firewall (or configure VLAN100 on a second device), upload the sysupgrade file via SCP and flash it.

I'm not a dev and can handle these tasks, but other users probably won't.

> Sven sven
March 13

@ajoeiam , it depends on what you call a "non-dev level of user".

You need to open the case, connect to a (non-populated) serial header, provide the initial file on a TFTP server, boot it via the bootloader, stop the firewall (or configure VLAN100 on a second device), upload the sysupgrade file via SCP and flash it.

I'm not a dev and can handle these tasks, but other users probably won't.

With a pic to accurately identify the first and clear (de)structions (my goofy humor intruding) on the rest I think it might be time to get a GX1900 24 to give this a whirl.

(Driving the need to experiment is trying to come up with a way of having a private network inside another network and at the same time carefully controlling outside access from even the network.
Trying to very much minimize intrusion possibilities AND information harvesting!!)

Thanks for the information and the encouragement!

I only own a Netgear GS108T v3 and a D-Link DGS-1210-16 rev. G, so I can only help with instructions for these two devices. :frowning:

Thanks - - - perhaps one of the other devs - - - please?

Note that a number of supported devices have populated headers. I believe all the ZyXELs have them. Some models, like the GS1900-10HP, even allow access to the header without opening the case. through a hole made for this purpose.

It is also possible to flash OpenWrt from stock web UI, at least on some models. But console is still recommended for now. The default OpenWrt network config is difficult to work with, and the uboot-envtools are not properly configured if you want to change bootpartition (e.g going back to stock). So you should be prepared to use the console, even if you test out flashing from stock.

1 Like

Status update:
I got a Pi PoE hat and a "PoE to USB" adapter.
Both are working fine with Zyxel!