The horrible Banana PI R1 bug

Hi. Months ago I was considering the Banana PI R1 as my first OpenWRT device. However, I've come across information on a horrible design flaw in it.

Basically, its internal switch cold boots into a state where it bridges everything, including the "WAN port". The WAN port is only separated once the CPU gives the switching chip new orders. So there is a window where the device simply doesn't firewall, and a risk that said window could be open for a long time if the operating system were to fail to boot.

With IPv4, where everyone uses private address space and masquerading, this would be a hole only one's own ISP could exploit. But in IPv6, where publicly routable internal addresses are encouraged, you'd be naked.

You can fix it by using a USB-Ethernet dongle for the WAN connection, but then the R1 offers no value above the many small computers that have only one built-in Ethernet port.

This problem is so bad that it deserves a remark on the table of hardware.

Also, I'd ask those who can find out to see if any other listed hardware has a similar flaw. In particular, I am now thinking of the Espressobin now that the Banana is struck off my list. (It openly has a similar everything-done-in-the-managed-switch design, but I've seen a claim the switching hardware is fail-secure, not turning on until the CPU approves.)


That is a problem on a number of device, including more classic routers. While there isn't a real fix for this, it is possible to reduce the impact by reducing the time window of the unconfigured switch mashing all ports together, ideally to a time span that isn't sufficient for a successful DHCP lease to be acquired (same with IPv6 RAs). A special preloader sitting between the real bootloader and the kernel (doing nothing but disabling all switch ports and then chainloading into the real kernel) can mitigate this a bit (and this needs to be applied on a number of devices), but there obviously isn't a real fix for this rather basic hardware deficiency.

If you want to avoid this altogether, you need to look for devices with a dedicated WAN port not connected to its internal switch instead. Modern devices with two CPU ports might be a bit more smart about sane default switch configs, but this isn't guaranteed either, the only really safe solution are dedicated low-level interfaces for LAN and WAN.

1 Like

If you want to avoid this altogether, you need to look for devices with a dedicated WAN port not connected to its internal switch instead.

But I don't see how to filter those from the current Table of Hardware; if there are even any devices currently sold that are that clean. (Outside of full-size PCs.)

Of course, there is always the brute-force approach of adding a USB-Ethernet pigtail to anything, but that's ugly....