Hasivo switches

mensi · March 15, 2026, 3:02pm

I've spent some time recently looking for a way to create a factory image for the S1300WP-8GT-2S+ (and probably any device using that imi binary as the main process). There's basically two ways the firmware takes "upgrades":

switch.tar.gz: As far as I can see this mostly just replaces the switch.tar.gz on the RUNTIME2 partition. It looks like there might also be a codepath to write something to /dev/mtd10 as a "kernel upgrade"
patch.tar.gz: Available through the CLI, allows arbitrary code execution as root.

But something is really weird with MTD: When I use the patch.tar.gz feature to run stuff as root, I for example get this:

# mtdinfo /dev/mtd10
mtd2
Name:                           SYSINFO
Type:                           nor
Eraseblock size:                4096 bytes, 4.0 KiB
Amount of eraseblocks:          16 (65536 bytes, 64.0 KiB)
Minimum input/output unit size: 1 byte
Bad blocks are allowed:         true
Device is writable:             true

And poking around more, it looks like the realtek kernel might have hacked minor >> 1 mtdchar.c does in upstream for RW/RO to minor >> 2 or something.

But it only reliably works up to mtd13 mapping to mtd3, afterwards it's just:

libmtd: error!: cannot open "/dev/mtd14"
        error 19 (No such device)
mtdinfo: error!: "/dev/mtd14" does not correspond to any existing MTD device

But it gets even weirder. The filesystem with vendor binaries is on mtdblock6:

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock6           22528     17172      5356  76% /mnt

But trying anything with that (or even mtdblock5) gives a No such device or address error. The device node uses major 31 and minor 6. But 31 doesn't even show up in /proc/devices...

So I'm starting to doubt the vendor firmware upgrade would even work - sadly I don't have one to try.

Has anyone ever seen something similar? The kernel sources from the dms-1250 GPL dump look normal and use minor >> 1, so no idea if this particular OEM got extra creative or if I'm just missing something.

bevanweiss · March 17, 2026, 7:42am

There is support for this switch (s1100wp-8gt-se) in OpenWrt (it went in Dec 2025).
PoE is not currently working (as of Mar 2026), but development is underway for it.

jhohertz · March 17, 2026, 2:37pm

Thanks for mentioning this, I haven't had time yet to do a deeper dive, but this hasivo is absolutely using the imi binary.

mensi · March 17, 2026, 4:37pm

You are looking at a S600W flavor, right? I just realized I have a S600WP-4GT-1SX-1XGT-SE lying around I can take a look at too.

It looks though that this might only have a 2MiB flash chip and no external serial, so it might be quite different.

janh · March 17, 2026, 6:42pm

That looks like a device based on RTL8372, so it won't run OpenWrt as the CPU is just a 8051 (but there is another project for alternative firmware)

markc1984 · April 8, 2026, 7:11am

Hey all,
I'm new here. I've been working to try and get a Hasivo F1100W-4SX-4XGT switch working with OpenWRT. This is the L3 version that is sold on AliExpress. I've also got the PoE version of the same switch, but for now I'm just trying to get the non-PoE version working.

This switch has 4x SFP+ ports and 4 x 10gbe copper ports. It has no fan, so does tend to get extremely hot under heavy use.

My objective was to get at least the copper ports working before moving on to the SFP+ ports, which also do not work, even though they appear within OpenWRT as an interface.

I have managed to boot in to OpenWRT using TFTP via u-boot and by editing a dts file for this switch, I've managed to get all 4 x copper lan ports to appear and detect a link when plugged in, albeit with the LED link lights all wrong.

Unfortunately, this is where I've hit a wall. Nothing is passing any traffic at Layer 2 on any of the ports, ARP basically does not work, and I've no idea why. It could be something stupid that I'm missing but for now I've given up as I've been messing with this for well over a week with zero progress. Unfortunately my knowledge of this system is limited, which is not helping.

I've uploaded a firmware dump that I made of the switch to github and have also included a dts file that I have been messing around with, it's probably wrong, so please go easy.

Any help would be most appreciated'

jonasj · April 8, 2026, 8:19am

Some experts here might help to get some information out of the firmware dump, never had Hasivo switch in my hands so I cannot help there. But general RTL930x.

Which PHYs are on those copper ports? I guess it's something like RTL8261. Then this might not be a SerDes issue but rather PHY issue which is in the process of being solved right now (see https://github.com/openwrt/openwrt/pull/22563 and https://github.com/openwrt/openwrt/issues/22811).

What doesn't work exactly with the SFP+ ports? Does a link get detected and just no traffic, or no link detected?

Please provide a bootlog (dmesg) including when you insert an SFP module and connect the cable to it so it should get a link up. At that stage, please also provide a dump of the SerDes registers (cat /sys/kernel/debug/realtek_otto_serdes/serdes.X/registers), probably of all SerDes (2-9) so we have the full picture.

pktpls · April 13, 2026, 1:10pm

My S1100WP-8GT just arrived. It has newer version of U-Boot. Unfortunately, I couldn't get U-boot prompt with "ESC" key. I also tried "Ctrl-Z", "Space", none of them worked. Anyone knows the magic key? Here is the part of U-Boot log:

I have the same problem with a different new Hasivo switch: F1100WP-4SX-4XGT with firmware version 7.1.9 from Nov 14 2025.

The interrupt prompt isn’t printed, only the countdown timer. Keyboard inputs are ignored. Later in the actual firmware console, inputs work fine.

bevanweiss · April 13, 2026, 9:40pm

For the F1100WP-4SW-4XGT I believe the escape sequence is ctrl-c, z, h during the countdown sequence.
So you press ctrl+c, and then z, and then h in quick succession.

pktpls · April 14, 2026, 8:57am

For the F1100WP-4SW-4XGT I believe the escape sequence is ctrl-c, z, h during the countdown sequence.

Nice, that works, thanks a lot! That seems to be a relatively complete u-boot. Hasivo email support insists that u-boot is locked “for safety reasons”.

mensi · April 15, 2026, 12:09pm

Only just took a very brief look at this binary, but it looks similar to the one I was working on. I'll see if I can find some time to poke around and write something up.

Do you happen to have to boot output from the serial console?

OpenWrtAWESOME · April 15, 2026, 5:42pm

the s1300wp has something similar, I removed the boot command env variable and entered the boota command manually. By that the device stops in the bootloader automatically if I recall correctly. You guys could try that as well

mensi · April 15, 2026, 7:43pm

This is the hardware profile my script for the other device extracted for the F1100WP:

static hwp_swDescp_t rtl9303_4xge_4x8261be_swDescp = {

    .chip_id                    = 0x93036810,
    .swcore_supported           = TRUE,
    .swcore_access_method       = HWP_SW_ACC_MEM /* 0x1 */,
    .swcore_spi_chip_select     = HWP_NOT_USED /* 0xff */,
    .nic_supported              = TRUE,

    .port.descp = {
        { .mac_id =  0, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_SERDES /* 0x8 */, .sds_idx = 0, .phy_idx = HWP_NONE /* 0xff */, .smi = HWP_NONE /* 0xff */, .phy_addr = HWP_NONE /* 0xff */, .led_c = 0, .led_f = 0, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id =  8, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_SERDES /* 0x8 */, .sds_idx = 1, .phy_idx = HWP_NONE /* 0xff */, .smi = HWP_NONE /* 0xff */, .phy_addr = HWP_NONE /* 0xff */, .led_c = 0, .led_f = 0, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id = 16, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_SERDES /* 0x8 */, .sds_idx = 2, .phy_idx = HWP_NONE /* 0xff */, .smi = HWP_NONE /* 0xff */, .phy_addr = HWP_NONE /* 0xff */, .led_c = 0, .led_f = 0, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id = 20, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_SERDES /* 0x8 */, .sds_idx = 3, .phy_idx = HWP_NONE /* 0xff */, .smi = HWP_NONE /* 0xff */, .phy_addr = HWP_NONE /* 0xff */, .led_c = 0, .led_f = 0, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id = 24, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_COPPER /* 0x1 */, .sds_idx = 4, .phy_idx = 0, .smi = 2, .phy_addr = 0, .led_c = 0, .led_f = HWP_NONE /* 0xff */, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id = 25, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_COPPER /* 0x1 */, .sds_idx = 5, .phy_idx = 1, .smi = 3, .phy_addr = 16, .led_c = 0, .led_f = HWP_NONE /* 0xff */, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id = 26, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_COPPER /* 0x1 */, .sds_idx = 6, .phy_idx = 2, .smi = 0, .phy_addr = 16, .led_c = 0, .led_f = HWP_NONE /* 0xff */, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id = 27, .attr = HWP_ETH /* 0x1 */, .eth = HWP_XGE /* 0x10 */, .medi = HWP_COPPER /* 0x1 */, .sds_idx = 7, .phy_idx = 3, .smi = 1, .phy_addr = 0, .led_c = 0, .led_f = HWP_NONE /* 0xff */, .led_layout = SINGLE_SET /* 0x0 */, .phy_mdi_pin_swap = 0, },
        { .mac_id = 28, .attr = HWP_CPU /* 0x8 */, .eth = HWP_NONE /* 0xff */, .medi = HWP_NONE /* 0xff */, .sds_idx = HWP_NONE /* 0xff */, .phy_idx = HWP_NONE /* 0xff */, .smi = HWP_NONE /* 0xff */, .phy_addr = HWP_NONE /* 0xff */, .led_c = HWP_NONE /* 0xff */, .led_f = HWP_NONE /* 0xff */, .led_layout = HWP_NONE /* 0xff */, .phy_mdi_pin_swap = 0, },
        { .mac_id = HWP_END },
    },  /* port.descp */

    .led.descp = {
        .led_active = LED_ACTIVE_LOW /* 0x1 */,
        .led_if_sel = LED_IF_SEL_SERIAL /* 0x1 */,
        .led_definition_set[0].led[0] = 0xBA0,
        .led_definition_set[0].led[1] = 0xA01,
        .led_definition_set[0].led[2] = HWP_LED_END /* 0xffffffff */,
    },  /* led.descp */

    .serdes.descp = {
        [0] = { .sds_id = 2, .mode = RTK_MII_10GR /* 0x2 */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [1] = { .sds_id = 3, .mode = RTK_MII_10GR /* 0x2 */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [2] = { .sds_id = 4, .mode = RTK_MII_10GR /* 0x2 */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [3] = { .sds_id = 5, .mode = RTK_MII_10GR /* 0x2 */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [4] = { .sds_id = 6, .mode = RTK_MII_USXGMII_10GSXGMII /* 0x1c */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [5] = { .sds_id = 7, .mode = RTK_MII_USXGMII_10GSXGMII /* 0x1c */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [6] = { .sds_id = 8, .mode = RTK_MII_USXGMII_10GSXGMII /* 0x1c */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [7] = { .sds_id = 9, .mode = RTK_MII_USXGMII_10GSXGMII /* 0x1c */, .rx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */, .tx_polarity = SERDES_POLARITY_NORMAL /* 0x0 */ },
        [8] = { .sds_id = HWP_END },
    },  /* serdes.descp */

    .phy.descp = {
        [0] = { .chip = RTK_PHYTYPE_RTL8224 /* 0x20 */, .mac_id = 24, .phy_max = 1 },
        [1] = { .chip = RTK_PHYTYPE_RTL8224 /* 0x20 */, .mac_id = 25, .phy_max = 1 },
        [2] = { .chip = RTK_PHYTYPE_RTL8224 /* 0x20 */, .mac_id = 26, .phy_max = 1 },
        [3] = { .chip = RTK_PHYTYPE_RTL8224 /* 0x20 */, .mac_id = 27, .phy_max = 1 },
        [4] = { .chip = HWP_END },
    },  /* .phy.descp */

};

static hwp_hwProfile_t rtl9303_4xge_4x8261be = {

    .identifier.name        = "RTL9303_4XGE_4X8261BE",
    .identifier.id          = HWP_RTL9303_8x2_5G /* 0x8de83a */,

    .soc.swDescp_index      = 0,
    .soc.slaveInterruptPin  = HWP_NONE /* 0xff */,

    .sw_count               = 1,
    .swDescp = {
        [0]                 = &rtl9303_4xge_4x8261be_swDescp,
    }

};

The phy stuff seems wrong, as it sounds more plausible the 4 copper ports are just 4 RTL8261.

If you see the same problem of the switch resetting after sitting at the uboot prompt for about 2-3 minutes you likely also have this hasivo watchdog chip thing.

pktpls · April 16, 2026, 1:44am

Thanks a lot, with this info I was able to mess with my DTS to get working 2.5G on the first RJ45 port! Code here: https://github.com/pktpls/openwrt/commits/f1100w/ based on this PR which adds RTL8261BE https://github.com/openwrt/openwrt/pull/22563. The 2nd/3rd/4th ports dont work yet but at least detect the link. The problem might be that all ports still have the same MAC address at the moment.

The first SFP+ port also detects a 10G link if I boot with a transceiver inserted.

I have the variant with PoE and console port.

I also noticed they messed up the hardware profile in my device with firmware 7.1.9 - I had to do setenv boardmodel 'RTL9303_5x8261BE_2XGE_ZHIHUI' to get tftpboot to work, lucky the 5th port of that model has the same phy as the 5th port on my model.

(I’m way over my head here and just poking stuff).

bevanweiss · April 16, 2026, 2:12am

It's definitely not going to be the MAC address. For a switch, generally all ports should report the same MAC (unless VLAN'd or different actual interfaces with an IP, or other L3 stack, above them), it should be based on what the vendor provided.

It may be an issue with the SERDES polarity.
I think @jonasj did some work in this area, although the hardware dump from @mensi seems to suggest no polarity oddness here...

pktpls · April 16, 2026, 7:47pm

I now have traffic on both sfp1 and lan1 on this F1100WP-4SW-4XGT Only 160 Mbps on sfp1 though I’ll push my branch and will also collect some more logs

Edit: actually traffic on all sfp1-sfp4, but only if they carry a transceiver during boot.

markc1984 · April 16, 2026, 8:34pm

Thanks for the reply. Yes I believe they are individual 8261BE PHYs. Haven't been able to get any traffic on any of the ports, including copper.

It's probably something I'm doing wrong, unfortunately due to work commitments I haven't had chance to look at this further.

markc1984 · April 16, 2026, 8:37pm

Here you go, this is from the stock firmware. I had to revert to it from OpenWRT as I needed to put the switch in to use:


U-Boot 2011.12.(3.6.8.55120) (Jul 11 2024 - 14:44:22)

Board: RTL9300 CPU:800MHz LX:175MHz DDR:600MHz
DRAM:  512 MB
SPI-F: MXIC/C22019/MMIO32-4/ModeC 1x32 MB (plr_flash_info @ 83f9a094)
Loading 65536B env. variables from offset 0xe0000
Net:   Net Initialization Skipped
No ethernet found.                                                                                                                                                                                                                                                                                                         0
## Booting image from partition ... 0
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   RTK_SDK
   Created:      2025-08-27  15:51:29 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    6253198 Bytes = 6 MB
   Load Address: 80000000
   Entry Point:  80316930
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

console [ttyS0] enabled
bootconsole [early0] disabled
Calibrating delay loop... 531.66 BogoMIPS (lpj=2658304)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 2048 (order: 3, 40960 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 12288 bytes)
UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
futex hash table entries: 256 (order: 0, 7168 bytes)
ntfs: driver 2.1.31 [Flags: R/W].
jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
msgmni has been set to 489
random: modprobe urandom read with 1 bits of entropy available
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 47, base_baud = 10764700) is a 16550A
SCSI Media Changer driver v0.25
RTK_SPI_FLASH_MIO driver is bypassed
RTK_NORSFG3 driver is used
=================================================================
init_luna_nor_spi_map: flash map at 0xb4000000
SPI NOR driver probe...
MXIC/C22019/MMIO32-4/ModeC add SPI NOR partition
MTD partitions obtained from built-in array
Creating 7 MTD partitions on "rtk_norsf_g3":
0x000000000000-0x0000000e0000 : "LOADER"
0x0000000e0000-0x0000000f0000 : "BDINFO"
0x0000000f0000-0x000000100000 : "SYSINFO"
0x000000100000-0x000000200000 : "JFFS2 CFG"
0x000000200000-0x000000300000 : "JFFS2 LOG"
0x000000300000-0x000000a00000 : "RUNTIME"
0x000000a00000-0x000002000000 : "RUNTIME2"
=================================================================
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
rtk_gen1_hcd_cs_init: rtk_gen1_hcd_cs_init()!
rtk_gen1_hcd_cs_init: register rtk_gen1_ehci ok!
usb_phy_configure_process: usb_phy_configure_process()!
rtk_gen1-ehci rtk_gen1-ehci: Realtek On-Chip EHCI Host Controller
rtk_gen1-ehci rtk_gen1-ehci: new USB bus registered, assigned bus number 1
rtk_gen1-ehci rtk_gen1-ehci: irq 28, io mem 0x18021000
rtk_gen1-ehci rtk_gen1-ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-platform: OHCI generic platform driver
usbcore: registered new interface driver uas
usbcore: registered new interface driver usb-storage
TCP: cubic registered
Freeing unused kernel memory: 4972K (80425000 - 80900000)
init started:  BusyBox v1.00 (2025.08.27-07:50+0000) multi-call binary
Starting pid 26, console : '/etc/rc'
RTCORE LKM Insert...
    TC util init (isr)

Starting pid 62, console /dev/ttyS0: '/bin/sh'
Decompressing /mnt/switch.tar.gz ...
switch
switch/kernel
switch/kernel/kernel_rtl9300_7v4
switch/kernel/kernel_9301_version.txt
switch/kernel/9300-sdk3.6.8
switch/other
switch/other/certificate.pem.crt
switch/other/private.pem.key
switch/other/do_next
switch/other/AmazonRootCA1.pem
switch/module
switch/module/system_gpio.ko
switch/module/inos_ifksdk.ko
switch/module/i2c-ddm.ko
switch/module/reset.ko
switch/module/i2c-poe.ko
switch/module/i2c-rtc.ko
switch/module/i2c-encyt.ko
switch/app
switch/app/ospf6d
switch/app/ripngd
switch/app/webfiles.bin
switch/app/lighttpd.tar
switch/app/mstpd
switch/app/snmpd
switch/app/ripd
switch/app/nsm
switch/app/lacpd
switch/app/ospfd
switch/app/bgpd
switch/app/openssh.tar.gz
switch/app/imi
switch/app/pimd
openssh
openssh/sbin
openssh/sbin/sshd
openssh/libexec
openssh/libexec/sshd-session
openssh/ssh
openssh/ssh/ssh_host_rsa_key.pub
openssh/ssh/ssh_host_ed25519_key4
openssh/ssh/ssh_host_ed25519_key1
openssh/ssh/ssh_host_ecdsa_key4
openssh/ssh/ssh_host_rsa_key4
openssh/ssh/ssh_host_rsa_key3.pub
openssh/ssh/ssh_host_ed25519_key2.pub
openssh/ssh/ssh_host_ecdsa_key2
openssh/ssh/ssh_host_ed25519_key2
openssh/ssh/ssh_host_rsa_key2
openssh/ssh/ssh_host_ecdsa_key1.pub
openssh/ssh/ssh_host_rsa_key2.pub
openssh/ssh/ssh_host_rsa_key1.pub
openssh/ssh/ssh_host_ed25519_key3
openssh/ssh/ssh_host_rsa_key3
openssh/ssh/ssh_host_ecdsa_key4.pub
openssh/ssh/ssh_host_ecdsa_key3.pub
openssh/ssh/ssh_host_ecdsa_key2.pub
openssh/ssh/ssh_host_rsa_key1
openssh/ssh/ssh_host_rsa_key4.pub
openssh/ssh/ssh_host_ecdsa_key3
openssh/ssh/ssh_host_ed25519_key3.pub
openssh/ssh/ssh_host_ecdsa_key1
openssh/ssh/ssh_host_ed25519_key.pub
openssh/ssh/ssh_config
openssh/ssh/ssh_host_ed25519_key4.pub
openssh/ssh/ssh_host_ecdsa_key.pub
openssh/ssh/ssh_host_ecdsa_key
openssh/ssh/ssh_host_ed25519_key1.pub
openssh/ssh/ssh_host_rsa_key
openssh/ssh/sshd_config
openssh/ssh/ssh_host_ed25519_key
openssh/lib
openssh/lib/libz.so.1
openssh/lib/libz.so.1.3.1
openssh/passwd
openssh/bin
openssh/bin/ssh
Start to run IFKSDK ...
Start to load PoE module ...
Start to load encyt module ...
Start to load GPIO module ...
Start to load reset module ...
Start to load RTC module ...
Start to run MSTP ...
Start to run LACP ...
Start to run RIP ...
Start to run RIPNG ...
Start to run OSPF ...
Start to run OSPF6 ...
Start to run BGP ...
Start to run PIM-SM ...
Layer 3 switch loading ...
Start to load configuration ...
SSH and Web can be used after about 30 seconds.


F1100W-4SX-4XGT 7.2.4
Creation date:Jan 23 2026 09:37:05



User Access Verification



Username:

pktpls · April 16, 2026, 9:45pm

Notable differences between F1100W-4SX-4XGT and F1100WP-4SX-4XGT: 512 vs 256 MB RAM, and RUNTIME/RUNTIME2 partition sizes. Possibly more things are different? Try out my branch though: https://github.com/pktpls/openwrt/commits/f1100w/

In my branch I named the device F1100W although I’m working on a WP here - I should change that. RAM and partitioning differences warrant a separate device definition I think.

On my WP device I now have full speed traffic between all ports working, although the SFP modules still need to be present at boot time for the port to work. Hotplugging of SFP modules and RJ45 cables works on all ports. Sysupgrade also works, so I’m now doing my regular internet traffic over this device, let’s see how it goes.

I shall write a proper progress report another day :))

mensi · April 17, 2026, 5:59pm

Did you just overwrite the relevant part on the SPI flash or do you have working code to generate a vendor image?