Meraki MS425 hardware overview

The Meraki MS425 series switches (codename “Hungry Hungry Hippo”) offer 16 or 32 ports of 10Gbit SFP+ Ethernet, two 40Gbit QSFP+ stacking ports, and a Gigabit Ethernet management port.

Meraki MS425-16 Switch with cover removed

Meraki MS425-16 internal view

The MS425 was discontinued in June 2024, and is too old to support secure boot.

Here is a quick summary of the MS425 specs:

  • Broadcom BCM56854 “Trident II” ASIC
  • Broadcom BCM5862x “StrataGX” management CPU
  • 16MB of SPI flash (MX25L12805D)
  • 2GB DDR3 RAM (soldered)
  • 1024MB NAND flash (Micron MT29F8G08ABACA; PDF datasheet)
  • MA-PWR-250WAC (identical to PWR-C2-250WAC)

The UART header in the MS425 is CONN7 (silk screen: UART Console) and follows the standard Meraki UART pinout (1: 3.3V Vcc, 2: Tx, 3: Rx, 4: GND) at 115200 baud.

The MS425-16 uses the same PCB as the MS425-32, but missing 16 SFP+ cages and two PHYs. This is the same technique Meraki used for the MS420-24 model.


The stock Meraki boot process uses u-boot on SPI to load a “bootkernel” (also from SPI), which then initializes NAND and using kexec boots the main firmware. The firmware layout follows the standard Meraki practice of having A/B firmware images: bootkernel1, bootkernel2, part.safe, part.old.

The firmware layout on SPI is:

0x000000-0x100000 : "uboot"
0x100000-0x800000 : "bootkernel1"
0x800000-0xf00000 : "bootkernel2"

Unlike the MS350, the management plane is not an x86 CPU, but a Broadcom “StrataGX” ARMv7. The MS425 runs the same firmware release (switch-arm) as the MS210/MS225/MS250 series.

PCI devices present:

00:00.0 PCI bridge: Broadcom Inc. and subsidiaries Device 8025 (rev 12)
01:00.0 Ethernet controller: Broadcom Inc. and subsidiaries Device b854 (rev 03)

The Broadcom SDK series implements the packet engine in userspace, using the GPL-licensed linux_kernel_bde and linux_user_bde kernel modules to interface with the ASIC. In the Meraki firmware, the packet engine is a component of the userspace click daemon, which loads the bcm_click shared object during click router initialisation.


Similar to the MS420, the three 40mm system fans in the MS425 are controlled by an onsemi ADT7473 (PDF datasheet). The MS425 fans have a Meraki part number: MA-FAN-18K (P/N 680-29010) and contain the Delta FFB0412UHN-C (PDF datasheet). These are identical to the Cisco FAN-T1, which can be purchased for considerably less than the Meraki branded part.

The MS425 accepts two hot-swap power supplies (model MA-PWR-250WAC, P/N 640-20010), which in my units are Delta model DPS-250AB-86 with 12V/20.83A output. Note that the MA-PWR-250WAC is physically and electrically compatible with PWR-C2-250WAC. Higher wattage power supplies like the PWR-C2-640WAC and PWR-C2-1025WAC will also power the MS425.

Idle power consumption:
MS425-16: 72W
MS425-32: 78W

Interesting to note is that the Trident II ASIC found in the MS425 supports VxLAN, however this feature is absent from Meraki’s datasheet and does not appear to be supported by their firmware. Apart from 40Gbit stacking ports, there is not much to be gained from the Trident II in the MS425 over the Trident+ in the MS420: idle power consumption is slightly lower, and it is still supported (see note below).

Meraki have chosen to EoL all of their Broadcom based switches. Being a Broadcom design, the MS425 was axed from the product portfolio on 2024-06-24. The MS425 will continue to receive limited software support from Meraki until Q3 2029. Big “we cancelled all our contracts with Broadcom and are now a Marvell/Catalyst shop” energy.


The GPL source code for the MS425 was requested from Meraki in December 2023, and at the time of writing Meraki has not provided any of the requested source code.

“[F]ulfilling your requests are an important priority for [Meraki]” so I am sure they will comply with their license obligations… Any day now… Just wait for it… It is almost as if they know that providing the GPL source code would enable people to re-use claimed/EOL products and are avoiding doing that. 🤔


Model Meraki Board Part number
MS425-16 Hungry Hungry Hippo 600-45010
MS425-32 Hungry Hungry Hippo 600-45015, 600-45020

Gigabyte MJ11-EC1 PCIe Bifurcation

The Gigabyte MJ11-EC1 motherboard is an ITX motherboard with an AMD EPYC 3151 (4C8T) onboard. These motherboards were being liquidated from the Gigabyte G431-MM0 GPU server in 2023, and could be purchased for around 60 Euros in the EU. The bare-bones G431-MM0 can still be purchased for around 170 Euros.

The MJ11-EC1 is very similar to the Gigabyte MJ11-EC0 with the main difference being the MJ11-EC0 has a PCIe x16 slot while the MJ11-EC1 has a SlimSAS (SFF-8654 8i) connector for use with the GPU riser in the G431-MM0.

You can purchase the SlimSAS cable (~18 Euros) and a PCIe riser (~15 Euros) from several AliExpress sellers. The added cost of the cable and PCIe riser does reduce the value proposition of the motherboard somewhat. Additionally, user testing showed that PCIe bifurcation was non-functional on the SlimSAS port, meaning only a single PCIe device could be recognized on the SlimSAS 8i port unless a PCIe switch was used.

However, I can demonstrate that bifurcation does work on the MJ11-EC1, and in fact it is possible to access all PCIe x16 lanes if you add the unpopulated U2_1 SFF-8654 connector. All the passive components for the SFF-8654 connector are already present on the motherboard, so only the physical connector needs to be added to unlock an additional 8 lanes of PCIe.

Two MJ11-EC1 motherboards, one with U2_1 unpopulated and one with a SlimSAS 8i connector soldered

However, PCIe Bifurcation does not work under every condition. The following scenarios do not work:

Cable Adapter Bifurcation working
SlimSAS 8i to dual 4i SlimSAS 4i to PCIe x4 No
SlimSAS 8i to 8i SlimSAS 8i to Dual NVMe No
Dual SlimSAS 8i to 8i PCIe x16 (JHHP1B) No

The first attempt was with a SlimSAS 8i to dual 4i cable. Unfortunately, bifurcation did not work with this cable, only one device was visible.

Only one device is recognized

The second attempt was with a SlimSAS 8i to dual NVMe adapter. Again, only the first NVMe device was visible, so I do not recommend purchasing this for use with the MJ11-EC1.

Only one device is recognized

I then tried this dual SlimSAS 8i to PCIe x16 adapter, which did not work at all. In my subsequent discussion with the vendor in the AliExpress dispute, it appears this adapter is only compatible with their PCIe x16 to SlimSAS riser. So despite using the SFF-8654 connector, it is not standards compliant with SlimSAS 8i and cannot be used with the MJ11-EC1. Do not purchase this.

This adapter does not work at all. Avoid purchasing the “2 Port SlimSAS 8i x2 to PCIe 4.0 x16 Slot Adapter Card SFF8654 Riser Card GEN4”


The following combinations are fully functional:

Cable Adapter BIOS configuration PCIe devices Bifurcation working
SlimSAS 8i to 8i PCIe x8 x8x8 2 Yes
SlimSAS 8i to 8i PCIe x8 with 4xNVMe riser, 2xNVMe x8x4x4 3 Yes
SlimSAS 8i to 8i PCIe x8 with 4xNVMe riser, 2xNVMe x4x4x4x4 4 Yes

The following SlimSAS 8i to PCIe x8 adapters were used during testing and worked as expected. The adapters were purchased with my own funds and I have no relationship to the brands or sellers.

CEACENT CNS41CX16W

The CEACENT CNS41CX16W places a decoupling capacitor (C21) in the path of the power connector. Cover this in glue/epoxy or it will get knocked off the board.

“SFF-8654 8i to PCIe 4.0 x16 External Graphics Card Adapter SFF-8654 8i Adapter Card” N-P548-A

The designer of this adapter does not seem to have considered the lack of clearance between the SFF-8654 and SATA power connector. I would call it “challenging” to plug in the SFF-8654 connector.

Most SFF-8654 to PCIe x8 adapters from China seem to have fundamentally flawed physical layouts, which is unfortunate given they are otherwise inexpensive and effective.

This NVMe adapter is great, my only wish is that they made a 1U compatible 2 NVMe version as inexpensive as the 4 NVMe model.

There are dual SlimSAS 8i to PCIe x16 adapters available, however they are cost prohibitive. Given the PCIe bifurcation options available in BIOS and the fact that there are 16 accessible PCIe lanes, I suspect a standards-compliant adapter (e.g. Ceacent CNS52CX16R) would work to expose all 16 lanes.


MJ11-EC1 with two PCIe x8 adapters; HP 544FLR-QSFP installed and BIOS configured for x8x8 bifurcation:

05:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]
06:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]
(...)
# lspci -s 05:00.0 -vvv
05:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]
        Subsystem: Hewlett-Packard Company InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544+FLR-QSFP Adapter
(...)
                LnkCap: Port #8, Speed 8GT/s, Width x8, ASPM L0s, Exit Latency L0s unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s, Width x8
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
# lspci -s 06:00.0 -vvv
06:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]
        Subsystem: Hewlett-Packard Company InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544+FLR-QSFP Adapter
(...)
                LnkCap: Port #8, Speed 8GT/s, Width x8, ASPM L0s, Exit Latency L0s unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s, Width x8
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

MJ11-EC1 with two PCIe x8 adapters, each with 4xNVMe adapters, NVMe 1 and 2 sockets populated; BIOS configured for x4x4x4x4 bifurcation:

05:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller 980 (DRAM-less)
06:00.0 Non-Volatile memory controller: KIOXIA Corporation NVMe SSD Controller BG4 (DRAM-less)
07:00.0 Non-Volatile memory controller: SK hynix 960GB TLC PCIe Gen3 x4 NVMe M.2 22110
08:00.0 Non-Volatile memory controller: Sandisk Corp WD PC SN810 / Black SN850 NVMe SSD (rev 01)
(...)
# lspci -s 05:00.0 -vvv
05:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller 980 (DRAM-less) (prog-if 02 [NVM Express])
        Subsystem: Samsung Electronics Co Ltd Device a801
(...)
                LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
                        ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s, Width x4
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
# lspci -s 06:00.0 -vvv
06:00.0 Non-Volatile memory controller: KIOXIA Corporation NVMe SSD Controller BG4 (DRAM-less) (prog-if 02 [NVM Express])
        Subsystem: KIOXIA Corporation NVMe SSD Controller BG4 (DRAM-less)
(...)
                LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L1 <32us
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s, Width x4
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
# lspci -s 07:00.0 -vvv
07:00.0 Non-Volatile memory controller: SK hynix 960GB TLC PCIe Gen3 x4 NVMe M.2 22110 (prog-if 02 [NVM Express])
        Subsystem: SK hynix Device 0000
(...)
                LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM not supported
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s, Width x4
                        TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
# lspci -s 08:00.0 -vvv
08:00.0 Non-Volatile memory controller: Sandisk Corp WD PC SN810 / Black SN850 NVMe SSD (rev 01) (prog-if 02 [NVM Express])
        Subsystem: Sandisk Corp WD PC SN810 / Black SN850 NVMe SSD
(...)
                LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <8us
                        ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s (downgraded), Width x4
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-


This was a fun modification but the economic case is dubious at best. With the SFF-8654 8i cables being roughly 18 Euros each, and SlimSAS 8i to PCIe x8 adapters ranging in price from 18-22 Euros (+shipping) the additional cost to fully utilise 16 PCIe lanes easily exceeds the entire cost of the motherboard.

The SFF-8654 connector (Amphenol U10-B074-200T) proved very hard to source from Western Distributors as they are discontinued, and are not available at a reasonable price on AliExpress. I ended up purchasing them on Taobao via a Chinese based forwarding service. The cost for QTY 20 was 523¥ on Taobao, plus forwarding agent fees, shipping to Europe, and VAT.

Soldering the connector is also a nightmare. The ground plane on the MJ11-EC1 is very effective at dissipating heat. I used a pre-heater, hot air station (set to 200C with high flow to avoid melting the plastic), leaded solder, sticky flux, and still required some touch up work with a very fine tip on the soldering iron to fix bad connections.

It should be noted that bifurcation of the populated U2_2 SFF-8654 port works. Anyone owning the MJ11-EC1 wishing to do that just needs to flash the MJ11-EC0 BIOS via the BMC to expose PCIe bifurcation settings in BIOS, and they should be able to install two PCIe x4 devices (subject to the limitations mentioned above regarding cables/risers).

Meraki MG21 hardware overview and secure boot bypass

The Meraki MG21, introduced in 2019, is a Cat 6 LTE gateway intended for fail-over connectivity. It features a soldered modem module and either two internal (MG21) or two external (MG21E) antennas.

Meraki MG21 LTE gateway

Here is a summary of the MG21 specs:

  • Qualcomm IPQ4029 (ARM A7, 4 cores @ ~700MHz)
  • 512MB DDR3 RAM (soldered)
  • 128MB of NAND flash (Winbond W29N01HV)
  • Cinterion PLAS9-X LTE Cat 6 modem module (LCC, soldered)
  • Gigabit Ethernet (x2, QCA8072 PHY)
  • Nano-SIM slot

There are no screws holding the MG21 together, the case is glued. As Meraki used glue and not adhesive to hold the MG21 together, heat does not help in opening the device. To open the MG21/MG21E: guitar picks and Isopropyl alcohol are recommended, with a lot of patience.

Opening the MG21 with guitar picks and Isopropyl alcohol

The 3.3V UART header in the MG21 is J5, which is unpopulated, and follows the standard Meraki pinout (1: VCC, 2: Tx, 3: Rx, 4: GND) with a 115200 baud rate. It looks like Meraki may have planned to ship the MG21 with an integrated u-blox module (U22), however on my production units the module is absent.

540-00144-01 48RLEQ01.0GA 2019.08.22


With the summary aside, let us focus on the secure boot status of the device. For context, see Breaking secure boot on the Meraki Z3 and Meraki Go GX20.

U-Boot 2017.07-RELEASE-gf49d105aeb-dirty (Jul 13 2020 - 11:22:51 -0700)

DRAM:  242 MiB
machid : 0x8010001
Product: meraki_Tie_Fighter
NAND:  ONFI device found
128 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
machid: 8010001
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=0", size 112 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 896, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 235/60, WL threshold: 4096, image sequence number: 2046230850
ubi0: available PEBs: 157, total reserved PEBs: 739, PEBs reserved for bad PEB handling: 20


Secure boot enabled.

Read 0 bytes from volume part.safe to 84000000
No size specified -> Using max size (29196288)
Valid image
## Loading kernel from FIT Image at 84000028 ...

Foreshadowing: You will notice that this output is very similar to that of the Z3 and GX20.

Unfortunately changing the EEPROM value to the MR33 (stinkbug) does not work, because Meraki have removed support for the legacy non-secure boot devices from recent U-Boot builds:

U-Boot 2017.07-RELEASE-gf49d105aeb-dirty (Jul 13 2020 - 11:22:51 -0700)

DRAM:  242 MiB
machid : 0x8010001
No product detected! (Major Number 30)
NAND:  ONFI device found
128 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
machid: 8010001
ubi0: attaching mtd1
(...)

Secure boot enabled.

Removing the BGA NAND and replacing the u-boot region with a dump of the Z3 2018 U-Boot build, U-Boot is still performing signature validation:

U-Boot 2017.07-RELEASE-g39cabb9bf3 (May 24 2018 - 14:07:32 -0700)

DRAM:  242 MiB
machid : 0x8010001
NAND:  ONFI device found
128 MiB
Using default environment

(...)

Secure boot enabled.

The reason for this is that the EEPROM is not found. But why? We have a clue from the stock bootlog of the device:

[   15.287320] i2c /dev entries driver
[   15.302889] at24 0-0056: 8192 byte 24c64 EEPROM, writable, 32 bytes/write

The EEPROM in the MG21 has the address 0x56 instead of 0x50 as on the Z3. This causes the downgraded Z3 U-Boot build to not detect the EEPROM.

The Meraki Go GR10 (Maggot) also has the EEPROM at address 0x56:

struct eeprom_i2c_config
{
	uint16_t gpio_scl;
	uint16_t gpio_scl_func;
	uint16_t gpio_sda;
	uint16_t gpio_sda_func;
	uint16_t eeprom_addr;
};
/* valid eeprom configuration for insects */
static const struct eeprom_i2c_config valid_eeprom_i2c_config[] = {
    { 20, 1, 21, 1, 0x50 }, // Stinkbug, Ladybug, Noisy Cricket
    { 10, 4, 11, 4, 0x56 }, // Maggot
};

However, the GR10 uses different GPIO pins to access the EEPROM.

I do not have the U-Boot source code of the MG21 to review (see endnote). Lacking the U-Boot source code, we can hexdump the Z3 and MG21 U-Boot regions from the flash dumps and compare.

Z3:

00044360  0f 00 14 00 01 00 15 00  01 00 50 00 0a 00 04 00  |..........P.....|
00044370  0b 00 04 00 56 00 00 00  00 f0 f4 a1 ea ea fb 01  |....V...........|

MG21:

000452f0  0f 00 14 00 01 00 15 00  01 00 50 00 14 00 01 00  |..........P.....|
00045300  15 00 01 00 56 00 00 00  00 f0 f4 a1 ea ea fb 01  |....V...........|

Decoding the structs from the hexdump we can infer the C source code used in the MG21 U-Boot build:

static const struct eeprom_i2c_config valid_eeprom_i2c_config[] = {
    { 20, 1, 21, 1, 0x50 }, // Fuzzy Cricket, Fairyfly, Heart of Gold
    { 20, 1, 21, 1, 0x56 }, // Tie Fighter
};

The only difference between the MG21 and Z3 is in the EEPROM address, the GPIO configuration remains the same.

Reviewing the datasheet of the at24 EEPROM, we can see that the address is set by the first 3 pins (A0-A2) being pulled to ground or Vcc. Since the EEPROM has the address 0x56, that must correspond to the bitmask 110 or: A0: 0, A1: Vcc, A2: Vcc.

After some verification on the PCB, removing the surface mount resistor R50 (4.7k) above U6 will remove Vcc from A1 and A2, changing the EEPROM address from 0x56 to 0x50.

The signed Z3 2018 U-Boot build now properly detects the EEPROM at address 0x50 and disables signature validation on the payload.

The chain-loaded U-Boot I used as a proof-of-concept is based on the Z3 GPL source code provided by Meraki in 2021, which does not include support for the MG21. Networking is non-functional, which makes further development challenging as images must be (slowly) transferred via UART.


Some readers may be wondering about the MG41. This secure boot bypass does not work on the MG41.

Meraki has signed the MG41 bootloader with a unique device certificate (x-wing), so cross-flashing U-Boot from another device such as the Z3 will not work.

Although the FCC internal photos of the MG41 show both NAND and EMMC, the production MG41 has only EMMC present. The boot_meraki_qca function has been re-written as boot_meraki_mmc_qca. During this re-write, Meraki removed the vulnerable switch statement that aborts enforcing signature validation on legacy products.


tl;dr

  1. MG21 uses the same device signing certificate as the Z3 and GX20
  2. Overwrite u-boot on NAND with dump from Z3 running 2018 release
  3. Change Product ID in EEPROM to device without secure boot (MR33)
  4. Desolder R50 to change EEPROM address

The MG41 is not vulnerable to this technique.


Model Meraki Board Part number
MG21 Tie Fighter 600-89010
MG21E Tie Fighter 600-89010
MG41 X-Wing 600-119020
MG41E X-Wing (unknown, let me know in comments)

There is still a long road ahead to support the MG21 with any custom firmware such as OpenWrt. Downgrading U-Boot on the device is not easy due to the weather proofing of the device, and the use of BGA NAND.

The GPL source code for the MG21 and MG41 was requested from Meraki in April 2024. At the time of writing Meraki has not provided any of the requested source code.

Meraki announced the end of sale of the MG21 and MG41 in March 2024, and stopped selling the MG21 and MG41 on 2024-09-18.