Horaco 2.5GbE Managed Switch (8 x 2.5GbE + 1 10Gb SFP+)

[AllocIn]

^^I think all of these fw's are exactly the same. Look at post 135 for the sodola one.

It probably pulls certain identifiers from nvram such as the model #. Something the firmware doesn't touch.

Yes, it seems that firmwares for those with the same port configurations are the same. 4 x 2.5Gb + 2 x 10Gb has different firmware.

 

[shimian]

There is L2 managed one with POE(1 x 802.3bt + 3 x 802.3af/at) 4*2.5Gb + 2*10Gb SFP and POE(1 x 802.3bt + 7 x 802.3af/at) 8 x 2.5Gb, and also unmanaged one POE(1 x 802.3bt + 7 x 802.3af/at) 8 x 2.5Gb + 1 x 10Gb. They have also L3 managed POE version.

Crazy that the shipping is so high on some of them, but I appreciate the links.

 

[up-n-atom]

Not sure if anyone looked at the firmware but there is a hidden factory? account

user: hengrui
password md5: 81d57ea79621e8887914f40ee4122185

I asked Horaco what the password was but they weren't forthcoming or acknowledged the existence of the account. Maybe they don't know if they're just a reseller...

http://192.168.2.1/Hengrui_mp_cfg

Factory Setting: ftdft.cgi
Logo Customize: ftlogo.cgi

and probably more

EDIT: And I just noticed https://forums.servethehome.com/ind...witch-8-x-2-5gbe-1-10gb-sfp.41571/post-401811 and also https://forums.servethehome.com/ind...witch-8-x-2-5gbe-1-10gb-sfp.41571/post-401936 which links to my discord server.

 

[OnnoO]

Am I the only one having problems with the management interface picking up an IP address in the wrong VLAN?
I have my native (untagged) vlan 1, and 3 different vlans. On my "uplink" I have vlan 1 untagged, and vlan 12-14 tagged.
The switch is configured with DHCP and right now gets an IP address in VLAN 13, instead of VLAN 1. Sometimes it seems to function correctly and get an IP address in VLAN 1.

 

[Mdk754]

Just wanted to add some data to this thread. I've now played with both the unmanaged MokerLink version of this switch, as well as the Sodola managed version. Not much to say about the unmanaged one except to document that it passes tagged traffic just fine through all ports, which is sometimes of use for people with wifi APs and such.

The managed switch has a few interesting quirks:

• The firmware images from several vendors seem to be bitwise identical (as confirmed by users with md5s above.)
• MokerLink actually posts firmware (including the latest 1.9) on their website in the Downloads tab, which probably makes it the easiest place to stay up to date. I just checked before posting and this is no longer true. Bummer. I got 1.9 (md5: 559fbd81a07ed7ce954a710c7fb2a249) from here a few days ago.
• The management interface does not support any secure protocols, and it appears to listen on its' static IP on any VLAN on any port.
• I sometimes have timeouts when trying to update the port assignments for a given VLAN and it doesn't update. Removing that VLANs PVID from any port, deleting the VLAN, and re-creating it with the updates, then re-setting the PVIDs, seems to work.

Only complaint I have so far... the management interface is fixed on VLAN 1. By default, I don't use VLAN 1 for anything, and normally don't even trunk it anywhere, I only allow tagged traffic on trunks.

In my experience, on the Sodola with firmware 1.9, it seems that the management interface will listen on any port with any PVID where you happen to configure yourself on the correct IP/subnet to ensure communication. For example, if I set port 1 to be untagged on vlan 1 with PVID 1, and set port 2 to be untagged on vlan 2 with PVID 2, I can reach the management interface by plugging into either port as long as I set the correct static address and netmask. Given this, I haven't tried telling the management interface to use DHCP, but I would hope it only sends the DHCPREQUEST out one of the VLANs (vlan 1 maybe?)

It's not obvious, but on the VLAN screen, even if you indicate a port should be an untagged member of a specific VLAN, you still have to go into the PVID screen and set the port VLAN there as well. This really should only be a single step, not two different steps.

This is quite common on managed switches. My understanding is that an untagged member port just means that traffic within a certain VLAN will leave that port without the tag, whereas the PVID says that untagged traffic coming into a port will be assigned a certain VLAN.

Poking around in the fw file ($00044bb0) we can see the following.

hengrui 81d57ea79621e8887914f40ee4122185
admin f6fdffe48c908deb0f4c3bd36c032e72

The admin md5 hash is a combination of the login+password - ie adminadmin

Can't say I've found that password, but I can say what I've tried unsuccessfully. It isn't any 6 char or fewer password with any case, number, special. It isn't any 7 or 8 char lowercase-only password. Beyond that, I'd have to get GPU acceleration into hashcat and I haven't had the time to putter with that yet. Using variations of hashcat -O -a 3 -m 0 hengrui.hash hengrui?a?a?a?a?a?a to do it. Perhaps someone with GPU accel and some time can try adding a few ?a to that, but the complexity for a brute force goes up quick. Maybe there's a wordlist that would be a better approach.

Wouldn't be easier to edit the firmware file and replace ...

Just documenting here that I tried this and it doesn't work. There must be some checksum/hash/signature on the image. It uploaded the modified image fine, but then the switch appeared to be bricked. It would no longer boot the previous or new image and no ports would light up after the initial flicker when first powered on. Turns out it was stuck in that firmware upgrade mode, but this time needed to be accessed at 192.168.1.1/24. This address can be seen in the firmware image itself if you search for byte sequences of 192.168, ie. env LANG=LC_ALL grep -obaP '\xc0\xa8' firmware.bin. This seems notable to document, as I'd image a similar situation if you happen to corrupt any other part of the firmware image when downloading. I just "accidentally" corrupted the exact bytes necessary to try a known password hash.

 

[blunden]

The managed switch has a few interesting quirks:

• The firmware images from several vendors seem to be bitwise identical (as confirmed by users with md5s above.)

It might be like on my managed Hasivo switch from the slightly older Realtek platform generation in that it has hidden menus for customizing the branding and default settings. It could also be that the branding is stored in a separate partition that isn't flashed when you upload a new firmware image.

 

[Mdk754]

It might be like on my managed Hasivo switch from the slightly older Realtek platform generation in that it has hidden menus for customizing the branding and default settings. It could also be that the branding is stored in a separate partition that isn't flashed when you upload a new firmware image.

Ack. That's almost surely the case. Another poster found the endpoint with a login page. I'm sure the vendor specific bits are just shoved into EEPROM or NVRAM somewhere behind that login. ftlogo.cgi and ftdft.cgi would imply they can customize the logo and maybe run some diagnostic tests.

 

[up-n-atom]

It might be like on my managed Hasivo switch from the slightly older Realtek platform generation in that it has hidden menus for customizing the branding and default settings. It could also be that the branding is stored in a separate partition that isn't flashed when you upload a new firmware image.

There definitely is a boot/base image partition as well as a config partition. I've wired up the serial and dumped the unmanaged version and tomorrow I have a web managed version coming in to dump.

Regardless of vendor the PCB has the same marking SWTG118AS with the unmanged version being V1.0 and the managed being V2.0. The flash size is significantly larger on the managed as well as some reset/led additions but overall they seem very compatible unless the switch chips are binned.

Attached is the dump from the unmanaged

pi@raspberrypi:~ $ sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1000 -r /tmp/SWTG118AS.bin
flashrom v1.2 on Linux 6.1.21-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q40.V" (512 kB, SPI) on linux_spi.
Reading flash... done.

I'll also modify the hash to see what's up with hengrui.

 

[grantl]

Here's a summary of information (URLs, documentation, firmware) that I've found on the (ZX/SL) SWTGW218AS 8x 2.5GbE plus 1x 10GbE SFP+ from various suppliers (Horaco/Sodola/Mokerlink, hence HSM). There are some differences between v1.3, v1.7 and v1.9 firmware... the latter adding Loop and Trunk Group Settings (static/LACP)... not a thorough review. Hope it is helpful!

 

[giver3]

I have a problem.

I mistakenly uploaded firmvare from an 8x 2.5GbE plus 1x 10GbE SFP+ switch to a 4x 2.5GbE plus 2x 10GbE SFP+ switch.
The switch allowed it, but after restarting it will not respond.
The sys LED is flashing all the time.
Cannot connect to the switch IP address 192.168.2.1 as well as 192.168.1.1 are not responding.
During startup all the LEDs light up for a while.

I have a plan to connect through some console (if it is possible) or modify the flash memory (FM25Q16A).
Any advice is welcome.

 

[OnnoO]

I recently did the same. I removed the flash chip and reprogrammed it with a full dump from another 4+2 switch and soldered it back.

 

[giver3]

Thank you for the advice.
I thought to do it that way but wasn't sure if it would work.
I have 2 more pieces of such 4+2 switches and one 8+1.

 

[OnnoO]

Remember to change the Mac address in the firmware. They must be unique in the network.

 

[giver3]

I have two pieces of news good and bad.
The good news is that after flipping the flash chip (from another switch) the switch boots. And the bad news is that I have damaged the flash chip.
The designation on the flash memory chip is: FM25Q16A (already ordered from China).
Unfortunately, the 25Q64JV chip (used as a replacement) did not want to work.
Of course, I had previously uploaded the batch from the original flash memory chip.

Remember to change the Mac address in the firmware. They must be unique in the network.

I cannot locate where exactly the MAC number is stored in the firmware.
After swapping the flash memory chips, I did not check what MAC address appeared.
The entire switch configuration was the same as in the source switch.

 

[OnnoO]

Mine starts with 1c:2a:a3

 

[giver3]

Mine starts with 1c:2a:a3

I found the MAC address at: 1fc000 in firmware.
I have the same beginning (1c:2a:a3) of the MAC address.

 

[toxic-tonic]

Hi,

has anybody an idea, what kind of hardware is used in these switches (like bootloader, ram, flash and cpu)? I'm just wondering if there is any chance of replacing the firmware with something like Openwrt...

Best regards

Toxic

 

[blunden]

Hi,

has anybody an idea, what kind of hardware is used in these switches (like bootloader, ram, flash and cpu)? I'm just wondering if there is any chance of replacing the firmware with something like Openwrt...

Best regards

Toxic

Most of these 4 + 2 switches use a particular generation of Realtek chips. There are people working on possible Openwrt support for the the slightly older generation that needs two separate Realtek chips (generally 5 + 2 switches). Look in one of the older Hasivo threads and you'll find an Openwrt forum thread linked there.

 

[joeribl]

Most of these 4 + 2 switches use a particular generation of Realtek chips. There are people working on possible Openwrt support for the the slightly older generation that needs two separate Realtek chips (generally 5 + 2 switches). Look in one of the older Hasivo threads and you'll find an Openwrt forum thread linked there.

Yes, but we are talking about L3 switches here, which have more FLASH and Memory. This has been always an "issue" with OpenWRT, and a reason why they stopped supporting a lot of devices. So i wouldnt hold my breath that for these basic swithes, there will be OpenWRT available ever.

 

[blunden]

Yes, but we are talking about L3 switches here, which have more FLASH and Memory. This has been always an "issue" with OpenWRT, and a reason why they stopped supporting a lot of devices. So i wouldnt hold my breath that for these basic swithes, there will be OpenWRT available ever.

Only some of these are L3 switches. I don't necessarily expect to ever see OpenWrt on these. I'm just telling him what I've seen in threads on the OpenWrt forum about some of these Realtek based switches.

One of the threads:

Hasivo switches

I finally received my S1300W-8XGT-SE/RTL-8XGT-SE/S1100-8XGT which I got during 11.11 sales for around $220US shipped and here is the firmware/pictures. https://drive.google.com/drive/folders/1f8WhrOcZ8uLa881B9C_aNwD3-Ijl8meE?usp=sharing The PCB shows It's just a rebadged Hasivo. I also...

forum.openwrt.org