[REPORT] OpenWrt on Barracuda F100 Rev B

Applied networking archeology strikes again... :smile: The subject of today's dig is Barracuda F100 Revision B. In hopes of receiving a tiny nod of approval from @RaylynnKnight, whose vast knowledge of hardware I admire, I feel obligated to mention that this device is a rebranded Lanner FW6436A-BA1 (no research was necessary; the Lanner model designation was printed on a sticker on the bottom of the device).

The device came to me used (and running 32-bit pfSense rather than the stock firmware), so I will endeavor to point out the differences between my experience and manufacturer's information as I go along. Also, I am going to report in reverse chronological order, starting from my experience of running OpenWrt on this device and only then describing the OpenWrt installation process.

A silly story: the previous owner is located in the Pacific Northwest known for its moist climate, so removing the seven screws holding the device's top lid in place required application of WD-40. I honestly can't remember a single instance of having to do this before... This said, no corrosion was apparent.

Front view

Rear view

(Images from the manufacturer's Web site)

Barracuda F100 Revision B looks almost identical to the earlier Revision A, except Revision A has a VGA port in the back instead of an RJ-45 console port. There is an important difference though; Revision B is nominally Gigabit (more on that later), while Revision A is Fast Ethernet (100 Mbps).

The device is unusually wide compared to other desktop routers (374 mm / 14.7 in). A look at the back explains why: it has two PCI expansion slots that can fit low-profile PCI expansion cards. This brings up a question: is there enough power to feed those cards? I am inclined to (tentatively) answer yes. Despite having been built around a very low-power VIA Eden CPU, the device is rated for a 60W (12V / 5A) power intake. A related model, F180, operates on the same power budget and features 10 additional Ethernet ports (so the total number of ports is 14) and a Wi-Fi (b/g/n) card.

Performance-wise, this is hardly a beast. In my simulated environment with Gigabit connections to both LAN and WAN, I was consistently getting about 350 Mbps LAN-to-WAN throughput in an iperf3 test (iperf3 server connected to the WAN port, iperf3 client, to a LAN port). (I blame the low-power CPU, but I may be wrong.) Offloading didn't seem to improve the matters at all, so I switched it back off after trying it.

All this said, I think this device still has uses due to the combination of expandability and passive (fanless) cooling. I can easily see it (with expansion card(s) installed) servicing a RasPi cluster or some other group of IoT devices in a setting where a combination of large number of available ports, minimum number of separate boxes, and silent operation is desired despite the less-than stellar throughput.


As already mentioned, the device is built around a low-power VIA Eden processor (500 MHz). This is a 32-bit CPU, so it will require an x86/generic OpenWrt image. The device has 2 GB or RAM; the sole storage device is a 4 GB CF card. There are four Ethernet ports; the NIC is identified by lspci as Realtek RTL8111/8168/8411.

The only management interface the device offers is the RJ-45 console port. The manufacturer says the port speed is 19200 bps, but the device I had operated at 115200 (the previous owner probably adjusted the relevant BIOS settings). To make things even more confusing, the default speed for x86/generic OpenWrt is 38400, so I ended up installing OpenWrt at 38400 and then editing /boot/grub/grub.cfg to allow OpenWrt to operate at 115200 bps.

Speaking of BIOS, it is password-protected. The factory password is bcndk1 (barracuda-can-never-die-kindly-one), all letters in lower case. My attempts to remove it proved futile; the supposedly removed password would still be in place after reboot. Oh well, at least we know what the password is...

Installing OpenWrt

As already mentioned, this device requires a x86/generic installation image. I chose generic-ext4-combined.img.gz for no particular reason. Chances are, generic-squashfs-combined.img.gz would have worked just as well. As for UEFI images, I didn't find any references to UEFI in the BIOS, so I am assuming the hardware is legacy-only.

I downloaded the image, flashed it onto a blank CF card using Rufus on a Windows machine, replaced the stock CF card with mine, and the device booted with no complaints. Port detection and assignment happened very predictably; ports labeled 1 through 4 on the case were designated as eth0 through eth3. eth1 was assigned to the WAN interface, eth0, to the br-lan bridge. (Somewhat strangely, eth2 and eth3 were not added to the bridge, but that proved easy to fix.)

I edited /etc/config/network to flip the interface assignments for eth0 and eth1 (making eth0 WAN and eth1 a part of br-lan) and add eth2 and eth3 to br-lan. The first two sections of the file, config interface 'loopback' and config globals 'globals', didn't need any changes; the remainder of the file is given below.

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'
        list ports 'eth2'
        list ports 'eth3'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr ''
        option netmask ''
        option ip6assign '60'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0'
        option proto 'dhcpv6'

An alternative installation method would be to make a bootable USB stick, boot the device from it, and, once on the command line, do something along the lines of:

cd /tmp
wget https://downloads.openwrt.org/releases/22.03.3/targets/x86/generic/openwrt-22.03.3-x86-generic-generic-ext4-combined.img.gz
gunzip openwrt-22.03.3-x86-generic-generic-ext4-combined.img.gz
dd if=openwrt-22.03.3-x86-generic-generic-ext4-combined.img of=/dev/sda

Then, remove the USB stick from the device and turn the device back on.

Speaking of turning the device on, it has an unusual power switch design. The switch looks like a flipping switch, but it doesn't actually flip. After you flip it and release it, it immediately springs back to the initial position...

Concluding Thoughts and a Call for Suggestions

I appreciated the low-drama installation process and reman curious about the expansion possibilities. If anyone has suggestions about specific NICs I should try with this unit, please post them here. I think I can get away with at least one four-port Gigabit card power-wise, but it's got to be low-profile and compatible with the PCI slot (see photos below). Needless to say, availability of OpenWrt drivers/firmware would be crucial.

Here's a picture of the device's internals:

And here's the PCI riser:

You can use the round yellow OK label on top of the riser to figure out the relative orientation of the two views.


This, as in early Atom generations (N270, 330, D425/ D525, D2500; basically everything older than baytrail-d) and the various VIA CPUs, is usually better avoided, the performance to power consumption ratio just doesn't meet expectations (usually not able to achieve 1 GBit/s throughput, power consumptions above 20 watts idle). While they are relatively cheap and plenty, they are still too expensive for what they can deliver - yes, it takes more effort and patience to identify and score better devices, but you will find them nevertheless (and haswell-and-newer SFF devices from the big four (Dell, Fujitsu, HP, Lenovo), taking normal low-profile PCIe cards, are competing in the same price bracket (more performance, widely varying power consumptions (10-30 watts, depending on the manufacturer/ model), but still not worse than those early (pre-baytrail) Atom/ VIA devices).

Very personally, I'd consider the various AMD Jaguar solutions to be sub-par as well, but compared to early Atom and VIA CPUs they are still better (a bit faster, better power consumption figures). The even older socket 479 Pentium M (Banias, Dothan and friends) belong to the landfill (faster than VIA, but really, pass).

These will be still very solid networking devices, they just can't meet modern expectations of performance and (low-) power consumption.

The platform with a CPU almost 20yrs ago, not really worth to spend time on it even with it's ultra low power consumption because it's too slow and big....

I passed on these devices some time ago due to the VIA CPU which as stated by others is low performance and high power consumption.