A Banana Pi-based router

Server Services

The entire Debian set of packages is available because Bananian uses the ARMv7 architecture that has long been supported by Debian. Moreover, all of the programs that have been specially compiled for the Raspberry Pi run on the architecture, because ARMv7 is downward compatible.

MicroSD cards, USB-connected storage, and a SATA disk all qualify as bulk storage for the server services. The performance of all of these options is sufficient for streaming content. However, the system is not as suitable when used as network-attached storage (NAS) for administering large volumes of data. This is because the R1 suffers from the same I/O weaknesses as the Banana Pi, the Cubietruck, or other A20-based boards. Large volumes of data lower the throughput to the network so dramatically that the choice of bulk storage depends more on its capacity than on its speed.

A bug found in pre-April 2015 versions of Bananian needs attention if you choose to use a SATA disk: The hardware configuration does not provide power to the disk. See the "Turning on the Power Supply" box to see how to approach this problem [6].

Turning on the Power Supply

Configuration of hardware on the R1 board is contained in the binary file script.bin on the first partition. The system evaluates the contents of this during bootup. After mounting the first partition to /mnt and making a backup copy of the file before editing it:

$ sudo mount /dev/sdc1 /mnt
$ cd /mnt
$ cp script.bin ~/
$ cd ~

you should change the file into text format with the bin2fex tool. Similarly, the fex2bin tool changes the file back (Listing 3).

In the text file, find the lines from Listing 4 and modify them as shown. In the original file, the key sata_power_en has no value. After changing the file back to binary format, restart the R1. The SATA connection should now have power.

Listing 3

Binary File Tools

$ sudo bin2fex /mnt/script.bin /mnt/script.fex
$ sudo fex2bin /mnt/script.fex /mnt/script.bin

Listing 4

Power Configuration

sata_used = 1
sata_power_en = port:PB03<1><default><default><0>

For reasons unknown, the throughput tests performed with FTP, SCP, and Rsync deliver wildly varying results, ranging from 16MBps using FTP to 7MBps using SCP or Rsync. Only with the use of a solid-state drive (SSD) do FTP values increase to between 19 and 33MBps. In all cases, bulk storage is not the cause of the bottlenecks, as can be demonstrated by writing directly via dd.

Although these results are somewhat disappointing, they do not present a problem in practice. The user wanting to write or read large volumes of data (e.g., video files, photos) is better advised to use NAS. The R1 is a candidate for scenarios with low data volume requirements. The user who always moves data by WiFi will not notice any limitations.

Operating as a Router

To use the BPi-R1 as a router requires somewhat more effort in the configuration process. This procedure requires configuring the switch by editing the /etc/network/if-pre-up.d/swconfig file (Listing 5) in such a way that it makes two logical network cards available. The result is two VLANs and two logical interfaces: eth0.101 and eth0.102.

Listing 5

Set Up VLANs

swconfig dev eth0 set reset
swconfig dev eth0 set enable_vlan 1
swconfig dev eth0 vlan 101 set ports '3 8t'
swconfig dev eth0 vlan 102 set ports '4 0 1 2 8t'
swconfig dev eth0 set apply

Now configure the two interfaces via /etc/network/interfaces as you would physical connections (Listing 6). For the first test, you should open routing between the two networks with the command:

Listing 6


auto lo
iface lo inet loopback
auto eth0.101
auto eth0.102
iface eth0.101 inet static
iface eth0.102 inet static
$ sudo echo 1 > /proc/sys/net/ipv4/ip_forward

For a permanent change, you should enter the line net.ip4.ip_forward=1 in the /etc/sysctl.conf file. If the router is also supposed to serve as a firewall with integrated NAT (e.g., if an interface is attached directly on a DSL modem), then the corresponding iptable commands are required. An ample supply of directions for how this is done can be found online [7]. The settings shown in Listing 7 in the /etc/dnsmasq.conf file ensure that the R1 DHCP only responds to requests on eth0.102. In contrast to switching, routing uses the CPU core and thus creates a few percent load on the CPU. The average routing throughput is 72 to 77MBps.

Listing 7



Buy this article as PDF

Express-Checkout as PDF

Pages: 6

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content