act mode is the green (gigabit) led blinking while traffics happen right? if yes, then act mode led is on.
i'm not sure about port expander, but sfp works, with gigabit sc transciever and gpon transciever.
No, in original firmware for poe devices mode button flips the showing of poe status or activity status of the lan/port leds. What the port led shows is showed with the poe or link/act led being lit.
But there is no way of controlling the port leds in openwrt as of now so they always show the link/act function.
But on your model I donāt think there is a mode switch or poe and linc/act led since you only have data ports.
1 Like
Check the DTS for -28 and -28MP. I only had to add a few definitions for the LEDs and buttons @flygarn12 is talking about and to move the common parts to a separate file to complete device support for the -28MP.
@flygarn12 Was this the one D-Link where the reset GPIO caused problems?
-28 and -28MP includes rtl8382_d-link_dgs-1210-28_common.dtsi, while the -10p and -10mp do not.
Isnt it just make sense just to make a new 1210-10_common.dtsi, then includes it on -10p and -10mp?
Yes, this is similar to what I did for the -28MP. Check out this PR: https://github.com/openwrt/openwrt/pull/11293
There is a parallel external reset circuit to reset everything on the pcb that took a while to find and track down and test.
Originally in my āclean up dts treeā PR there was pretty much divided common files, but after everyone was happy in the reviews for the pr there wasnāt much left of the cleanup.
The new port status view in OpenWrt 23.05-rc3 looks really nice on my Zyxel GS1900-48.
However, the SFP slots on port 49+50 are empty (no SFP present), but they still show up as link-up. Is that expected?
The phy link itself is always up even though no module is using the link.
Maybe a better sfp driver in the future can solve it but SFP isnāt really āsmartā things and it isnāt ethernet ports.
3 Likes
If it is the same as in master you will se the interfaces connected to the port if you hold the mouse over the āgreen lineā. But the color for the port change with interface color or get a āchain colorā links for a trunk port.
1 Like
If you like that then you should take a look at the PR to introduce a page for LLDP neighbors - this makes these large switches much easier to administer IMHO, as you can see which peer is on which port quickly and easily.
3 Likes
Does anyone else have bogus MAC addresses for switch ports on 23.05-rc3? See OpenWrt 23.05.0-rc3 - Third Release Candidate - #15 by hailfinger for details.
I'm currently swamped with work, so I won't be able to bisect this regression between -rc2 and -rc3 before the weekend.
Hopefully merged before the final 23.05 release
I can confirm. On an older build the MAC was valid in all ports. Now only the actual switch interface (which is tagged in my configuration) seems to have a valid MAC.
# ip a s|grep -B1 bc:
12: switch.1@switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:a5:xx:xx:xx:xx
@hailfinger My money is on commit 4ebba8a05d0 messing up something in target/linux/realtek/base-files/etc/board.d/02_network, that's the last commit in 23.05 touching the realtek target from what I can see. If I find time to run another build this weekend I'll see what reverting it does.
I suspect "realtek: eth: Do not write directly to dev->addr" as the culprit, but I didn't look into the patch in detail.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=e7aae81d03f21dda8a371163fe347ea949381e34
That was backported to 23.05 three months ago, and my previous (working) 23.05 build is from end of July, so that is outside the window if you ask me. Seemed functional till 680a4c7e12 at least.
Edit: I can confirm reverting 4ebba8a05d0 restores the MACs on my GS108T v3.
1 Like
From what I can see in the commit there's not that much going on so I suspect some syntax error somewhere in the scripts.
I can confirm the same behaviour on a GS1900-8HP v1. Without 4ebba8a05d0: MACs as expected. With 4ebba8a05d0: all zeroes.
@Borromini Have you tried reverting only 02_network? As an alternative, have you tried deleting /etc/board.d/03_gpio_switches ?