{"id":919,"date":"2022-04-16T11:50:26","date_gmt":"2022-04-16T09:50:26","guid":{"rendered":"https:\/\/www.i8zse.it\/en\/?p=919"},"modified":"2026-06-07T11:54:21","modified_gmt":"2026-06-07T09:54:21","slug":"packet-bbs","status":"publish","type":"post","link":"https:\/\/www.i8zse.it\/en\/packet-bbs\/","title":{"rendered":"Packet BBS"},"content":{"rendered":"

“`html<\/p>\n

The Foundations: the Linux Kernel and the AX.25 Stack<\/h2>\n

Packet Radio<\/em><\/strong> celebrates around 40 years of existence in 2022, considering the first experiments developed between the late 1970s and early 1980s. During those years, several amateur radio groups contributed to the development of this technology; among them, the American Radio Research and Development Corporation (AMRAD) proposed the use of an amateur-radio-adapted version of the CCITT X.25 standard, a packet networking protocol. This was something revolutionary compared to other digital amateur radio communication technologies of the time. AX.25 indeed allows, thanks to its shared medium access mechanism (CSMA), multiple stations (nodes) to operate on the same frequency, enabling the sharing of a single radio channel among multiple users. Furthermore, through nodes and digipeaters implementing store-and-forward<\/em> mechanisms, reliable transfers can be achieved even between two stations that are not directly reachable. This was a completely different world compared to typical amateur digital communications, generally point-to-point, and extremely interesting also from an educational standpoint, considering that at the time data networks were still in their infancy even in the business<\/em> world. The downside was that its implementation required each node to be equipped with a TNC (terminal node controller<\/em>), a small dedicated microcomputer handling all processing required for data exchange.<\/p>\n

This was still technology largely developed by radio amateurs, driven in those years by the Tucson Amateur Packet Radio (TAPR) group: their TNC-1 kit appeared in the July<\/a> and August<\/a> 1983 issues of Ham Radio Magazine and became the first of a long series of amateur and commercial products.<\/p>\n

Although activating it in those years required significant investment \u2014 in addition to the TNC, a computer or terminal was essential \u2014 packet radio quickly gained a strong community of enthusiasts due to its ability to distribute and make amateur radio news and documentation available across regions. Its golden age lasted over 10 years. Then, in parallel with the development of the Internet, which gradually overshadowed this capability, it fell into near disuse. Today it is mainly used as support for APRS, but it still survives in local networks and experimental activities.<\/p>\n

That said, packet radio remains an excellent educational and experimental tool in the field of networks and digital communications \u2014 especially today, when technological advances have made it possible to implement it at negligible cost.<\/p>\n

An example is the packet node I assembled these days, operating from my shack on 144.875 MHz.<\/p>\n

\"BBS<\/a><\/p>\n

It is based on an old Raspberry Pi 1 B. To \u201cdo packet\u201d with a Raspberry Pi, which does not have a usable analog audio input, it is sufficient to add a USB audio \u201cdongle\u201d. The transceiver is an old Icom IC-02E.<\/p>\n

The Operating System<\/h3>\n

Linux has native support for AX.25 and is therefore the most suitable operating system for this application. As a distribution I used Devuan<\/a>, a Debian-based system without systemd<\/em>: the resources of the RPi-1 are quite limited, so it is useful to follow the KISS<\/a> philosophy. I specifically used version 2 (called ascii<\/em>), which uses kernel 4.14. For packet radio use it may be preferable to avoid very recent kernels, since in some configurations the AX.25 stack presents known unresolved issues. In particular, on Raspberry Pi systems there is also a known bug<\/a> that may affect proper operation.<\/p>\n

TNC functions are implemented in software. On Linux there are two main solutions: soundmodem<\/em><\/strong> and direwolf<\/em><\/strong>. The latter is more modern and offers superior features, but on very limited hardware such as the RPi-1 it requires more resources. I therefore used the lighter soundmodem<\/a> (a different project from the similarly named Windows version by UZ7HO), which still works very well with a low resource footprint.<\/p>\n

The packages to install via apt-get are therefore soundmodem, libax25, libax25-dev, ax25-tools, ax25-apps<\/em>. It is convenient to disable onboard audio by editing \/boot\/config.txt and adding the line dtparam=audio=off<\/strong><\/code>.<\/p>\n

The Transceiver<\/h3>\n

The project is intended for 24\/7 continuous operation, so it requires a dedicated device. The most suitable type is an HT, or walkie talkie<\/em>. It is likely that you already have one unused in your shack, and nowadays they are extremely inexpensive anyway. I used an old Icom IC-02E, but I also tested other devices such as the Baofeng UV-5R. Since handheld radios do not have a standard method for transmit switching, a dedicated interface must be built.<\/p>\n

The Interface<\/h3>\n

This can be adapted, with small variations, to multiple models: those that key by pulling the microphone hot line to ground through a resistor (Icom, Yaesu), and those that instead close the microphone ground to the speaker ground (Baofeng).<\/p>\n

\"Digital<\/a><\/p>\n

The two audio lines are used to match the output levels of the Raspberry Pi and the HT (both designed for headphones\/speakers) to the microphone inputs of the counterpart, with DC isolation. I did not find it necessary to use isolation transformers.<\/p>\n

A third line is used for transmit switching (PTT). Some people use the HT VOX, but this is not an optimal solution: it is designed for voice and introduces unwanted delay in digital modes, increasing latency. The best solution, in the case of a Raspberry Pi, is to use a GPIO line such as GPIO4.<\/p>\n

Both soundmodem and direwolf allow direct use of a GPIO as PTT, as does hamlib for radios with CAT control, or classic serial control line interfaces.<\/p>\n

GPIO isolation (which operates at 3.3V) is handled by an optocoupler.<\/p>\n

\"BBS\u2013RTX<\/a><\/p>\n

AX.25<\/h3>\n

The next step is configuring the AX.25 stack. The first file to modify is \/etc\/ax25\/axports<\/em>:<\/p>\n\n\n\n
\n
# \/etc\/ax25\/axports\r\n#\r\n# name callsign speed paclen window description\r\n#\r\nax0 I8ZSE-3 1200 255 2 144.875 (1200 bps)<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The fields are: name<\/strong>, callsign<\/strong>, speed<\/strong>, paclen<\/strong>, window<\/strong>, and description<\/strong>.<\/p>\n
Once the port is defined, soundmodem is configured in \/etc\/ax25\/soundmodem.conf<\/em>. […]<\/p>\n
In the pkt<\/em><\/strong> line, mode<\/em><\/strong> can take two values: MKISS<\/em><\/strong> and KISS<\/em><\/strong>. MKISS allows multi-channel operation and can be used as a basis for more advanced configurations, while KISS creates a simple interface to the AX.25 stack.<\/p>\n
Hamlib<\/h3>\n
[…]<\/p>\n
Soundmodem must always run in the background; it can be started automatically at boot, for example via crontab<\/em> using an @reboot<\/strong><\/code> entry.<\/p>\n
After rebooting, the AX.25 stack should be configured and active.<\/p>\n
With more powerful hardware (such as an RPi-3\/4 or a PC), it is possible to use Direwolf<\/strong><\/em> instead of soundmodem as a soft-modem. It implements the basic functions of a KISS TNC but also offers many additional features. It can operate as an APRS GPS tracker, digipeater, and gateway without external software, and can be used over TCP\/IP as well as through the AX.25 stack. The full feature list is available on the project\u2019s GitHub<\/a> page.<\/p>\n
Direwolf is available in the apt-get repositories; however, since it is an actively developed project, it may be preferable to download and compile the latest source code.<\/p>\n
The Direwolf configuration file is a simple text file. For TNC usage, the following example is equivalent to the soundmodem configuration shown earlier:<\/p>\n
PTT GPIO 4\r\nACHANNELS 1\r\nCHANNEL 0\r\nMYCALL I8ZSE-1\r\nMODEM 1200<\/pre>\n
Direwolf supports several PTT control methods, all well documented. For example, for a Yaesu FT-897 connected via CAT at 38400 bps:<\/p>\n
PTT RIG 1023 \/dev\/ttyUSB0 38400<\/pre>\n
Direwolf can display diagnostic information directly to stdout, which is very useful for system tuning. For this reason it is convenient to run it in a separate terminal so that it can be monitored at any time. For this purpose, GNU screen can be used, installable with apt-get install screen<\/em>. Screen<\/em><\/strong> is a terminal multiplexer that allows persistent sessions detached from the original terminal, which can be reattached later.<\/p>\n
To start Direwolf I use the following script:<\/p>\n
echo \"starting Direwolf...\"\r\n\/usr\/bin\/screen -d -m -S direwolf \/usr\/bin\/direwolf -p -c direwolf.conf -t 0\r\nsleep 2\r\nPTS=`ls -l \/tmp\/kisstnc | awk '{ print $11 }'`\r\n\/usr\/sbin\/kissattach $PTS ax0\r\n# set kiss parameters\r\n\/usr\/sbin\/kissparms -c 1 -p ax0 -r 125 -t 250 -s 20 -f n -l 20\r\necho \"... started\"<\/pre>\n
The command \/usr\/bin\/screen -d -m -S direwolf<\/em> starts a detached session named direwolf<\/em>, in which \/usr\/bin\/direwolf -p -c direwolf.conf -t 0<\/em> is executed. The -p<\/em> option creates a pseudo-terminal used to connect the AX.25 stack, while -t 0<\/em> disables text coloring.<\/p>\n
Direwolf creates a symbolic link in \/tmp\/kisstnc<\/em> to expose the dynamically assigned pseudo-terminal name. This value is read into the variable PTS<\/em>, which is then used by kissattach<\/em> to attach the AX.25 interface (ax0). The kissparms<\/em> command is then used to configure AFSK channel timing parameters.<\/p>\n
Direwolf can be run in user space, provided the user has access to audio devices (audio group). However, some commands require elevated privileges; a simple solution is to enable the SUID bit (chmod u+s<\/em>) on the required executables (direwolf, kissattach, kissparms, axlisten, axcall, etc.).<\/p>\n
Audio Levels<\/h3>\n
Both soundmodem and Direwolf require careful adjustment of audio levels, both for transmission and reception. A first coarse adjustment can be made via the hardware interface, while fine tuning is done using the ALSA mixer (alsamixer<\/em>):<\/p>\n
\"ALSA<\/a><\/p>\n
Transmit adjustment is relatively simple: even without measurement tools it is enough to monitor modulation using another radio. On reception it is useful to rely on Direwolf\u2019s diagnostic output, which indicates whether the audio level is too high or too low. Even on less powerful systems it can be useful to run it temporarily for calibration. It is advisable to disable automatic gain control to obtain more accurate results.<\/p>\n
Once configuration is complete, it is important to save it with alsactl store<\/em>, otherwise it will be lost after reboot.<\/p>\n
To access the Direwolf session: screen -r direwolf<\/em>. To detach while keeping it running: CTRL-A<\/strong> followed by D<\/strong>.<\/p>\n
Modem<\/h3>\n
The AX.25 protocol does not define the type of modem to be used. The most common standard on VHF\/UHF is 1200 baud AFSK, with tones at 1200 and 2200 Hz (derived from Bell 202). This is an outdated and inefficient technology. More advanced alternatives exist, such as 9600 baud G3RUH, originally designed for satellite use but also adopted for terrestrial links, or solutions such as SuperVozelj.<\/p>\n
An alternative approach is the use of more efficient modulation schemes that better exploit the available bandwidth (about 2.2 kHz) with standard equipment. However, in amateur radio usage, speed is not always the priority, except for specific applications such as emergency communications.<\/p>\n
Direwolf also supports FX.25<\/a><\/em>, which introduces forward error correction mechanisms. Soundmodem also includes experimental modes such as Q15X25<\/a><\/em>.<\/p>\n
These are still interesting areas of experimentation: remaining tied to the TNC-2 model is quite limiting today.<\/p>\n
Testing<\/h3>\n
Once levels are adjusted, it is time to test the system. For this purpose, the Test CD<\/a> by WA8LMF is very useful, containing recordings of radio traffic that can be used as a test source. In Linux, the axlisten<\/em> command allows monitoring received traffic, while axcall<\/em> allows establishing a connection with another station and testing the transmit chain.<\/p>\n
At this point, the packet radio layer of the system is operational, and applications can be installed.<\/p>\n
LinFBB<\/h3>\n
F6FBB is a well-known BBS application used since the 1980s. LinFBB is the Linux version, installable via apt-get or from source. Its configuration requires several files; among them, one of the most significant is port.sys<\/em>:<\/p>\n
# FBB7.0.10\r\n#\r\n#Ports TNCs\r\n1 1\r\n#\r\n#Com Interface Adress (Hex) Baud\r\n1 9 0 1200\r\n#\r\n#TNC NbCh Com MultCh Pacln Maxfr NbFwd MxBloc M\/P-Fwd Mode Freq\r\n0 0 0 0 0 0 0 0 00\/01 ---- File-fwd.\r\n1 4 1 ax0 250 7 2 10 30\/05 XUWYL 144.875\r\n#\r\n# End of file.\r\n#<\/pre>\n
LinFBB can be started automatically at system boot via \/etc\/rc.local<\/em>. It is possible to connect locally using xfbbC -c -i <callsign><\/em> (TCP port 3386).<\/p>\n
DxSpider beacon<\/strong><\/em><\/p>\n
On my node there is also an active beacon that displays spots coming from the DXCluster network, in particular from the node dxcluster.i8zse.eu<\/a>. The system waits for commands sent via UI packets (DXCLUSTER HELP or DXCLUSTER <filter>), temporarily enabling transmission of filtered spots.<\/p>\n
The software is available on GitHub<\/a>.<\/p>\n
Link utili<\/div>
\n