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....

If this is a common problem, then maybe this my idea is worth to mention, even though it is hard to implement.

In theory, it is possible to place a hardware switch between the WAN port and Ethernet cable and control it with GPIO. If we can somehow trigger it to disconnect data lines at poweroff and reboot, and signal it to connect when the switch is properly configured, then this could be a valid solution.

I know that it would require creating a custom hardware device. Just leaving this idea here. Maybe someone will bother to actually implement it.