Category Archives: Hardware

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.

Meraki MX85 hardware overview

The Meraki MX85 SD-WAN appliance (codename “Box Wine”) is the replacement to the Meraki MX84 and offers 4 WAN uplink ports (2 SFP, 2 Gigabit Ethernet, 1 w/PoE), 10 LAN ports (8 Gigabit Ethernet, 2 SFP), a dedicated Gigabit Ethernet port for management, and a USB 3.0 port for external cellular modems¹.

Inside the Meraki MX85

Here is a summary of the MX85 specs:

  • NXP LayerScape LS1046A (ARM A72, 4 cores @ 1.8GHz)
  • 8GB DDR4 RAM (Samsung K4AAG165WA-BCWE x4, soldered)
  • 16GB of EMMC flash (SanDisk SDINBDA6-16G)
  • Winbond W25Q64JVSIQ (x2)
  • Aikido/Cisco TAM hardware root-of-trust (Microchip SmartFusion2 M2S010)
  • Qualcomm QCA8337-AL3C 7-port Gigabit Ethernet Switch (x2, PDF datasheet)
  • Qualcomm QCA8334-AL3C 4-port Gigabit Ethernet Switch (PDF datasheet)
  • Atheros AR8033-AL1A Gigabit Ethernet PHY (dedicated management port)
  • Microchip PD69104B1 PSE controller (PoE WAN port)
  • UMEC UP1501D-54 150W power supply

Meraki tries to be the Apple of SMB networking, and frequently uses premium materials like aluminum in their product designs (MS220, MS320, MS225, MS350, MX84). This is a bit silly for something that sits in a rack, but it is the brand image they were trying to cultivate.

The MX85 does not appear to use any aluminum in the chassis. Like the budget-oriented MS120 series, the entire MX85 chassis is made of steel. Meraki marketing will tell you this was for better cooling and is definitely not related to any cost reduction.

Meraki engineers even included thermal pads and metal spacers on top of the SFP ports (and below the PCB) to dissipate heat through the chassis. You could be forgiven for assuming they are SFP+ ports (they are not) with so much attention given to heat dissipation.

All for a device which consumes less power at idle than the (also) passively-cooled MX84, and no longer includes a spinning hard drive.

Unlike previous products, Meraki use glue to secure the front panel ribbon cable


The UART header is J3 on the MX85 and follows the standard Meraki UART pinout (1: VCC, 2: Tx, 3: Rx, 4: GND) at 3.3V and 115200 baud.

Note: R6 and R7 are 0 ohm resistors which (dis)connect Tx and Rx lines of the SoC to the UART header. R6/R7 are not populated by default. You must populate them, or bridge the pads, for the UART header to function.


The U-Boot release on the MX85 is 2018.09julia-spl-boxwine and, like all other recent Meraki products, it does not allow interrupting boot.

U-Boot SPL 2018.09julia-spl-boxwine (Mar 17 2021 - 20:02:01 +0000)
Initializing DDR....using SPD
DDR clock (MCLK cycle 952 ps) is slower than DIMM(s) (tCKmax 750 ps) can support.
Trying to boot from BOOTROM


U-Boot 2018.09julia-spl-boxwine (Mar 17 2021 - 20:02:01 +0000)

SoC:  LS1046AE Rev1.0 (0x87070010)
Clock Configuration:
       CPU0(A72):1800 MHz  CPU1(A72):1800 MHz  CPU2(A72):1800 MHz  
       CPU3(A72):1800 MHz  
       Bus:      700  MHz  DDR:      2100 MT/s  FMAN:     800  MHz
Reset Configuration Word (RCW):
       00000000: 0e150012 10000000 00000000 00000000
       00000010: 33330000 00b00012 40000000 c1000000
       00000020: 00000000 00000000 00000000 00018ffc
       00000030: 20004504 01003000 00000096 00000001
Model: LS1046A RDB Board
Board: LS1046ARDB, boot from Invalid setting of SW5
CPLD:  V0.0
PCBA:  V0.0
SERDES Reference Clocks:
SD1_CLK1 = 100.00MHZ, SD1_CLK2 = 100.00MHZ
I2C:   ready
DRAM:  Detected UDIMM Fixed DDR on board
DDR clock (MCLK cycle 952 ps) is slower than DIMM(s) (tCKmax 750 ps) can support.
7.9 GiB (DDR4, 64-bit, CL=15, ECC off)
SEC0: RNG instantiated
PPA Firmware: Version LSDK-18.09
GPIO:	initialized
setting up RGB LED controller lp5562....
Using SERDES1 Protocol: 13107 (0x3333)
Using SERDES2 Protocol: 0 (0x0)
SERDES2[PRTCL] = 0x0 is not valid
NAND:  0 MiB
MMC:   FSL_SDHC: 0
EEPROM: meraki_MX85 600-102010
In:    serial
Out:   serial
Err:   serial
Net:   Invalid SerDes protocol 0x3333 for LS1046ARDB
Fman1: Uploading microcode version 108.4.9
Could not get PHY for MDIO2: addr 8
Failed to connect
Could not get PHY for MDIO2: addr 9
Failed to connect
Could not get PHY for MDIO1: addr 9
Failed to connect
PCIe0: pcie@3400000 disabled
PCIe1: pcie@3500000 disabled
PCIe2: pcie@3600000 disabled
FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5 [PRIME], FM1@DTSEC6, FM1@DTSEC9, FM1@DTSEC10

As we can see from the above ECC off output, the MX85 is using non-ECC RAM. This is a downgrade from the MX84 which did use ECC memory.

The MX85 also contains the Cisco TAM, implemented using a SmartFusion2 M2S010. The TAM is used for secure boot.

## Starting application at 0x82120000 ...
bootselect
## Application terminated, rc = 0x0
## Starting application at 0x82120000 ...

----Security Versions----
SecureBoot:  R6.3.66-f6737c7-20200623
SB Core:     F01257R21.038ae8d0b2020-05-15
Microloader: MK0007R01.0105062020
SF: Detected SPI Generic with page size 256 Bytes, erase size 4 KiB, total 16 MiB

----SecureBoot Registers----
system_invalid:            0
boot_check_count_error:    0
boot_done:                 1
boot_ok:                   1
boot_check_count_golden:   0
boot_check_count_upgrade:  2
boot_status_golden:        0
boot_status_upgrade:       1
first_bootloader:          1

----Upgrade----
boot_error:                0
boot_check_count_error_vc: 0
boot_check_count_error:    0
boot_timeout_vc:           0
boot_timeout:              0
boot_cs_good:              1
boot_config_error:         0
boot_version_error:        0
boot_config_error_code:    0
boot_error_code:           0
boot_cs_good:              1
boot_version_error:        0
boot1_cs_key_type:         1
boot1_cs_return_code:      0
boot1_cs_key_index:        5
boot2_cs_return_code:      0
boot2_cs_key_index:        5
boot2_cs_key_type:         1

----Other Registers----
fpga_version:      0090

Reading whitelist from TAM
whitelist.bin: 740 bytes

Converting whitelist to signature fdt
BOX-WINE_LDWM-rel
wired-arm64-AP-SECP384R1_1-rel
wired-arm64-OD-SECP384R1_1-rel
wired-arm64-RT-SECP384R1_1-rel
wrote 558 bytes to 0000000082330000
## Application terminated, rc = 0x0
** File not found part.new **
87760567 bytes read in 4176 ms (20 MiB/s)
## Loading kernel from FIT Image at a0000000 ...
   Using 'conf@3' configuration
   Verifying Hash Integrity ... sha384,secp384r1:wired-arm64-RT-SECP384R1_1-rel+ OK
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0xa000012c
     Data Size:    10563592 Bytes = 10.1 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x80080000
     Entry Point:  0x80080000
     Hash algo:    sha1
     Hash value:   186b252be8c267ec7b20b072de98fe3d51c93c7f
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at a0000000 ...
   Using 'conf@3' configuration
   Verifying Hash Integrity ... sha384,secp384r1:wired-arm64-RT-SECP384R1_1-rel+ OK
   Trying 'ramdisk@1' ramdisk subimage
     Description:  meraki-image
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0xa0a13224
     Data Size:    76964193 Bytes = 73.4 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   a1f027fbf5acbf81befdb6ce746fee76adf132d5
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at a0000000 ...
   Using 'conf@3' configuration
   Verifying Hash Integrity ... sha384,secp384r1:wired-arm64-RT-SECP384R1_1-rel+ OK
   Trying 'fdt@3' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0xa538fb0c
     Data Size:    46124 Bytes = 45 KiB
     Architecture: AArch64
     Load Address: 0x90000000
     Hash algo:    sha1
     Hash value:   dd869c604072a7e29f37cc6cb4e1c9c398a46295
   Verifying Hash Integrity ... sha1+ OK
   Loading fdt from 0xa538fb0c to 0x90000000
   Booting using the fdt blob at 0x90000000
   Loading Kernel Image ... OK
   Using Device Tree in place at 0000000090000000, end 000000009001e42b
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
fdt_update_ethernet_dt: Invalid SerDes prtcl 0x3333 for LS1046ARDB
WARNING failed to get smmu node: FDT_ERR_NOTFOUND
WARNING failed to get smmu node: FDT_ERR_NOTFOUND
*** din = 0x0000000000000000

All ahead full! Goodbye!

All head full! Screw all attempts to boot any other software on this device! Let the LIC-MX85-SEC-3Y embrace your wallet!

To anyone still wondering: no, there will never be OpenWrt support for this device.


Idle power consumption: ~15W

The power supply in the MX85 is the same model (UMEC UP1501D-54) found in the MS220-8P and the MS120-8FP. It is rated for 2.7A at +56VDC

UMEC UP1501D-54 label


Model Codename Part number
MX85 Box Wine 600-102010

The codename of the MX85 might be “wines” there are multiple references to both in the bootloader and firmware.


¹: USB modems with MX/Z series devices running firmware MX 18 or newer will be limited to best effort support and will not be receiving any future firmware fixes or improvements. Meraki documentation

It would seem that Meraki prefers their customers purchase an MG41 or MG51 than plug in their own USB LTE modem. Better margins and less to support, win-win!


The GPL source code for the MX85 was requested from Meraki in May 2024. At the time of writing Meraki has not provided any of the requested source code.

Meraki MS420 hardware overview

The Meraki MS420 series switches (codename “Fatboy”) offer 24 or 48 ports of 10G SFP+, with a dedicated gigabit Ethernet port for remote management.

The MS420 series does not support dedicated stacking capabilities, although you can always connect multiple switches together via SFP+.

The MS420 was discontinued in 2016, and is too old to support secure boot.

Here is a quick summary of the MS420 specs:

  • Broadcom BCM56840 family “Trident+” ASIC (Product Brief PDF). The BCM56846 is used for both 24 and 48 port models.
  • BCM84754 SFI-to-XFI PHY
  • Freescale P2020E (PowerPC) dual-core management CPU @ 1GHz
  • 128MB NAND (Hynix H27U1G8F2BTR-BC)
  • 2048MB DDR3 ECC RAM (soldered)

Like the PowerPC-based Meraki MX60 and MX80, the MS420-series uses Kernel 3.4.113.

Similar to other Meraki Broadcom-based switches, the MS420 series implements the packet engine in userspace, using the 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.

The UART header is CONN4 on the MS420 and follows the standard Meraki UART pinout (1: VCC, 2: Tx, 3: Rx, 4: GND) at 115200 baud.


The u-boot release on the MS420 is 2013.10 and allows interrupting the autoboot with the magic string xyzzy, as found on other older Meraki products before they disabled the boot delay. Therefore, you can interrupt the boot process, although you have only a few seconds to do so:

NAND boot... transfering control to secondary loader
Starting secondary loader ...
Booting U-boot
transfering control


U-Boot 2013.10-g9a6f165 (Mar 11 2016 - 20:09:33)

CPU0:  P2020E, Version: 2.1, (0x80ea0021)
Core:  e500, Version: 5.1, (0x80211051)
Clock Configuration:
       CPU0:1000 MHz, CPU1:1000 MHz, 
       CCB:333.333 MHz,
       DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz
L1:    D-cache 32 KiB enabled
       I-cache 32 KiB enabled
Board: Fatboy
I2C:   ready
DRAM:  2 GiB (DDR3, 64-bit, CL=6, ECC on)
L2:    512 KiB enabled
NAND:  128 MiB
*** Warning - bad CRC, using default environment

PCIe1: Root Complex, x1, regs @ 0xff70a000
  01:00.0     - 14e4:b846 - Network controller
PCIe1: Bus 00 - 01
PCIe2: Root Complex, no link, regs @ 0xff709000
PCIe2: Bus 02 - 02
In:    serial
Out:   serial
Err:   serial
init GPIO
init REAR FAN I2C to output
register sysled device
Set Fan in Full Speed
Net:   eTSEC1 [PRIME]
autoboot in 3 seconds
LOADER=>

Once you have gained access to the u-boot console it is possible to tftpboot your own payload.


The P2020E boots directly off NAND, without an intermediate “bootkernel” on SPI flash (as is the case on the MS220, MS210/225, and MS350).

Booting is not as straightforward as just creating a FIT image. Similar to the MX80, Meraki have created a custom image format which includes a header with additional data used to validate the integrity of the image.

The layout of the image header for the MS420 is as follows:

Header field Data type (value)
SHA1_MAGIC uint32 (0x8e73ed8a)
DATA_OFFSET int32 (0x0000400)
DATA_LEN int32
SHA1SUM char[20]

0000:00:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 21)
0001:02:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 21)
0001:03:00.0 Ethernet controller: Broadcom Corporation Device b846 (rev 02)

The switch contains a discrete I2C RTC (NXP PCF8563), however there is no battery present so the RTC does not retain the time across power cycles.

rtc-pcf8563 2-0051: low voltage detected, date/time is not reliable.
rtc-pcf8563 2-0051: setting system clock to 2010-03-21 03:00:00 UTC (1269140400)

The four 40mm system fans in the MS420 are controlled by an onsemi ADT7473 (PDF datasheet). It appears that only the internal temperature sensor of the ADT7473 is present (for anyone else wondering, digging into the kernel module reveals that temp1 corresponds to Remote 1 Temperature, temp2 to Local Temperature, and temp3 to Remote 2 Temperature). The Meraki firmware does a respectable job of managing fan speed; after booting and settling, the fans are not quite the 1U screamer as you might expect from such a switch. They are still audible, but it is tolerable and being near the switch does not require an investment in hearing protection.

The MS420 fans have a Meraki part number: FAN-MS420-R (P/N 680-29010). These are identical to the Cisco FAN-T1, which can be purchased for considerably less than the Meraki branded part.

The MS420 accepts two hot-swap power supplies (model PWR-MS420-400AC-R, P/N 640-29010), which in my units are Compuware model CPR-4011-4M1 with 12V/33A and 5Vsb/3A output (combined power 400W) and are 80+ Gold certified:

MS420-24 idle power consumption: ~85W (single PSU)
MS420-48 idle power consumption: ~100W (single PSU)


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

There are other Trident+ switches (like the Arista DCS-7050S) that can be purchased for around $200 USD, and do not require any additional effort to use. Unless you have decommissioned MS420 switches, I would recommend against buying one as there are better options available.


Model Meraki Board Part number
MS420-24 FATBOY 600-29020
MS420-48 FATBOY 600-29010