WatchGuard Firebox M300 is an entry-level rack-mountable device running on a Freescale T2081 processor (quad-core, octa-thread, 1.8 GHz, OpenWrt target qoriq) with 4 GB of DDR3L ECC memory. The sole storage device is an 8 GB SD card.
The device appears to be a rebranded Lanner product (the case is very similar to x64-based related models, which are definitely Lanners), but I was not able to identify the underlying Lanner model. The system board is labeled MB-M300, which doesn’t appear to be a known Lanner designation. So I wonder whether this was a one-off Lanner did for WatchGuard…
OpenWrt installation was pretty easy. Initially, I didn’t want to overwrite the stock SD card, so I used a microSD card I had on hand, inserting it into an SD holder (I wrote the ext4 version of OpenWrt onto that one). After the successful first test, I wrote the squashfs version of OpenWrt onto the stock card and re-used it. Both times, I used the 24.10.4 release.
The installation procedure was exactly as described in the wiki:
Long story short, you take the SD card out of its holder on the system board, write your choice of firmware onto it, return the SD card into its holder, and boot the device while accessing it using serial console. The device attempts to boot as if it still had stock firmware, fails, and you get command prompt. Once that happens, you run:
setenv OpenWrt_kernel watchguard_firebox-m300-fit-uImage.itb
setenv loadaddr 0x20000000
setenv wgBootSysA 'setenv bootargs root=/dev/mmcblk0p2 rw rootdelay=2 console=$consoledev,$baudrate fsl_dpaa_fman.fsl_fm_max_frm=1530; mmc dev 0; ext2load mmc 0:1 $loadaddr $OpenWrt_kernel; bootm $loadaddr'
saveenv
reset
This allows OpenWrt to be loaded at boot. Speaking of loading, the M300 appears to have a small non-removable storage device on which the bootloader resides. Here’s what storage layout looks like according to lsblk:
root@OpenWrt:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 100.6M 0 loop /overlay
mtdblock0 31:0 0 64K 1 disk
mtdblock1 31:1 0 128K 1 disk
mtdblock2 31:2 0 64K 1 disk
mtdblock3 31:3 0 64K 1 disk
mtdblock4 31:4 0 704K 1 disk
mtdblock5 31:5 0 704K 1 disk
mtdblock6 31:6 0 704K 1 disk
mtdblock7 31:7 0 768K 1 disk
mtdblock8 31:8 0 64K 1 disk
mtdblock9 31:9 0 64K 0 disk
mtdblock10 31:10 0 768K 1 disk
mmcblk0 179:0 0 7.3G 0 disk
├─mmcblk0p1 179:1 0 16M 0 part
└─mmcblk0p2 179:2 0 104M 0 part /rom
So when I boot my device, I am initially greeted with the stock U-Boot screen:
After that, OpenWrt boots, never mind what U-Boot says…
Networking is eight Gigabit ports. Three (eth0-eth2) appear to be independently configurable, the rest (sweth3@eth4-sweth7@eth4) are in a switch configuration. There’s also an eth3 port, which somehow has the same MAC address as sweth3@eth4. I am not sure what to make of this. By default, eth0 is WAN (and a DHCP client), eth1 is LAN (192.168.1.1, the DHCP server for the 192.168.1.* range), the remaining ports are configured with static IP addresses (10.0.x.1, where x is the port number ranging from 3 to 7).
Initial performance tests were somewhat underwhelming. Bidirectional iperf3 (client on LAN, server on WAN) reported this:
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-10.00 sec 726 MBytes 609 Mbits/sec 790 sender
[ 5][TX-C] 0.00-10.01 sec 724 MBytes 606 Mbits/sec receiver
[ 7][RX-C] 0.00-10.00 sec 902 MBytes 757 Mbits/sec 166 sender
[ 7][RX-C] 0.00-10.01 sec 899 MBytes 753 Mbits/sec receiver
During the test, two processor threads were maxed out, so that made me wonder whether offloading and/or packet steering could help improve the situation. Packet steering with suggested (128) steering flows didn’t do anything; switching to 256 steering flows actually reduced the reported throughput slightly. So I reverted to the default (Standard: none). Offloading, on the other hand, helped instantaneously. After I enabled hardware offloading, reported performance improved:
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec 0 sender
[ 5][TX-C] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec receiver
[ 7][RX-C] 0.00-10.00 sec 1.04 GBytes 897 Mbits/sec 95 sender
[ 7][RX-C] 0.00-10.00 sec 1.04 GBytes 895 Mbits/sec receiver
The two processor threads that were previously maxed out now hovered in the 30-40% load range.
Overall, I am intrigued by the concept. Decent, though not stellar, processor speed combined with a high thread count, ECC memory, a built-in switch — this could be an interesting combination of features in specific use cases…
