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

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
L

LittleMike

New Member
May 7, 2024
2
0
1
Forgive me if this has been answered, search has failed me. But I bought a similar variant to this one:

MokerLink 4 Port 2.5G PoE Managed Switch with 1 Port 10G Ethernet Port, 1 Port 10G SFP+ Slot, IEEE8023af/at PoE 65W, Metal Web Managed Fanless Small Network Switch

Will the 1.9 firmware posted in this thread work for that as well, or are the boards different? In the management UI, it tells me I'm on Firmware Version v1.8 and hardware version HS72_V1.04 and I have the same bug that resets everything every time power is cycled.
 
M

ms264556

Well-Known Member
Sep 13, 2021
419
331
63
New Zealand
ms264556.net
LittleMike said:
I have the same bug that resets everything every time power is cycled.
Click to expand...
Did you go to Tools > Save > Save after you'd applied the changes you wanted? These work like most enterprise switches, where your changes aren't committed permanently unless you save them.

LittleMike said:
Will the 1.9 firmware posted in this thread work for that as well, or are the boards different? In the management UI, it tells me I'm on Firmware Version v1.8 and hardware version HS72_V1.04.
Click to expand...
I think it's reasonably likely the appropriate Hasivo firmware will work. My Hasivo and PoePlus 4+1+1 POE switches both have the same hardware version, HS72_V1.04, and the PoePlus switch was happy to take the Hasivo firmware at 微站.
 
O

OnnoO

New Member
Oct 12, 2023
15
4
3
I don't see these packet drops at 700 Mbit/s. At 2.5Gbit/s I only see <5 retransmitted packets.
My setup:
Win11(Realtek PCIe 2.5) <--2.5g-->Realtek based 2.5 switch<--2.5g-->Realtek based 2.5g switch<--10g DAC-->Mikrotik CRS309<--10g DAC-->Linux (Mellanox ConnectX-3).

The Realtek switches run FW 1.9.
 
  • Like
Reactions: zipityzi
L

LittleMike

New Member
May 7, 2024
2
0
1
ms264556 said:
Did you go to Tools > Save > Save after you'd applied the changes you wanted? These work like most enterprise switches, where your changes aren't committed permanently unless you save them.


I think it's reasonably likely the appropriate Hasivo firmware will work. My Hasivo and PoePlus 4+1+1 POE switches both have the same hardware version, HS72_V1.04, and the PoePlus switch was happy to take the Hasivo firmware at 微站.
Click to expand...
I did notice that after the fact but I still had issues that may or may not have been related (I couldn't get back to the web admin no matter what IP I tried using).
 
Z

zipityzi

New Member
Feb 8, 2024
7
1
3
OnnoO said:
I don't see these packet drops at 700 Mbit/s. At 2.5Gbit/s I only see <5 retransmitted packets.
My setup:
Win11(Realtek PCIe 2.5) <--2.5g-->Realtek based 2.5 switch<--2.5g-->Realtek based 2.5g switch<--10g DAC-->Mikrotik CRS309<--10g DAC-->Linux (Mellanox ConnectX-3).

The Realtek switches run FW 1.9.
Click to expand...
That's fantastic and that's what I would expect. Thank you so much for sharing your experience.

//

I ran more tests today, as I also have a Hasivo 8x2.5GbE + 1x10GbE switch (S1100WP-8GT-1XGT-SE), POE, managed plus ran a wider variety of tests: regular browsing, iperf3 again (same settings), and TamoSoft's Throughput Test (1min test manually timed-though it's percents anyways; UDP & TCP-though UDP is irrelevant here).

Now, TamoSoft's test is not apples-to-apples as it runs 100% all the time: 1 Gbe on 1 Gbe switches, 2.5 Gbe on 2.5 Gbe switches. But congestion shouldn't be a confounding factor with just two clients on 8-port switches.

I must be unlucky as 1) all tests on my two Hasivo switches showed much higher retransmits and 2) the old reliable TP-Link 1 GbE had virtually none (including 1 test with exactly 0 retransmits). Here are the results with the Hasivo V1.9 firmware reset to defaults; some re-tests to check my sanity:

1716235244938.png

The "regular browsing" result is the significant jump in retransmits over the weekend: ~34k to ~257k; that was one Windows client on the Hasivo 8+1 switch.

//

I've tried a few changes, without even any improvement: dumb mode, loop detection / prevention, MTU, different cables, different adapters, etc.

Now, the root cause may not be Hasivo: maybe my 2.5 GbE clients don't play well with Hasivo's firmware or Hasivo's hardware. I've had a chat open with Hasivo for a few days, but no replies except for "wait" about 18 hours ago. I have a TrendNET 2.5 GbE switch on the way and I'll re-run my tests there.

//

macOS server: macOS 17.5, UGreen 2.5 GbE type-C adapter ( RTL8156BG), iperf3 3.17.1
Windows client: Windows 11 Pro 23H2 22631.2593, ASUS ROG STRIX Z690-I, BIOS 2602, I225-V with driver 2.1.3.15, iperf3 3.17.1
Cables: all Monoprice CAT6a thin cables

I would test more clients / servers, but unfortunately are the only two laptops / desktops. I will see if I can borrow a device.

EDIT: can confirm, the Hasivo 8+1 also does not show any "BadPkts"

 
Last edited:
  • Like
Reactions: tamuin
K

keyxmakerx

New Member
May 24, 2024
1
0
1
Hellos, having an issue with my setup.
OpnSense > mokerlink 8 2.5Gb + 1 10GEth switch > sodola 8 2.5Gb + 1 10GbSFP

If I connect only the Mokerlink all is good, but even with STP on or off (already verified timing) I'm getting the weirdest issue where I can connect to statically assigned IPs (I.E. the switches) but nothing else will connect. I can't ping anything even the gateway. It's like it loses its mind once I connect the sodola switch.

I've tried to use only the sodola and it works fine, I've also tried another router (VyOS) and same thing, so I don't believe it's a router issue.

Both switches run v1.7 firmware and Ik the sodola has an upgrade and I'll try it tomorrow but wanted to see if anyone else has seen this issue or has any ideas? Honestly I've been a network engineer for some time but this one has left me completely flummoxed.

I've also verified that all vlans seem to be fine, mac tables on both switches show correct macs and vlans.

5 hours into this and I'm literally back to square one...
 
E

error404

New Member
May 27, 2024
5
1
3
Not sure if there's another thread about the 5/6-port, but after some hacking I was able to successfully flash the unmanaged SWTG115AS-V2.0 (5x2.5G) board - mine is SODOLA brand - to the managed version. I guess the SFP+ cage would work too if it were fitted, but I don't need it and it's a bit of tricky soldering, so I didn't try it. All of this very likely applies to the SWTG118AS-V2.0 unmanaged boards as well, the firmware is nearly identical, though maybe slightly different patch locations.

Unfortunately I don't think this is going to be possible without hardware hacking, as at least on my PCB only 4mbit of flash was fitted - the managed image needs a minimum of 16mbit and the OEM managed boards seem to have 32mbit fitted. So I didn't spend too much effort trying to reverse engineer the unmanaged firmware.

You will need to acquire an appropriate flash chip (I used W25Q16JLSS but probably any 25Q16 or 25Q32 in SOIC8 would work - I had 16mbit on hand, but 32mbit is probably a better choice to match the OEM hardware), < $1, and have a means to program it (I used a TL866, but CH341A 'bios' programmers should do the job for cheap), then swap it with the chip on the PCB (U8).

There are two checks in the firmware that need to be bypassed to make this work. First is a check of the unique ID programmed in the flash itself - this is meant to be unique _per chip_, but it's used as an 'authentication' scheme here. It's not possible to change this in widely available flash chips, so the only way around it is to patch the check. The second is the firmware's embedded checksum, which the algorithm hasn't been found yet afaik so must be bypassed.

In the v1.9 bare images (from up-n-atom's github repo - ie. not the firmware update files), patch 0xdd406 and 0x651c from 0x60 to 0x80. You might want to also patch the MAC address at 0x1fc000, I used the vendor's base 1c:2a:a3 with a random suffix for mine. Or use the attached image (but has MAC aa:bb:cc:dd:ee:ff).

Thanks to this github thread from libc0607 who did the hard work, I just interpreted the thread to figure out exactly what needed to be patched. Their switch hardware seemed to get stuck in a reset loop after similar patching, but apparently my board doesn't have this problem as it works fine.

If you do attempt this, note that using the internal updater will probably brick your unit until you remove the flash and reflash your patched image, unless you patch the new binary similar to above (but presumably at different addresses).
 

Attachments

Last edited:
  • Like
Reactions: blunden
E

error404

New Member
May 27, 2024
5
1
3
up-n-atom said:
github.com

SWTG118AS/tools/calcsum.py at main · up-n-atom/SWTG118AS

SWTG###AS RE. Contribute to up-n-atom/SWTG118AS development by creating an account on GitHub.
github.com github.com
Click to expand...
As far as I can tell, this calculates the checksum of the update package which has a simple structure, not the header of the firmware itself as burned to the flash ROM. I tried some 'obvious' checksums and variants on your code but couldn't get a match - but I didn't search that hard. There's also speculation on the GH thread that it might include some bytes from the OTP of the flash which would make it difficult to RE. Maybe you understand what's necessary but I couldn't easily figure it out. If you want to have a go, in the raw image the header is found at 0x1d000 (can be verified from the values printed on the serial console), and seems to be the same basic header, at least the header checksum works and the values match what the SPI viewer says.
 
Z

zipityzi

New Member
Feb 8, 2024
7
1
3
zipityzi said:
View attachment 36784
Click to expand...
The new TrendNET switch (model TPE-TG350) arrived, but only just had time to test. Thankfully, it's soon enough where I can still run identical tests: same cables, same adapters, same systems, same OS versions, same tests, same methodology,

TrendNET TPE-TG350 pros vs Hasivo:
  • Lifetime US warranty
  • Far more reliable / virtually no TCP retransmissions
  • Comes with little rubber feet
  • Slightly beefer power supply (55V * 1.3A, but could be due to higher power consumption); usable POE power is the similar at 55W
  • Power adapter has some US energy efficiency markings (but still no UL, ETL, nor TUV; unsure on the other labs' marks)
TrendNET TPE-TG350 cons vs Hasivo:
  • Only POE+, not POE++
  • No 10 GbE ports
  • No management interface
  • Runs noticeably warmer (warm to my hand, but not hot: have not attached its rubber feet)
For TCP retransmissions, the TrendNET is vastly improved over both my now-former Hasivo switches. TCP retransmissions have decreased by well over 50x (5,300%), so I'll switch to TrendNET for this round of upgrades. It's pricier & fewer features, but for me, significantly fewer TCP retransmissions trumps the rest.

What I'd call the toughest test (2.5 Gbps TCP iperf3) showed exactly 0.00% retransmissions, which is a sight for sore eyes.



In the meantime, I've successfully returned the two Hasivo Switches and AliExpress authorised a full 100% refund; the Hasivo folk are honest. But, Hasivo never did reply to my technical support questions and unfortunately, I won't be able to test the 1.9.1 (though it doesn't mention any TCP / reliability / perf fixes).

As noted above, I may have just gotten 2x bad Hasivo units or my hardware config may not be as compatible with Hasivo's HW / FW. I'll be here if anyone has questions; otherwise, the best of luck, ladies and gentlemen, with your new switches while I humbly bow out of this helpful thread.
 
up-n-atom

up-n-atom

Neko
May 30, 2019
31
50
18
Canada
www.eleventwentytwo.com
error404 said:
As far as I can tell, this calculates the checksum of the update package which has a simple structure, not the header of the firmware itself as burned to the flash ROM. I tried some 'obvious' checksums and variants on your code but couldn't get a match - but I didn't search that hard. There's also speculation on the GH thread that it might include some bytes from the OTP of the flash which would make it difficult to RE. Maybe you understand what's necessary but I couldn't easily figure it out. If you want to have a go, in the raw image the header is found at 0x1d000 (can be verified from the values printed on the serial console), and seems to be the same basic header, at least the header checksum works and the values match what the SPI viewer says.
Click to expand...
The offsets would need to be changed in the code if used on a flash dump based on GitHub - up-n-atom/SWTG118AS: SWTG###AS RE I could possibly add it in the future.

I do see the jump you've modified at 0xdd406 in a flash dump is part of the payload and also included in the updates hence the payload sum failure. Going forward you can just modify the update bin at 0xC4418 or by searching for the 59494F4754fff00 string and working your way back to the jump. Finally, run the modified update through the calcsum script.

This weekend I will look at this and try to sort it all out.

EDIT: can confirm that the mod to the 1.9.1 firmware update @ 0xC4418 and running python3 calcsum.py -u <firmware> passes. On the SWTG118AS-v1.0 PCB it will end up in a reset button boot loop.

Code: 
==========Loader start===========
Press any key to start the normal procedure.
To run SPI flash viewer, press [v]
To enforce the download of the runtime kernel, press [ESC] .....
  cmd -1
    Check Runtime Image.....
    Chksum Correct!
    RunTime Kernel Starting....
Ver8372N=2
Ver8373N=2
LINE 1462, RL6818C_pwr_on_patch_phy_v007 , patch 0xf finished!
LINE 1462, RL6818C_pwr_on_patch_phy_v007 , patch 0xf0 finished!



===========================Config Area pre-check Starts.=====================.
Pre-Check the config size structure is equal or not.
(sizeof(configCache)) a42.
(FLSH_ADDR_END-FLSH_CONFIG_ADDR_START) a42.
(FLSH_CONFIG_ADDR_START) 1fe000.
(FLSH_ADDR_END) 1fea42.
It seems no risk!..................
==============================Config Area pre-check ends.===================.



SalFlshCopyFlshToCache()
sal_sys_config_restore()
Restore dhcp state is: 0

Restore ip is: 192.168.2.1

...OK
sal_mirror_config_restore()...OK
sal_qos_config_restore()...OK
sal_vlan_config_restore()...OK
sal_rate_config_restore()...OK
sal_trunk_config_restore()...OK
sal_l2_config_restore()...OK
sal_loop_config_restore()...OK
sal_eee_config_restore()...OK
sal_stp_config_restore()...OK
sal_igmp_config_restore()...OK
sal_port_config_restore()...OK



#############According to the flash setting to set the WEB/DUMB mode

#############Read the web/dumb mode.....!!!###

#############web_dumb_cfg.vld_flag=-1, web_dumb_cfg.mode=-1
#############Begin to set the web mode



Reset button push 1 second.

################################################################

############Login Menu ############
### Please input uboot password below: ###

Reset button push 2 second.

Reset Factory Default.
The "reset button" i/o is tied between the RTL8373 and RTL8224 (screenshots) and needs to be pulled high to fix the reset loop. I'll leave it up to the diyers to decide where and how to do it.
 

Attachments

Last edited:
  • Like
Reactions: Stanchik and blunden
pigr8

pigr8

Member
Jul 13, 2017
95
96
18
  • Like
Reactions: bleili
D

der2of6

New Member
Mar 17, 2024
2
1
3
tahirsenpai said:
Hi all, I think the v1.9.1 firmware for the HORACO switch is already out (model ZX-SWTGW218AS)
I just ordered this switch and this was part of the automated messages with the seller.
This is for the 8-port model, not sure if it will work with the 4-port.

Here is the direct link as well: https://cdn.shoplazza.com/8b589a2df28a47bb7c255e3c6a56764b.zip
Click to expand...
Worked wich the HORACO Version of the switch.
After flashing, the switch was facotry default again.

So i you have VLANs etc configured be aware of this behavior.
 
  • Like
Reactions: bleili
D

der2of6

New Member
Mar 17, 2024
2
1
3
I not quite sure.
switchfan said:
Sure that you have saved your config when vou were on the old firmware?
If not, a simple reboot/powercycle would have had he same effect...
Click to expand...
I belive i saved the config after the last changes.
Maybe someone can confirm that a saved config is still there after firmware update.
 
E

error404

New Member
May 27, 2024
5
1
3
up-n-atom said:
EDIT: can confirm that the mod to the 1.9.1 firmware update @ 0xC4418 and running python3 calcsum.py -u <firmware> passes. On the SWTG118AS-v1.0 PCB it will end up in a reset button boot loop.
Click to expand...
Interesting. I suppose the built-in updater is updating the checksum in the header at flash location 0x1d000 when the image is installed. Of course I wasn't able to do it that way when flashing an unmanaged unit, at least from the dumps in your repo. These dumps don't boot without also patching out the loader check.
 
pigr8

pigr8

Member
Jul 13, 2017
95
96
18
der2of6 said:
I not quite sure.


I belive i saved the config after the last changes.
Maybe someone can confirm that a saved config is still there after firmware update.
Click to expand...
yes i can confirm, i updated my two without loosing any config, just flash and reboot.
 
  • Like
Reactions: der2of6
You must log in or register to reply here.
Top Bottom