xlxd – K2IE

The Importance of IPv6 in Amateur Radio

What most of us call an IP address, in the form 1.2.3.4, is really an IP Version 4 (IPv4) address. IPv4 has a serious limitation. The largest number that can be respresented in the 32 bit binary value of an IPv4 address is 2 ^ 32 (4,294,967,296). Believe it or not, these addresses are in short supply.

IPv6 was created as a solution almost 23 years ago. An important specification document was published in December 1998. IPv6 World Launch Day was 10 years ago! IPv6 is not new. IPv6 provides 2 ^ 128 (340 trillion trillion trillion) addresses. So why aren’t we all using IPv6 now?

Aside from a bounty of address space, there are other reasons to adopt IPv6. Large network providers have built new and optimized infrastructure with IPv6 in mind. Here’s an example of how this can work to your advantage.

The 020 Digital Multiprotocol system has bridge to the Brandmeister DMR (BM) system. Low network latency is of critical importance in delivering high quality voice connections. Any network latency created issues are amplified when voice transmissions are passed through multiple applications and protocol transcoding hops.

Using the IPv4 network, ping time between our end of the bridge and BM is about 8 ms. That is actually pretty good. IPv6 blows that away, with about 1.5 ms ping times. That reason was good enough for me to get my hands dirty and modify some Python code to be IPv6 capable.

IPv6 also helps with the problem of NAT and port forwarding on residential routers. Simply put, NAT can be thrown into the trash bin of computing history. Instead of just one address, the minimum network assignment under IPv6 is 64 bits. That is 2 ^ 64 addresses!

Several ham software authors and volunteers are working on updating their software to be IPv6 capable. My amateur radio wishlist for full IPv6 capability includes xlxd, DMRGateway and ircDDBGateway. HBlink will be there once my pull request is merged. That is the Python code I referred to that links the 020 world to Brandmeister.

N7TAE has a functional QnetGateway using IPv6. I could not get it to work with my DVAPs and will need to followup up with Tom, but he has provided a wide range of hardware support including MMDVM devices.

There are a lot of bits and pieces that will be involved with updating amateur radio software, much of it ancient, to IPv6. So let’s start now. This will take time. And, if you’re a ham working on some new software for the amateur radio world, please make sure that it supports IPv6 out of the box.

73 de K2IE

XLX020 Supports Direct YSF

XLX020 has upgraded to Luc (LX1IQ)’s latest xlxd (2.3.1) software. We now support direct connections via the Yaesu YSF protocol.

Luc is in contact with the distributors of Pi-Star and the OpenSpot to have this capability added to the dashboards. In the meantime, there is a simple change that you can make to your Pi-Star configuration to connection to XLX020.

You’ll have to be willing to edit your Pi-Star /etc/mmdvmhost file. Look for the [System Fusion Network] stanza. You’ll need to change the GatewayAddress to xlx020.k2ie.net and the GatewayPort to 42000. You’ll also need to change LocalPort to 0.

[System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=0
GatewayAddress=xlx020.k2ie.net
GatewayPort=42000
Debug=0
ModeHang=20

See on you Fusion!

73 de K2IE

xlxd and SELinux

TL;DR — If you’re not running an xlxd based reflector using SELinux you can skip this post.

I recently migrated the XLX reflector from Debian Stretch to Fedora FC30. Debian is the platform recommended by the software author, but xlxd runs fine under Fedora as well. However, since I’m running with SELinux enabled, there were a couple of issues to tackle.

SELinux tags filesystem elements with a security context and in some cases, xlxd fails to access certain files for which it does not have authorization. There are three files that will require some special attention.

xlxd.pid -- contains the running process number
xlxd.log -- the XML log file used by the dashboard
callinghome.php -- contains the hash value used for registration

In my system, the files are installed in the following directories:

/var/run/xlxd.pid
/var/log/xlxd.log
/var/lib/httpd/xlxd/callinghome.php

I had to create new rules to put the files in the correct security contexts.

semanage fcontext -a -t httpd_sys_content_t /var/log/xlxd.xml
semanage fcontext -a -t httpd_sys_content_t /var/run/xlxd.pid
semanage fcontext -a -t httpd_sys_rw_content_t \
         /var/lib/httpd /xlxd/callinghome.php

One issue I discovered is that the contexts do not handle the creation of a new file. For that, I installed restorecond. This system daemon watches for specified files to be created and relabels the security context.

dnf install restorecon

Then, add the 3 fully pathed file names to /etc/selinux/targeted/contexts/files/file_contexts.local. Restart the restorecond service and you’re ready to start the xlxd, httpd, and php-fpm services.

A very useful command is ls -lZ. On an SELinux enabled system it will list the security context labels for each file.

ls -lZ
 total 4
 -rwxrwxrwx. 1 apache apache system_u:object_r:httpd_sys_rw_content_t:s0 66 May 16 14:12 callinghome.php

Another useful command is restorecon. RTFM.