BPQ

Bpqether is a Linux kernel driver which allows the use of AX.25 over ethernet-like networks such as Ethernet, 802.11 family Wifi networks but also virtual devices such as the Linux software bridge, VLANs and more.

Unsupported networking technologies

Technologies which are similar to Ethernet but not supported are FDDI, HIPPI. It might be a matter of testing but as long as this has not positively tested the kernel will not allow configuring BPQ over these devices.

Configuration

Up to Linux 4.1 the behaviour is that when the bpqether driver is built into the kernel or loaded as a module a network interface named bpq followed by a small decimal number is created for every ethernet-like device. Details can be seen in /proc/net/bpqether which might look like:

dev   ether      destination        accept from
bpq5  vnet1      ff:ff:ff:ff:ff:ff  *
bpq3  vbridge    ff:ff:ff:ff:ff:ff  *
bpq2  virbr0     ff:ff:ff:ff:ff:ff  *
bpq1  wlan0      ff:ff:ff:ff:ff:ff  *
bpq0  eth0       ff:ff:ff:ff:ff:ff  *

So bpq0 maps to eth0, bpq to the wireless interface wlan0 and bpq2..bpq5 map to virtual interfaces and bridges related to hosting KVM machines. Each of these machines can be configured as usual, for example to assign the callsign ABCDEF-7 and IP address 172.20.4.1 with a /24 prefix equivalent to a 255.255.255.0 netmask:

ifconfig bpq0 hw ax25 abcdef-7 172.20.4.1/24

By default a BPQ interface will accept traffic from any sender and the destination address is a broadcast address. While this minimizes the configuration required it results in unnecessary load for others than the intended destination system. So it is preferrable to set a specific destination address as long as all outgoing BPQ traffic on this interface is targeted for the same destination system. Similarly it is possible to limit from which Ethernet address a packet is accepted.

Security

The accept from and destination settings are not a suitable security mechanism. They should rather be considered as a mechanism to limited the impact of gross missconfiguration of a network and performance optimization.

BPQ Multicast address

Some systems are using the ethernet address 01:42:50:51:00:00 as the BPQ multicast address. Most Ethernet NICs will accept address that has the lowest bit of its first byte set as a multicast address and accept that as a broadcast packet

RLI encapsulation

also known as BPQENET is a minor but incompatible variant of BPQ encapsulation. Like BPQ encapsulation it's using Ethernet packet type 0x08ff but has an extra 3 byte header following that Ethernet type. Linux does not support this type of encapsulation. RLE originated in Hank W0RLI's SNOS.

Rewrite of bpqether

One of the problems of the bpqether driver is that it creates lots of unnecessary interfaces. This is in particular a problem on big systems with many ethernet interfaces or KVM hosts systems. There is also no guarantee that on each bootup a particular bpq interface will map to the same ethernet interface. And bpq needs to be configured with bpqparms which uses bpqether-specific ioctls, both practices which are frowned upon for many years.

A new mechanism is based on the standard rtnetlink protocol and ip(8) utility and is available in

 http://git.linux-ax25.org/cgit/ralf/linux-rose.git/
 http://git.linux-ax25.org/cgit/ralf/iproute2.git/

The most significant change is that bpq interfaces are no longer created automatically. Instead a command like

 ip link add link eth0 name bpq0 type bpq

is required to configure the interface. Note that this is possible even using an old iproute2 version that doesn't contain support for BPQ. Advanced configuration, that is setting the accepted and destination ethernet addresses currently requires the iproute2 version from above GIT repository. This allows for example to

 ip link add link eth0 name bpq0 type bpq accept 24:74:71:15:74:fc destination 00:25:91:ac:91:f0
 ip link set dev eth0 accept 24:74:71:15:74:fc destination 00:25:91:ac:91:f0

to be used. You also may leave out the "name bpq0" part in which case the kernel will pick a name starting with "bpq" followed by the first available number. This avoids conflicts but also means you no longer have a predictable name.

The old ioctl configuration mechanism and bpqparms are deprecated but retained for the time being, that is the existing bpqparms" program can continue to be used.