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