Inserting an SFP into ports 24-28 of a DGS-1210-28 on OpenWrt changes nothing, copper keeps the link
Homelab switch: a D-Link DGS-1210-28 revision F1 that I flashed with OpenWrt so I could stop fighting the stock web UI. Everything works except the last four ports, which are the copper/fibre combo ones.
- Switch: D-Link DGS-1210-28 rev F1
- Firmware: OpenWrt 21.02.0-rc3 (r16172-2aba3e9784)
- Ports 24-28: RJ45/SFP combo behind an RTL8214FC PHY (the rest sit on RTL8218B/RTL8218D)
- Module: a generic 1G optic that links fine in another switch
Whatever I put in the cage, the port behaves as an ordinary RJ45 port. The copper side stays selected and the fibre side never comes up:
# ethtool lan28
Supported ports: [ TP MII FIBRE ]
Port: MII
Link detected: yesThe boot log does show these ports bound to the RTL8214FC combo PHY driver, and that driver is supposed to know about SFP, so the hardware side looks right.
Tried so far:
- reseated the module, then tried a second one
- pulled the copper cable out of the port entirely in case it was a priority thing - port stays on copper
- moved the module to a different switch, where it links
With the vendor firmware on it, this switch used to flip the port to fibre by itself the moment a module went in. Is there a way to select the medium on this build, or are the combo ports simply not usable yet?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Nothing is broken, there is just no automatic medium selection in the realtek target. The RTL8214FC is a combo PHY with a copper half and a fibre half, and on this firmware it stays on the MII/copper side until something tells it otherwise. Inserting a module means nothing to the driver, because nobody implemented the switchover.
You select the medium yourself from userspace:
After that the cage is the active medium on that port and the optic comes up. To hand the port back to the RJ45 half:
Same call for each of the other combo ports, one per port.
What you remember from the stock firmware was a limited auto-select: it looked at both halves and copper won whenever both had a link. That is why this reads like a regression, but it is not - the function was simply never written for this target.
Two caveats. It is CLI only, it is not exposed in LuCI, and people have been asking for that for a while. And nothing on this build can pick the medium for you, so if you want fibre after every boot, make sure taht call actually runs.
That was it, thank you. One call and the port swapped over:
The optic came up immediately and the RJ45 half went quiet. I did the same for the other three combo ports and put the four calls in a startup script, since as you say nothing remembers the choice.
Mildly irritating that a per-port toggle has to live in a shell script, but the ports are usable now, which is what I needed.
Worth knowing before you build monitoring on top of those ports: link state on the SFP side of these boards is not always trustworthy. On the DGS-1210-10P the device tree has no sfp nodes at all, so the kernel never gets module-present or loss-of-signal and the MAC reports a permanent carrier -
ip linkprints<BROADCAST,MULTICAST,UP,LOWER_UP>for lan9 with an empty cage, and it stays up with a GLC-T-CO copper SFP seated and no patch cord in it. The DGS-1210-10MP does not behave that way, because its DTS already has the nodes.The fix there was a device tree change modelled on the 10MP and on the Zyxel GS1900-10HP: an i2c-gpio bus per cage, an sfp node per cage with los-gpio, mod-def0-gpio and tx-disable-gpio,
sfp = <&sfp0>referenced from the port,phy-mode = "1000base-x"andmanaged = "in-band-status". With those in place the cage is probed over I2C and the carrier finally tracks the actual optical signal.On the stock images of that period the behaviour persists, so if anything of yours watches carrier on a combo or SFP port, verify that it actually drops when you pull the fibre.