Support for RTL838x based managed switches

robimarko · February 25, 2022, 9:22am

This was my first idea, but I am not sure if the GPL dump U-boot is sufficient as the code where it's checked is conveniently not present or is present in a precompiled object like the board detection and config which D-Link ships as a precompiled object.

I tried decompiling the U-boot but Ghidra is not the best with MIPS.

Ok, found the part responsible for checking the tag.
Its a precompiled object in common/cmd_tool.o

I am not sure, but isn't this a breach of GPLv2?

Ok, so its looks really easy to bypass the checks, they are just called in do_bootm, will just remove the calls and that's it.

Yeah, just remove the call to fixup_checksum_linux in do_bootm and then it works

anon13997276 · February 25, 2022, 7:06pm

Hi,

I am on vacation and could only smuggle an XGS1210 past my wife. I wanted to work on network without the help of u-boot, but have not gotten around to that either.
Does the network work for the 3 10GBit ports?

There were quite a few changes in the last days in the code, it is entirely possible something got broken in the last minute. If it is the MAC-PHY link, then my suspicion would be on something in dsa.c.

Borromini · February 26, 2022, 8:19pm

Yep, oddly enough they do. Tried all three; they reply to pings. Switched to a plain gigabit port: again nothing...

anon13997276 · February 28, 2022, 6:46am

OK, this helps to limit it to something going on with the connection between SerDes and the 8218D PHY. We actually got stuck in quarantine here for another week at least. But the issue with the 8218D is something I can also look into with the XGS1210.

Borromini · February 28, 2022, 8:41am

No rush. Hope you test negative soon .

Borromini · March 5, 2022, 6:56pm

@blogic Is there a way to get realtek-poe to be more verbose? PoE stopped working at some point on my GS1900-8HP v1. OEM firmware still powers PoE clients as might be expected. All I'm seeing is the port my PoE client is connected to has its status listed as 'unkown', e.g. here the 1st port. Early on, lowering the power budget (device is specced for 70W ZyXEL says) worked for a bit, but that's not the case anymore.

# ubus call poe info
{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 65.000000,
	"consumption": 0.000000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "unknown"
		},
		"lan2": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		}
	}
}

Configuration:


config global
        option budget   '65'

config port
        option enable   '1'
        option id       '1'
        option name     'lan1'
        option poe_plus '1'
        option priority '2'

config port
        option enable   '1'
        option id       '2'
        option name     'lan2'
        option poe_plus '1'
        option priority '2'

Borromini · March 6, 2022, 11:31am

@bmork Any instructions on how I can check packet's aren't leaking on the CPU port after your patch? So I can provide my Tested-by.

(Patchwork seems to be down atm.)

bmork · March 6, 2022, 1:01pm

I simply snoop on "switch" using tcpdump, observing that there is almost no unicast packets address to external clients.

For example, snooping while I start pinging between two clients on lan1 (10.11.12.13) and lan2 (10.11.12.12) I see this:

root@OpenWrt:/# tcpdump -ni switch
[98987.064784] device switch entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on switch, link-type EN10MB (Ethernet), capture size 262144 bytes
12:42:24.743708 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:26.328199 IP 10.11.12.13 > 10.11.12.12: ICMP echo request, id 39923, seq 1, length 64
12:42:26.743079 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:28.745909 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:29.193655 DTPv1, length 38
12:42:29.697754 IP6 fe80::bea5:11ff:fe9f:e123 > ff02::1: ICMP6, router advertisement, length 120
12:42:30.748743 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:32.748181 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:34.751008 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:36.750410 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:38.753188 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
12:42:40.752645 STP 802.1d, Config, Flags [none], bridge-id 8025.80:e8:6f:97:78:00.8001, length 42
^C
12 packets captured

There is one initial ICMP packet because the address was unknown to the switch, but it learns from that packet and none of the remaining unicast packets show up on the CPU port.

The rest of the above are all multicast packets.

Note that the difference with and without the patch is only the initial inconsistency. If you toggle learning off and on, then the bridge and DSA ports will become synchronized even without the patch.

But "no one" ever does that, making this fix critical for sane bridge behaviour.

EDIT: BTW, I've now also put the patch into one of my "production" GS1900-10HPs. There I can simply observe the port statistics to validate the patch (this was how I initially discovered the bug). Ran a series of speedtests on the NR7101 hanging off the switch for fun, getting 850 Mbps over 5G Makes it easy to verify traffic spikes on the ports involved and no others. Not to mention that I'd expect the ethernet driver to explode with something like that thrown at it.

bmork · March 6, 2022, 1:30pm

WRT port statistics monitoring, in case anyone wonders about that, I added simple ethtool statistics support to mini_snmpd. It's in https://github.com/troglobit/mini-snmpd . Kind of had plans to integrate that with the OpenWrt package once it ended in a release. But I see that this is now more that a year old. How time flies...

Anyway, for now I simply run it with a config file like this:

root@gs1900-10hp:~# cat /etc/mini_snmpd.conf 
# mini-snmpd.conf

location       = "xxxxx"
contact        = "xxxxx"
description    = "ZyXEL GS1900-10HP"

# Vendor OID tree
#vendor         = ".1.3.6.1.4.1"

# true/false, or yes/no
authentication = true
community      = "public"

# MIB poll timeout, sec
timeout        = 1

# Disks to monitor, i.e. mount points in UCD-SNMP-MIB::dskTable
#disk-table     = { "/", }

# Interfaces to monitor, currently only for IF-MIB::ifTable
iface-table    = { "lan1", "lan2", "lan3", "lan4","lan7", "lan8", "lan9", "lan10" }

ethtool "lan*" {
        rx_bytes      = ifInOctets
        rx_mc_packets = ifInMulticastPkts
        rx_bc_packets = ifInBroadcastPkts
        rx_packets    = ifInUcastPkts
        #rx_errors     =
        rx_drops      = dot1dTpPortInDiscards
        tx_bytes      = ifOutOctets
        tx_mc_packets = ifOutMulticastPkts
        tx_bc_packets = ifOutBroadcastPkts                                                                                                                                                                                                   
        tx_packets    = ifOutUcastPkts
        #tx_errors     =
        tx_drops      = ifOutDiscards
}

And then I can just monitor the OpenWrt realtek switches like any other switch using cacti.

If it isn't clear: The point of all that is that the lanX interface counters only show us the CPU traffic on the realtek DSA driver. The port counters are only available using ethtool. The changes to mini_snmpd let you return named ethtool counters instead of the usual interface counters.

For example, the counters of the port attached to the NR7101 demonstrates why the interface counters are useless (or of little interest at least):

root@gs1900-10hp:~# ifconfig lan7
lan7      Link encap:Ethernet  HWaddr BC:CF:4F:D1:6B:38  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:136 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6672 (6.5 KiB)  TX bytes:0 (0.0 B)

root@gs1900-10hp:~# ethtool -S lan7
NIC statistics:
     tx_packets: 0
     tx_bytes: 0
     rx_packets: 136
     rx_bytes: 6672
     ifInOctets: 13605459970
     ifOutOctets: 2400042653
     dot1dTpPortInDiscards: 0
     ifInUcastPkts: 10533929
     ifInMulticastPkts: 4
     ifInBroadcastPkts: 131
     ifOutUcastPkts: 3216870
     ifOutMulticastPkts: 8601
     ifOutBroadcastPkts: 617
     ifOutDiscards: 0
     .3SingleCollisionFrames: 0
     .3MultipleCollisionFrames: 0
     .3DeferredTransmissions: 0
     .3LateCollisions: 0
     .3ExcessiveCollisions: 0
     .3SymbolErrors: 0
     .3ControlInUnknownOpcodes: 0
     .3InPauseFrames: 0
     .3OutPauseFrames: 0
     DropEvents: 0
     tx_BroadcastPkts: 617
     tx_MulticastPkts: 8601
     CRCAlignErrors: 0
     tx_UndersizePkts: 0
     rx_UndersizePkts: 0
     rx_UndersizedropPkts: 0
     tx_OversizePkts: 0
     rx_OversizePkts: 0
     Fragments: 0
     Jabbers: 0
     Collisions: 0
     tx_Pkts64Octets: 239642
     rx_Pkts64Octets: 37010
     tx_Pkts65to127Octets: 1450137
     rx_Pkts65to127Octets: 1336624
     tx_Pkts128to255Octets: 20590
     rx_Pkts128to255Octets: 192270
     tx_Pkts256to511Octets: 14381
     rx_Pkts256to511Octets: 20533
     tx_Pkts512to1023Octets: 11779
     rx_Pkts512to1023Octets: 71524
     tx_Pkts1024to1518Octets: 1489559
     rx_StatsPkts1024to1518Octets: 8876103
     tx_Pkts1519toMaxOctets: 0
     rx_Pkts1519toMaxOctets: 0
     rxMacDiscards: 0

EDIT: One shortcoming I meant to mention: mini_smnpd is limited to monitoring 8 ports. Which is why you see I dropped lan5 and lan6 in that config. This is hard to fix. In theory we can just increase the static tables, but it's really designed for a limited number of ports and that will cost both memory and cpu. Anyway, it's great for the small switches.

hurricos · March 6, 2022, 4:51pm

ZyXEL GS1900-24 v1 support pull request has been submitted: https://github.com/openwrt/openwrt/pull/9400

kroon040 · March 6, 2022, 6:31pm

When will there a default package in the openwrt image for POE?

hurricos · March 6, 2022, 6:34pm

There is some disagreement with how to integrate realtek-poe; see this patchwork thread.

hurricos · March 6, 2022, 6:44pm

Some issues with realtek-poe:

Using the realtek-poe-add-support-for-PoE-on-Realtek-switches.diff patch acquired by hitting diff here,
applying it with patch -p1 < /tmp/realtek-poe-add-support-for-PoE-on-Realtek-switches.diff
to a copy of the openwrt tree one commit after current snapshot master that I just used to build OpenWrt for the GS1900-24HP v1
then running make,
(after a make clean, I do get an .ipk file);
Installing the resulting realtek-poe package on a running GS1900-24HP v1 and running it generates creates an interesting segfault:

[ 2184.754425] do_page_fault(): sending SIGSEGV to realtek-poe for invalid write access to 004020cc
[ 2184.764434] epc = 77dbeff9 in libubox.so.20211120[77dba000+17000]
[ 2184.771449] ra  = 00401487 in realtek-poe[400000+3000]

... Using the toolchain's objdump:

./build_dir/toolchain-mips_4kec_gcc-11.2.0_musl/binutils-2.37/binutils/objdump -dDS /tmp/realtek-poe | less

... I get:

  401480:       1a00 095c       jal     402570 <ustream_consume@mips16plt>
  401484:       6d0c            li      a1,12
  401486:       9980            lw      a0,0(s1)
  401488:       e42b            subu    v0,a0,s1
        if (list_empty(&cmd_pending))
  40148a:       2203            beqz    v0,401492 <poe_stream_msg_cb+0x46>
  40148c:       1a00 0507       jal     40141c <poe_cmd_send.isra.0>

At this point, honestly not sure how to debug moving forward. I had to edit this post to remove incorrect assumptions -- I was looking at the wrong list_empty(&cmd_pending) in main.c, and even then, at 401488, I'm looking at something that GCC generated (I guess that's what inlining is?)

hurricos · March 6, 2022, 6:58pm

Hi there @svanheule; here's my GS1900-24HP v1:

root@gs1900-24hp:/tmp# fw_printenv
baudrate=115200
boardmodel=ZyXEL_GS1900_24HP
bootargs=console=ttyS0,115200 mem=64M quiet
bootcmd=cst fcTest; boota
bootdelay=0
bootpartition=0
ethact=rtl8380#0
ethaddr=04:BF:6D:22:F5:F8
ipaddr=10.0.7.2
netmask=255.255.255.0
serverip=10.0.7.1
stderr=serial
stdin=serial
stdout=serial

From my GS1900-24 v1:

root@OpenWrt:~# fw_printenv
baudrate=115200
boardmodel=ZyXEL_GS1900_24
bootargs=console=ttyS0,115200 mem=64M quiet
bootcmd=cst fcTest; boota
bootdelay=0
ethact=rtl8380#0
ethaddr=E4:18:6B:F7:73:85
ipaddr=192.168.1.1
netmask=255.255.255.0
serverip=192.168.1.111
stderr=serial
stdin=serial
stdout=serial

bmork · March 6, 2022, 7:20pm

That's the exact patch I've been using since it was posted. Just run make menuconfig or similar after patching and enable "realtek-poe - Realtek PoE Switch Port daemon" under Network. I usually include it in the image, but building as a package should also work.

If you have no such menu entry then something went wrong with your patching.

hurricos · March 6, 2022, 7:27pm

A make clean, inclusion as a default package to my board, and a full build of that board was enough to have the build generate that package.

I suspect the issue with realtek-poe segfaulting may be related to the difference in the PoE board on my GS1900-24HP v1 (in comparison to other PoE boards).

I don't have easy access to the board.

Here's realtek-poe -d:

root@gs1900-24hp:~# realtek-poe -d
TX -> 0x20 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x18
RX -> 0x20 0x01 0x02 0x18 0x00 0xe1 0x11 0x11 0x00 0x01 0x01 0x40
TX -> 0x18 0x02 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x14
RX -> 0x18 0x02 0x02 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x15
TX -> 0x18 0x03 0x00 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0x17
RX -> 0x18 0x03 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x14
TX -> 0x06 0x04 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x02
RX -> 0x06 0x04 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x02
TX -> 0x18 0x05 0x00 0x02 0x8a 0x00 0x3c 0xff 0xff 0xff 0xff 0xe1
RX -> 0x18 0x05 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x16
TX -> 0x1a 0x06 0x00 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1b
RX -> 0x1a 0x06 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x19
TX -> 0x1c 0x07 0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1f
RX -> 0x1c 0x07 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1c
TX -> 0x15 0x08 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x17
RX -> 0x15 0x08 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x16
TX -> 0x13 0x09 0x00 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x17
RX -> 0x13 0x09 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x15
TX -> 0x11 0x0a 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x15
RX -> 0xfe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xf4
TX -> 0x10 0x0b 0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x17
RX -> 0x10 0x0b 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x14
TX -> 0x00 0x0c 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x06
RX -> 0x00 0x0c 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x05
TX -> 0x00 0x0d 0x01 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x07
RX -> 0x00 0x0a 0x01 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x07
TX -> 0x00 0x0e 0x02 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x09
RX -> 0x00 0x0e 0x02 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x09
TX -> 0x00 0x0f 0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x0b
RX -> 0x00 0x0f 0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x0b
TX -> 0x00 0x10 0x04 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x0d
RX -> 0x00 0x10 0x04 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x0a
TX -> 0x00 0x11 0x05 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x0f
RX -> 0x00 0x11 0x05 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x0f
TX -> 0x00 0x12 0x06 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x11
RX -> 0x00 0x12 0x06 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x11
TX -> 0x00 0x13 0x07 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x13
RX -> 0x00 0x13 0x07 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x13
TX -> 0x23 0x14 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x2e
RX -> 0x23 0x14 0x00 0x00 0x00 0x00 0x07 0x02 0xff 0xff 0xff 0x3d
TX -> 0x2a 0x15 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x37
RX -> 0x2a 0x15 0x00 0x11 0xc0 0x10 0x10 0x10 0x10 0x10 0x10 0x70
TX -> 0x26 0x16 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x34
RX -> 0x26 0x16 0x00 0x03 0x01 0x4d 0x02 0x00 0xff 0xff 0xff 0x8c
TX -> 0x30 0x17 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x3f
RX -> 0x30 0x17 0x00 0x00 0x00 0x00 0x00 0x00 0xce 0x00 0x00 0x15
TX -> 0x26 0x18 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x37
RX -> 0x26 0x18 0x01 0x03 0x01 0x4d 0x00 0x01 0xff 0xff 0xff 0x8e
TX -> 0x30 0x19 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x42
RX -> 0x30 0x19 0x01 0x00 0x00 0x00 0x00 0x00 0xcd 0x00 0x00 0x17
TX -> 0x26 0x1a 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x3a
RX -> 0x26 0x1a 0x02 0x03 0x01 0x4d 0x00 0x02 0xff 0xff 0xff 0x92
TX -> 0x30 0x1b 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x45
RX -> 0x30 0x1b 0x02 0x00 0x00 0x00 0x00 0x00 0xcd 0x00 0x00 0x1a
TX -> 0x26 0x1c 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x3d
RX -> 0x26 0x1c 0x03 0x03 0x01 0x4d 0x00 0x03 0xff 0xff 0xff 0x96
TX -> 0x30 0x1d 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x48
RX -> 0x30 0x1d 0x03 0x00 0x00 0x00 0x00 0x00 0xce 0x00 0x00 0x1e
TX -> 0x26 0x1e 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x40
RX -> 0x26 0x1e 0x04 0x03 0x01 0x4d 0x00 0x04 0xff 0xff 0xff 0x9a
TX -> 0x30 0x1f 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x4b
RX -> 0x30 0x1f 0x04 0x00 0x00 0x00 0x00 0x00 0xcc 0x00 0x00 0x1f
TX -> 0x26 0x20 0x05 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x43
RX -> 0x26 0x20 0x05 0x03 0x01 0x4d 0x00 0x05 0xff 0xff 0xff 0x9e
TX -> 0x30 0x21 0x05 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x4e
RX -> 0x30 0x21 0x05 0x00 0x00 0x00 0x00 0x00 0xcc 0x00 0x00 0x22
TX -> 0x26 0x22 0x06 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x46
RX -> 0x26 0x22 0x06 0x03 0x01 0x4d 0x00 0x06 0xff 0xff 0xff 0xa2
TX -> 0x30 0x23 0x06 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x51
RX -> 0x30 0x23 0x06 0x00 0x00 0x00 0x00 0x00 0xcc 0x00 0x00 0x25
TX -> 0x26 0x24 0x07 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x49
RX -> 0x26 0x24 0x07 0x03 0x01 0x4d 0x00 0x07 0xff 0xff 0xff 0xa6
TX -> 0x30 0x25 0x07 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x54
RX -> 0x30 0x25 0x07 0x00 0x00 0x00 0x00 0x00 0xcc 0x00 0x00 0x28
TX -> 0x26 0x26 0x08 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x4c
RX -> 0x26 0x26 0x08 0x00 0x00 0x4d 0x00 0x08 0xff 0xff 0xff 0xa6

And of ubus call poe info which more clearly demonstrates bugginess:

{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 65.000000,
	"consumption": 0.000000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		{
			"priority": 0,
			"mode": "",
			"status": "",
			"consumption": 8760293210493327441055989213691904.000000
		},
		{
			"priority": 215,
			"mode": "",
			"status": "unknown"
		}
	}
}

bmork · March 6, 2022, 9:02pm

hurricos:

{
	"firmware": "v17.1",
	"mcu": "ST Micro ST32F100 Microcontroller",
	"budget": 65.000000,
	"consumption": 0.000000,
	"ports": {
		"lan1": {
			"priority": 2,
			"mode": "PoE+",
			"status": "Searching"
		},
		{
			"priority": 0,
			"mode": "",
			"status": "",

Weird. The name and priority come directly from the config, so I can't see how that's messed up. What does your config file look like?

uh-oh. Hope you don't have to pay for that

Borromini · March 6, 2022, 9:44pm

If it would help any, on my GS1900-8HP v1 (latest master, PoE PD on lan1, config here) yields this:

root@OpenWrt:~# realtek-poe -d
Failed to add object: Invalid argument
TX -> 0x20 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x18

exponentialverteilt · March 10, 2022, 6:44pm

Hi @imaginator, I'm having exactly the same problem. I just flashed my DGS-1210-28 and with the vanilla config, it successfully works with IPv6. ARP seems to not be forwarded, so there is basically no IPv4 possible.

I'm running OpenWrt 21.02.2 r16495-bf0c965af0 / Linux 5.4.179

However, I noticed, when I reassign some ports (1-9) to VLAN 100, everything works and the switch can be used at least as a switch.

The second thing I noticed: When I connect a port of each VLAN (1 and 100) of the switch to my home network (with DHCP, etc.) there seem to be some loop created, because lights start flickering fast and Wireshark displays lots of ICMP Neighbor Advertisements.

A few posts above I read about VLAN1 being enabled on all ports, but that seems to has been fixed in #4323.

Is there anything I can do to help debugging this?

Config where switching between 1-9 works:

root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd9f:ebb2:1abf::/48'

config device 'switch'
	option name 'switch'
	option type 'bridge'
	option macaddr 'bc:22:28:7a:21:40'
	list ports 'lan1'
	list ports 'lan10'
	list ports 'lan11'
	list ports 'lan12'
	list ports 'lan13'
	list ports 'lan14'
	list ports 'lan15'
	list ports 'lan16'
	list ports 'lan17'
	list ports 'lan18'
	list ports 'lan19'
	list ports 'lan2'
	list ports 'lan20'
	list ports 'lan21'
	list ports 'lan22'
	list ports 'lan23'
	list ports 'lan24'
	list ports 'lan25'
	list ports 'lan26'
	list ports 'lan27'
	list ports 'lan28'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'lan5'
	list ports 'lan6'
	list ports 'lan7'
	list ports 'lan8'
	list ports 'lan9'
#	option ipv6 '0'
#	option sendredirects '0'
#	option multicast '0'

config bridge-vlan 'wan_vlan'
	option device 'switch'
	option vlan '1'
#	list ports 'lan3'
#	list ports 'lan4'
#	list ports 'lan6'
#	list ports 'lan7'
#	list ports 'lan8'
#	list ports 'lan9'
	list ports 'lan10'
	list ports 'lan11'
	list ports 'lan12'
	list ports 'lan13'
	list ports 'lan14'
	list ports 'lan15'
	list ports 'lan16'
	list ports 'lan17'
	list ports 'lan18'
	list ports 'lan19'
	list ports 'lan20'
	list ports 'lan21'
	list ports 'lan22'
	list ports 'lan23'
	list ports 'lan24'
	list ports 'lan25'
	list ports 'lan26'
	list ports 'lan27'
	list ports 'lan28'

config device
	option name 'switch.1'
	option macaddr 'bc:22:23:7a:21:40'

config bridge-vlan 'lan_vlan'
	option device 'switch'
	option vlan '100'
	list ports 'lan1:t'
	list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        list ports 'lan5'
        list ports 'lan6'
        list ports 'lan7'
        list ports 'lan8'
        list ports 'lan9'

config device
	option name 'switch.100'
	option macaddr 'be:22:28:7a:21:40'

config interface 'lan'
	option device 'switch.100'
	option proto 'dhcp'
#	option delegate '0'

exponentialverteilt · March 17, 2022, 7:13pm

Hi, using today's snapshot, the described issue with VLAN is solved. Seems I had a misconception which commits have landed in the last release.
However, I would like to suggest some modification to the device page of https://openwrt.org/toh/hwdata/d-link/d-link_dgs-1210-28. I was living under the assumption, that the device support has already 'production quality'. Sorry.

Have you tried the snapshot, @imaginator ?