I checked it by Wireshark on Windows, but there is no packet tagged with vid 100...
1 Like
I managed to get flash of my 1910-8-PoE+ dumped yesterday. They've gone through a lot of hoops to hide the fact that U-boot and Linux is running inside - no luck on getting shell on U-boot or Linux inside - HP has set up scripted menus and hidden all standard output. Unfortunately, I had to desolder the chip, using SOP-16 clip didn't work out, as SoC was interfering with detection.
Output of binwalk is:
binwalk 1910-8-poe+_flashdump.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
1024 0x400 U-Boot version string, "U-Boot 1.1.4 (2017-04-14 - 15:05:19)"
167600 0x28EB0 CRC32 polynomial table, big endian
230128 0x382F0 JFFS2 filesystem, big endian
245400 0x3BE98 Copyright string: "Copyright (c) J.S.A.Kapp 94-96."
250064 0x3D0D0 CRC32 polynomial table, big endian
590164 0x90154 7-zip archive data, version 0.2
1049600 0x100400 U-Boot version string, "U-Boot 1.1.4 (2017-04-14 - 15:05:19)"
1216176 0x128EB0 CRC32 polynomial table, big endian
1278704 0x1382F0 JFFS2 filesystem, big endian
1293976 0x13BE98 Copyright string: "Copyright (c) J.S.A.Kapp 94-96."
1298640 0x13D0D0 CRC32 polynomial table, big endian
1638740 0x190154 7-zip archive data, version 0.2
3156344 0x302978 U-Boot version string, "U-Boot 1.1.4 (Aug 9 2013 - 10:45:30)"
3326280 0x32C148 Copyright string: "Copyright (c) J.S.A.Kapp 94-96."
3330952 0x32D388 CRC32 polynomial table, big endian
3336532 0x32E954 7-zip archive data, version 0.2
3474784 0x350560 7-zip archive data, version 0.2
8468231 0x813707 XAR archive, version: 19827, header size: 3486, TOC compressed: 2045766838601749417, TOC uncompressed: 8590467829423221911
15065464 0xE5E178 U-Boot version string, "U-Boot 1.1.4 (2017-04-14 - 15:05:19)"
15250472 0xE8B428 CRC32 polynomial table, big endian
15258900 0xE8D514 7-zip archive data, version 0.2
15398776 0xEAF778 7-zip archive data, version 0.2
Too bad, that binwalk didn't unpack too much by itself, compared to Broadcom FastPATH switches, for example.
HPE probably uses dual SPL/main U-boot layout, both of which are updateable through console, as U-boot is also found in firmware package, and four times on the flash itself. Output of strings is quite interesting and mentions a lot of RTL838x models, including 1920 series as well, like 1920-8G-PoE+ (65W) Switch JG921A
Unfortunately I found no JTAG header on the board, but front console access should help hacking it anyway.
I'm willing to share the dump if anyone else would like to also take a look. Stay tuned for more 
@svanheule have you had any luck with getting GPL source from HPE?
HPE consequently ignored my GPL requests 
I only got proper replies from a person working on FW security (or similar), but either he's just blowing smoke to keep me out of their code, or he's being stonewalled internally too.
Not even a "we don't support this device any more" kind of reply (because they pushed an OpenSSL fix last year, so they were still maintaining it then). 
I guess it's time to dig up Ghidra now, then.
I might do the same for 1820 series, which look very, VERY similar to Netgear GS728TXS, but are the mentioned "Brodcom FastPATH". Netgear actually host their GPL source for this device on their webpage, without asking. I guess they are not getting my 10$ for the GPL code.
I lately was in contact with a very friendly HPE resp. Aruba customer service representative who shared them GPL sources with me. While the request took half a year to process I not only got them sources for the Marvell based model I have but they initially also posted them Realtek U-Boot sources (actually in error as them H3C engineers forgot which is which (;-p).
Tomorrow morning once I'm behind a proper PC again I will try to dig it up and post them somewhere for you...
2 Likes
This is verbatim the GPL U-Boot sources I got back in March. The rar password is: linux20210303. Maybe it can be added to gpl_source_drops on @biot's rtl83xx site.
2 Likes
Maybe you could try directly with H3C as the OEM. Unfortunately it is kinda hard to correlate the HPE branded models to the right H3C models. Some are easy, the HPE 5120-EI is the H3C S5120-EI, but the HPE 5510-HI is the H3C S5000V3-EI. I guess the HPE 1920 could be H3C S5120V2-LI, but HPE didn't push the upgrade to ComWare 7 out.
In general, everything OfficeConnect 19xx, FlexNetwork and FlexFabric is developed and manufactured by H3C.
Everything formerly ProCurve now Aruba is cooked up by HPE itself.
I have no idea what hell the officeconnect 1820/1920s crawled out ( both are same Hardware different Firmware, just like the 1920/5120-SI, 1950/5130-EI, ...).
Thanks a lot! This should ease my work significantly.
Regarding Linux for 1920s, it shouldn't be that much necessary, but could help sorting out PoE, I still haven't found a way to get a root shell on those.
Kind of off-topic, but wouldn't you mind asking about 1820s (J9979A/J9980A) as well, or helping me get in touch with that representative? 
Probably won't differ that much from Netgear GS728TX/S3300X-28X, what I extracted from their images and flash dumps is really, REALLY, similar, and I've got GPL sources from Netgear. Unfortunately all the switch magic is hidden in the Fastpath application running in userspace.
@tgt79 Regarding 1820s, they are different hardware - Broadcom Fastpath based, as I mentioned previously, at least J9979A/J9980A which I own. All of them (8/26/52-ports, PoE/non-PoE as well) run the same binary.
I'm now adding support for the Netgear GS110TPv3 which appears to have less multiplexing of the GPIO values used for SFP as follows:
====== Fiber =================
Fiber Port Number: 2
------------ Fiber Detect
LPort Present MediaChg OE Status LOS Status
------ -------- --------- ---------------------- ----------------------
8 OE OE Enabled (GPIO:EXT_14) Enabled (GPIO:EXT_7 )
9 OE OE Enabled (GPIO:EXT_13) Enabled (GPIO:EXT_6 )
------------ Fiber Optical
LPort I2C DEV I2C TYPE ID Delay SCK SDA
------ -------- --------- ----- ------- ------ ------
8 0 8 BITS 0x50 1000 EXT_36 EXT_28
9 1 8 BITS 0x50 1000 EXT_36 EXT_27
------------ Fiber TX Disable
LPort Method
------ ------
8 GPIO(EXT_9 )
9 GPIO(EXT_8 )
I've not used SFP modules on Linux before, so other than ensuring I have a link on the SFP port are there any diagnostic or utility programs I can use to verify the SFP is fully functional?
@Leo-PL just to be sure: are you talking about "1920s" as plural of 1920 (JG* product number) or about the actual 1920S Series (JL* product number).
Edit: one thing I like about the HPE OfficeConnect switches is their lifetime warranty, because it really covers a lifetime. The default warranty runtime is 100 years and so far they have been delivering (replaced one 4200G after 15 years, and a 1820 after 4 that got hit by lightning). You will only get refurbished devices as replacements after a certain point though.
ethtool. you should be able to read out the eeprom, and sensor data if available, using ethtool -m. And you should be able to talk to the phy if there is one in the SFP (copper only). Look for the PHYAD address in the link settings and autoneg works all ways.
You'll also see the SFPs detected in the kernel log:
[ 3.880851] i2c-gpio i2c-gpio-0: Slow GPIO pins might wreak havoc into I2C/SMBus bus timing
[ 3.890693] i2c-gpio i2c-gpio-0: using lines 184 (SDA) and 185 (SCL)
[ 3.898350] i2c-gpio i2c-gpio-1: Slow GPIO pins might wreak havoc into I2C/SMBus bus timing
[ 3.908070] i2c-gpio i2c-gpio-1: using lines 190 (SDA) and 191 (SCL)
[ 3.915831] libphy: SFP I2C Bus: probed
[ 3.920568] sfp sfp-p9: Host maximum power 1.0W
[ 3.926509] libphy: SFP I2C Bus: probed
[ 3.931234] sfp sfp-p10: Host maximum power 1.0W
[ 4.342773] sfp sfp-p10: module FiberStore SFP1G-SX-85 rev sn D87B2312465 dc 171202
[ 4.433086] sfp sfp-p9: module OEM GLC-T rev B sn M0312A804 dc 130823
And also the phys (if it exists) when you ifconfig the port up:
[5309425.355075] rtl83xx-switch switch@bb000000 lan9: PHY [i2c:sfp-p9:16] driver [Marvell 88E1111]
This is all mostly testing i2c. But that's the really important part. You could also verify that you can turn off the laser by using an SFP with DOM as detector in the other end.
1 Like
Courageous souls, eager to try out my new RTL8231 driver, can find the freshly submitted patches here:
https://lore.kernel.org/linux-gpio/cover.1620735871.git.sander@svanheule.net/T/
You will need an MDIO bus to connect to the expander chip, for which I currently use a bitbanged implementation:
mdio1: mdio {
compatible = "virtual,mdio-gpio";
#address-cells = <1>;
#size-cells = <0>;
/* Requires upstream driver for internal GPIOs*/
gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>,
<&gpio0 3 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&gpio_mdx_pins>, <&gpio_shadowing>;
gpio1: expander@0 {
compatible = "realtek,rtl8231";
reg = <0x0>;
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&gpio1 0 0 37>;
};
};
switchcore@1b000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1b000000 0x20000>;
pinctrl_gpio: pinmux@a0e0 {
compatible = "pinctrl-single";
reg = <0xa0e0 0x4>;
pinctrl-single,bit-per-mux;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x1>;
#pinctrl-cells = <2>;
gpio_mdx_pins: pinmux_gpio_mdx_pins {
pinctrl-single,bits = <0x0 0x0 0x1>;
};
};
pinctrl_shadowing: pinmux@0144 {
compatible = "pinctrl-single";
reg = <0x0144 0x4>;
pinctrl-single,bit-per-mux;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x1>;
#pinctrl-cells = <2>;
gpio_shadowing: pinmux_gpio_shadowing {
pinctrl-single,bits = <0x0 0x0 0x2>;
};
};
};
2 Likes
Do you mean the 1st part about Linux sources of my post? If so, it's about JG537A specifically, so not even a 1920, but 1910.
If it's about the last part (1820), then neither again, I meant the Aruba stuff here, which I'm working on as well, I just wanted to clarify that those are very different hardware than 1920 series.
Great work! I tried to backport the pending patches to my 5.10 branch and it works
Currently, I tested only minimal support of RTL8231-related drivers.
...
[ 1.786474] libphy: GPIO Bitbanged MDIO: probed
[ 1.868006] rtl8231-pinctrl: Failed to locate of_node [id: -2]
[ 1.879438] rtl8231-leds: Failed to locate of_node [id: -2]
...
[ 6.531362] rtl8231-leds rtl8231-leds.1.auto: scan mode missing or invalid
[ 6.539227] rtl8231-leds: probe of rtl8231-leds.1.auto failed with error -22
...
/sys/class/gpio, /sys/kernel/debug/gpio
root@OpenWrt:/# ls -alh /sys/class/gpio/
drwxr-xr-x 2 root root 0 Jan 1 1970 .
drwxr-xr-x 17 root root 0 Jan 1 1970 ..
--w------- 1 root root 4.0K Jan 1 1970 export
lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip451 -> ../../devices/platform/mdio-gpio/mdio_bus/gpio-0/gpio-0:00/gpio/gpiochip451
lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip488 -> ../../devices/platform/soc/b8003500.gpio-controller/gpio/gpiochip488
--w------- 1 root root 4.0K Jan 1 1970 unexport
root@OpenWrt:/# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 451-487, parent: mdio_bus/gpio-0:00, rtl8231-pinctrl, can sleep:
gpio-454 ( |reset ) in hi <-- released (reset button on BSH-G24MB, active-low)
gpiochip0: GPIOs 488-511, parent: platform/b8003500.gpio-controller, b8003500.gpio-controller:
gpio-488 ( |red:sys_loop ) out lo
gpio-490 ( |mdio-gpio ) out lo
gpio-491 ( |mdio-gpio ) in hi
root@OpenWrt:/# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 451-487, parent: mdio_bus/gpio-0:00, rtl8231-pinctrl, can sleep:
gpio-454 ( |reset ) in lo <-- pressed
gpiochip0: GPIOs 488-511, parent: platform/b8003500.gpio-controller, b8003500.gpio-controller:
gpio-488 ( |red:sys_loop ) out lo
gpio-490 ( |mdio-gpio ) out lo
gpio-491 ( |mdio-gpio ) in hi
root@OpenWrt:/# REBOOT <-- reboot triggered
IMO, CONFIG_MDIO_BITBANG and CONFIG_MDIO_GPIO may have to be selected by CONFIG_MFD_RTL8231.
EDIT:
repo: https://github.com/musashino-build/openwrt/tree/tgtbump/rtk_5.10_rtl8231
1 Like
I get those warning messages too, but I don't know how to get rid of them. I've put them in the cover letter of my patch sent and asked for guidance
Althought this currently uses CONFIG_MDIO_GPIO, this is not a hard requirement. Any MDIO bus will do. A next step would be to implement the hard MDIO bus provided by the LED/GPIO peripheral. Then the bitbanging won't required anymore. This driver also shouldn't be specific to the Realtek platform. It's an MDIO device, so any MDIO bus should do.
1 Like
Ah, indeed. thank you!
I've updated the pinmux config in the DTS snippet I posted above. @johnd2 was experiencing spontaneous device resets after my driver probed the RTL8231. But the T1600G also does register shadowing, which wasn't disabled by the pinmux config. I've added another pinmux config (really an peripheral enable setting, but whatever, we need to set that flag correctly) to make sure the register shadowing is disabled.
Edit: The extra pinctrl didn't fix the reset issue on the T1600G yet... 
3 Likes
I finally got my DLink DGS-1210-10P version F1 to work properly with OpenWRT. Up until now it was not letting traffic pass the switch, one could merely ping/ssh to it. The only packets that seemed to pass were MDNS frames from the printer. I started to compare register settings one-by-one with my Zyxel GS1900 10HP and stumbled on the Packet Inspection Engine being set up with forwarding rules by u-boot, even if "rtk network on" is never used to configure the network. This is the comparison between the relevant registers:
U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Oct 20 2017 - 15:42:41)
Board: RTL838x CPU:500MHz LXB:200MHz MEM:300MHz
DRAM: 128 MB
SPI-F: 1x32 MB
Loading 1024B env. variables from offset 0x80000
Board Model = DGS-1210-10P-F1 Cameo_bdinfo_get_BoardID [293]
Switch Model: RTL8380M_INTPHY_2FIB_1G_DEMO (Port Count: 10)
Switch Chip: RTL8380
**************************************************
#### RTL8218B config - MAC ID = 8 ####
Now Internal PHY
Net: Net Initialization Skipped
rtl8380#0
Hit Esc key to stop autoboot: 0
u-boot>#
Abort
Ctrl-c was pressed..(Changing to u-boot console mode(0))
<INTERRUPT>
u-boot># md.l 0xbb006100 4
bb006100: 00000fff 00000fff 00000001 00000000 ................
u-boot># md.l 0xbb006910 14
bb006910: 00000000 00001003 00000000 00000000 ................
bb006920: 00000043 00440000 00000000 00000000 ...C.D..........
bb006930: 00000000 00000000 00000000 0000ffff ................
bb006940: ffff0000 00000000 00000000 00001c00 ................
bb006950: 80000000 00000000 00009c1c 00002000 .............. .
On the Zyxel:
RTL838x# printenv boardmodel
boardmodel=ZyXEL_GS1900_10HP
RTL838x# md.l 0xbb006100 4
bb006100: 00000fff 00000000 00000000 00000000 ................
RTL838x# md.l 0xbb006910 14
bb006910: 00000000 00000000 00000000 00000000 ................
bb006920: 00000000 00000000 00000000 00000000 ................
bb006930: 00000000 00000000 00000000 00000000 ................
bb006940: 00000000 00000000 00000000 00000000 ................
bb006940: 00000000 00000000 00000000 00000000 ................
From registers bb006104 (Power control for the 12 Inspection Engines) and bb006108 (template configuration for packet matching) one can see that the 12 Engine blocks are powered on and a template is being configured. bb006914 shows that someone was using the control register to manipulate the IACL table (https://www.svanheule.net/realtek/maple/table/iacl), it seems rule 3 in that table was written to. At this point I got a bit paranoid, because the SDK does not suggest to delete any rules on startup, the default u-boot from the SDK does not set any PIE rules and one could use these to exfiltrate data from the LAN. But it turns out these rules merely protect the switch during configuration, i.e. no leakage of packets from one port to another. The 12 rules I found all redirect all kinds of packets on various layers to the CPU-port, in particular ARP-frames, IPv4 and IPv6 and UDP. Which seems to explain the strange MDNS traffic.
I will submit a patch that on switch initialization will always delete any PIE rules present. This will make the DLink work, and protect against any funny rules in the PIE possibly compromising the network.
1 Like
I somehow get the feeling that the resets caused when loading the RTL8231 driver on the T1600G-28TSv3 are also related to some improper register configuration. Moreover, when the GPL uboot complains about not recognizing the boardname. Does anyone have a full register dump of a RTL8382M at uboot stage of another device which I could compare against mine with faked and not faked boardname?