Yeah that's included in my build 
Another question: I assume it's Realtek specific, like the name suggests? So not usable for other OpenWrt supported platforms that come with PoE? Like some EdgeRouter models e.g.? Just out of curiosity.
I set the package here to depend on the Realtek target, locally.
The VLAN 100 thing comes from
I'm not convinced that it is a good idea. I believe most users will end up like you: Wondering where the management interface went.
I believe it is better to replicate stock firmware behaviour by default. Assuming users will flash from stock to OpenWrt without necessarily having console, it might even make sense to pick up both management VLAN and address from the stock config. Then you would just reach luci exactly where you just used the stock web gui.
The stock CLI config is available to OpenWrt by simply mounting the partition it is saved in:
root@gs1900-10hp:~# mount -o ro -t jffs2 /dev/mtdblock3 /mnt
[59617.370439] jffs2: notice: (3572) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
root@gs1900-10hp:~# ls -la /mnt/
drwxr-xr-x 4 root root 0 Jan 1 1970 .
drwxr-xr-x 1 root root 0 Dec 8 08:23 ..
-rw-r--r-- 1 root root 1052 Jan 1 2020 backup-config
drwxr-xr-x 2 root root 0 Jan 1 2019 ssh
-rw-r--r-- 1 root root 1985 Nov 14 21:17 startup-config
I don't think a full parser is worth it, but just fetching the management parts might be. This could be done in a uci-defaults script. If someone does the work..,..
The current PoE package only implements the Broadcom PoE control protocol. If this happens to be a Broadcom thing, it might be reusable on other devices, but there is currently no universal PoE interface (yet).
Some Realtek switches use different PoE platforms (Microsemi PD69xxx, TI platform on that one TP-Link switch), so these are currently not supported.
A follow-up question regarding this: if fw_printenv does not show the bootpartiton variable, does that mean I cannot manipulate it?
# fw_printenv|grep boot
bootargs=console=ttyS0,115200 mem=64M quiet
bootcmd=cst fcTest; boota
bootdelay=0
I first thought boota implied partition 0 but it's just the macro you mentioned, so there's no way to tell from this what partition is active I presume (this is from the OpenWrt ramdisk).
You can manipulate it. But there isn't any automatic config generation (yet). Manual setup example (with slightly obfuscated numbers again):
root@gs1900-10hp:~# echo "/dev/mtd2 0x0 0x1000 0x10000" >/etc/fw_sys.config
root@gs1900-10hp:~# fw_printenv -c /etc/fw_sys.config
resetdefault=0
mac_start=BC:CF:4F:12:34:56
mac_end=BC:CF:4F:12:34:60
sn=S202L28001234
dualfname1=2.60(AAZI.2)C0.bix
dualfname0=x.bin
bootpartition=0
And similar with fw_setsys -c /etc/fw_sys.config of course
I was looking at how to set up this automatically in an elegant way. Generating the config and some symlinks for fw_printsys and fw_setsys is simple. But that would need to run on every boot, which means an additional init script. Or the symlinks would just have to be there on every device and do nothing unless you have that partition config. I don't know what's best?
EDIT: if you wonder about those dualfnameX variables: They are written when you flash from stock firmware. I do not know what they are used for. Maybe just a UI thing. It's the actual file name you flash, so it's pretty meaningless. The "x.bin" is the result of me creating a shorter filename for an OpenWrt initramfs image 
Thanks. I rebooted into u-boot, and used the setsys/savesys commands you mentioned earlier. However, bootpartition=0 shows up when I issue printsys, not when I issue printenv. Similarly, with OpenWrt running from RAM fw_printenv doesn't show the bootpartition value either.
Either way, when I issue boot it's clearly booting OpenWrt from partition 0, so all looks well. However, I am missing an overlayfs. I'm seeing these messages:
logread -e jffs2
Wed Dec 9 12:43:44 2020 kern.info kernel: [ 0.166640] jffs2: version 2.2 (NAND) (SUMMARY) (ZLIB) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, In.
Wed Dec 9 12:43:44 2020 kern.notice kernel: [ 1.306851] 0x000000160000-0x000000260000 : "jffs2"
Wed Dec 9 12:43:44 2020 user.notice kernel: [ 12.393597] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
logread -e mount
Wed Dec 9 12:43:44 2020 user.notice kernel: [ 12.393597] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
Wed Dec 9 12:44:16 2020 user.notice ucitrack: Setting up non-init /etc/config/fstab reload handler: /sbin/block mount
Wed Dec 9 12:44:18 2020 daemon.err mount_root: failed - mount -t jffs2 /dev/mtdblock8 /rom/overlay: Not a tty
And this, but given it's 16 MB flash, it seems a bit strange?
Wed Dec 9 12:44:18 2020 kern.err kernel: [ 60.471289] Too few erase blocks (2)
/proc/mtd contents:
cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "u-boot-env2"
mtd3: 00100000 00010000 "jffs"
mtd4: 00100000 00010000 "jffs2"
mtd5: 006d0000 00010000 "firmware"
mtd6: 00280000 00010000 "kernel"
mtd7: 00450000 00010000 "rootfs"
mtd8: 00020000 00010000 "rootfs_data"
mtd9: 006d0000 00010000 "runtime2"
/rom size:
df -h /rom
Filesystem Size Used Available Use% Mounted on
/dev/root 4.3M 4.3M 0 100% /rom
ROM size doesn't look outrageous to me, but it might be tight because of the dual partition setup maybe? If I'm not mistaken mtd8 is 131072 bytes (hex 00020000?) which translates to 128 kB? That does sound a bit small for rootfs_data?
No, there isn't all that much flash with it divided in two like this. But it is more than enough for the packages you'd want on a switch, I believe.
Did you build a rootfs with lots of stuff? This is what mine looks like:
root@gs1900-10hp:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "u-boot-env2"
mtd3: 00100000 00010000 "jffs"
mtd4: 00100000 00010000 "jffs2"
mtd5: 006d0000 00010000 "firmware"
mtd6: 002c0000 00010000 "kernel"
mtd7: 00410000 00010000 "rootfs"
mtd8: 001e0000 00010000 "rootfs_data"
mtd9: 006d0000 00010000 "runtime2"
root@gs1900-10hp:~# df -hT
Filesystem Type Size Used Available Use% Mounted on
/dev/root squashfs 2.3M 2.3M 0 100% /rom
tmpfs tmpfs 60.3M 64.0K 60.2M 0% /tmp
/dev/mtdblock8 jffs2 1.9M 240.0K 1.6M 13% /overlay
overlayfs:/overlay overlay 1.9M 240.0K 1.6M 13% /
tmpfs tmpfs 512.0K 0 512.0K 0% /dev
I did yes. I'm sharing configurations (SSL etc.) between multiple devices so extra stuff gets pulled in. Looks like I'll be stripping. Thanks for confirming, and for all your help.
@anon13997276 Thanks a lot for your help as well, and my apologies for filling this thread with tons of questions.
Thanks for asking all those questions! I am sure the questions and bmork's answers will be very helpful for anyone who wants to set up a realtek-based switch. When I see the level of sophistication we already have in configuring these devices it is also amazing how far we all got in making OpenWRT run so well on these switches in such a short time.
@bmork For what it's worth I seem to be encountering duplicate ping messages (DUP!) as well when the switch comes online. No idea if this has been solved in kobi's tree by now?
I think the config looks pretty sane now:
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr 'xx:xx:xx:xx:xx:xx'
config bridge-vlan 'lan_vlan'
option device 'switch'
option vlan '1'
option ports ' lan1 lan10 lan2 lan3 lan4 lan5 lan6 lan7 lan8 lan9'
config device 'lan_switch_1_dev'
option name 'switch.1'
option macaddr 'xx:xx:xx:xx:xx:xx'
config interface 'lan'
option ifname 'switch.1'
option proto 'static'
option ip6assign '60'
list ipaddr '10.0.0.254/24'
I don't think it is. I also see those. Must be related to mac address learning. Will only happen for the very first packet for any device. So it's not a major problem.
I have added a wiki entry, I'll add the experiences and information you guys shared piecemeal, when I have the time.
I believe by default the hardware traps packets from new source address to the cpu-port. From @LGA1150 we learned that we need to make sure that the packet then is not forwarded twice by the bridge and the switch layer. Probably the reason code is a different one in the cpu-tag when this happens, so that skb->offload_fwd_mark is not set. This is hopefully easy to fix.
If I build from OpenWrt trunk does the D-Link DGS-1210-10P build also work for the DGS-1210-10? I don't see anything in the DTS file that appears to reference PoE related hardware.
Ray
For PoE there is a package, since all of it is handled in user-space. Package name is rtl83xx-poe IIR. Otherwise the dts should work.
Hi,
I have an Zyxel GS1900-8HP, and I think it is also an RTL838x chipset. Is there already a snapshot to test? I only use vlans (tagged and untagged) and poe, and looking in the wiki that should work.
regards Richard
The snapshot builds are broken for the realtek target, so I did a self build. You can try that if you'd like - but are the internals the identical between the 8HP and the 10HP? At least when it comes to flash layout and whatnot? If not, that could brick your device.
I can link you to one of my builds, they're not compatible with the OpenWrt package repos though (and come with a limited package set - no dnsmasq etc.). So if you'd use it as a switch, no problem, but the builds aren't suited for use as a router.
Borromini: could you explain what was wrong with the latest patch? Do you have any logs available?
I took the switch out of the network yesterday, will investigate today. At this point I can only say ath79 devices from the same buildrun flash fine. Gonna hook up serial again .
Hi ,
I got an zyxel GS1900-8HP. He looks the same as the zyxel GS1900-10HP.
here some info, I want to flash it but I want to make sure it is possible with de GS1900-10HP image.
U-Boot Version: 2.0.0.60266 (Jul 17 2015 - 12:29:50)
CPU: 500MHz
DRAM: 128 MB
FLASH: 16 MB
Model: ZyXEL_GS1900_8HP
SN: S162L33000409
MAC: 60:31:97:80:4F:B3 - 60:31:97:80:4F:BB
Press SPACE to abort boot script: 0
## Booting image from partition ... 0
Version: V2.40.2
Created: 2019-06-05 11:49:46 UTC
Size: 6613306 Bytes = 6.3 MB
Verifying Checksum ... OK
Uncompressing Image ... OK
U-Boot Version: 2.0.0.60266 (Jul 17 2015 - 12:29:50)
CPU: 500MHz
DRAM: 128 MB
FLASH: 16 MB
Model: ZyXEL_GS1900_8HP
SN: S162L33000409
MAC: 60:31:97:80:4F:B3 - 60:31:97:80:4F:BB
Press SPACE to abort boot script: 0
RTL838x# ?
So it is and RTL838x chip, below the flash layout
## RTL838x# flshow
=============== FLASH Partition Layout ===============
Index Name Size Address
# 0 LOADER 0x40000 0xb4000000-0xb403ffff
1 BDINFO 0x10000 0xb4040000-0xb404ffff
2 SYSINFO 0x10000 0xb4050000-0xb405ffff
3 JFFS2_CFG 0x100000 0xb4060000-0xb415ffff
4 JFFS2_LOG 0x100000 0xb4160000-0xb425ffff
5 RUNTIME1 0x6d0000 0xb4260000-0xb492ffff
6 RUNTIME2 0x6d0000 0xb4930000-0xb4ffffff
and of course a picture of inside
So should this be a possible ?
