Dire Wolf turns a soundcard into an AX.25 TNC and APRS decoder
Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md
At a glance
- What is it?
- Dire Wolf is a C program that turns a radio's audio into AX.25 frames and APRS packets, running digipeater, IGate, tracker or APRStt gateway duties in one process. The error correction paths are what to check first, because FX.25 and IL2P cannot interoperate.
- Who is it for?
- Adopt Dire Wolf if you already run amateur radio and want digipeater, IGate, tracker or APRStt duty from one process on Linux, a Raspberry Pi or Windows. Leave it alone if every node you must reach is a hardware TNC, and do not switch to IL2P until both ends of the path support it, because IL2P is not AX.25 compatible.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Soundcard decoding replaces the 1980s hardware TNC
Ham packet radio used to need a Terminal Node Controller: a separate box holding a dedicated modem chip, wired to the radio through a serial port, costing around $200 and built from 1980s parts. Dire Wolf takes that box out of the signal path. Audio from a radio enters through the computer's soundcard interface, digital signal processing recovers AX.25 frames, and the APRS payload is decoded from those frames in software.
The reader here is a licensed amateur radio operator who already owns a transceiver and wants to watch or serve the APRS network without buying a hardware TNC. A Raspberry Pi with a USB audio adapter and a VHF radio is enough hardware for a fixed site digipeater or IGate.
One contradiction sits in the project's own framing. The description reads "Decoded Information from Radio Emissions for Windows Or Linux Fans", while the platform list names Mac OSX next to Windows and Linux (PC/laptop, Raspberry Pi, etc.). The heading was never updated to match that bullet, so the list is the fuller statement.
The Makefile default target prints instructions instead of building
The default branch comes down as source plus a Makefile whose first target compiles nothing. Running make prints a notice that "The build procedure has changed in version 1.6." and then the steps to type by hand, so the first build is manual from the start. The default branch is master, and an optional branch switch reaches the development line before anything is compiled.
Start where the Makefile starts:
cd ~
git clone https://www.github.com/wb2osz/direwolf
cd direwolf
mkdir build && cd build
cmake ..
make -j4That out-of-source layout is one of the two new steps named in the notice, and the cmake call is the other. Installation adds two targets:
sudo make install
make install-confFor the development line, the switch comes before the build directory:
git checkout devBuilding is not the same as having a station on the air. The same Makefile says additional applications and libraries are needed depending on the operating system, and packaging directories such as systemd/ and debian/ sit at the top level of the tree without any instruction naming them. For redistribution, the code is under GPL-2.0 with a LICENSE file beside CMakeLists.txt, so a modified binary handed to another operator travels with the same terms.
AX.25, FX.25 and the IL2P compatibility gap
Three link layers live inside Dire Wolf, and they do not mix. Plain AX.25 is the baseline every other station on the channel already speaks. FX.25 wraps that traffic in Forward Error Correction, adding redundancy so a frame can survive a fade that destroys the uncorrected copy, and the project calls it completely compatible with existing systems. That protection only pays off when both ends speak FX.25, so a lone station on the air gains nothing.
Version 1.7 added IL2P, a different error correction method with less overhead, developed first for satellites and now common on HF. It is not compatible with AX.25. That one constraint decides who hears whom: an IL2P node ignores plain AX.25 frames and an AX.25 node never decodes IL2P, so a digipeater or IGate can join only one of the two sides. Planning a relay means choosing the protocol before choosing the interface.
Connected mode is a third entry point. AX.25 v2.2 gives the TNC automatic retries and in-order delivery of connected data, which fits chat and file transfer rather than the single-frame APRS packets that dominate local repeater traffic.
Four station roles running on one AX.25 stack
One process covers four jobs a hardware TNC never handled alone. A tracker takes position from a GPS receiver and turns it into periodic transmissions, so a vehicle shows up on the network map. A digipeater listens, judges whether a frame deserves repeating, and retransmits it, with cross band repeating and filtering rules that limit what leaves the site. An IGate passes selected content between the radio network and the Internet, joining two disjoint radio networks that cannot hear each other.
The fourth is APRStt, and it is the strangest of the set. Someone holding nothing but a handheld radio that can send DTMF tones can enter information into the global APRS data network: Dire Wolf decodes the tones, builds the packet, and answers in Morse code or synthesized speech. Most hams own a handheld but not a portable data rig, and that is the gap this mode fills.
Beyond position, a beaconing, tracker and telemetry toolkit exists for building your own transmissions. Separate from all of that sits the Ham Radio of Things proposal, a standardized method for letting different Internet of Things systems talk over ham radio, documented in its own repository rather than folded into Dire Wolf.
KISS and AGW turn Dire Wolf into a virtual TNC
The same decoder can hand packets to other programs instead of running alone. Two interfaces do that work: KISS, over TCP/IP, a serial port or Bluetooth, and the AGW network interface over TCP/IP. Both present Dire Wolf to client software as if a TNC were attached to the radio.
That matters because the named clients run well past mapping software. APRSIS32, Xastir, APRS-TW, YAAC, PinPoint APRS, UI-View32, UISS, Linux AX25 and SARTrack sit alongside Winlink Express, BPQ32, Outpost PM, Packet Commander and Packet Compressed Sensing Imaging. A mapping client and a terminal program reach one modem through different interfaces, so a station can be built around whatever the operator already runs.
One consequence deserves attention. Every receive and transmit decision, including the modem rate and the filter rules, happens inside Dire Wolf while the client keeps its own view of the link. The README does not document a rollback procedure if a configuration change turns out to be wrong, and it does not describe how that split can be audited.
Modem rates and the three soundcard ceiling
Six modem modes are listed, and the rate follows the band. 300 bps AFSK covers HF, 1200 bps AFSK is the common VHF and UHF mode, 2400 and 4800 bps PSK sit in between, and 9600 bps GMSK/G3RUH is the fast end. AIS reception and EAS SAME reception sit in that same list, so one box can serve maritime tracking and weather alerts alongside packet traffic.
Every signal arrives through the computer's soundcard, which is why the supported interface list is a list of audio adapters rather than radio interfaces: DRAWS, UDRC, SignaLink USB, DMK URI, RB-USB RIM, RA-35, DINAH and SHARI among them. Software defined radios work too, with gqrx, rtl_fm and SDR# named as compatible.
The ceiling is stated and small: concurrent operation with up to 3 soundcards and 6 radios. A site wanting two radios on one soundcard sits inside that limit; a contest station running six separate receivers plus a spare does not. DTMF decoding and encoding feed APRStt, and a speech synthesizer interface with a Morse code generator carries the replies.
Gaps a first operator hits before the first packet
After make install-conf, nothing on the front page names a config key, a command line flag, or a port for any of the four station roles. The top level conf/ and man/ directories are the only pointers to the configuration format, so the first transmitted packet depends on the doc directory rather than on the README. That documentation is split too: stable pages sit on the master branch, development pages on dev, and additional topics live in a separate direwolf-doc repository.
The upgrade path is short and thin at the same time. Three 2025 builds are listed with dates: 1.8-beta1 on 2025-10-03, 1.8 on 2025-10-29 and 1.8.1 on 2025-11-13, with CHANGES.md at the top level for what shifted between them. The repository is not archived and the last push was on 2026-09-22.
Harder gaps sit in the operation. The README does not document rollback, and it names no per-platform dependency list, so a failed install is debugged by reading CHANGES.md and the doc pages. APRStt carries a condition the software cannot supply either: the far end needs a handheld that can send DTMF tones.
Dire Wolf against hardware TNCs and first generation soundcard modems
The comparison offered by the project is its own, and it is specific. Dire Wolf decodes over 1000 error-free frames from Track 2 of the WA8LMF TNC Test CD, a disc the repository hosts, against hardware TNCs and first generation soundcard modems. Read closely, that number covers one track of one test disc in a mode that still speaks AX.25, and the same front page states that IL2P is not AX.25 compatible. A station that moves to IL2P buys lower overhead and loses every node the 1000 frame claim was measured against.
The difference in approach is where the work happens. A hardware TNC spends a modem chip on demodulation, connects over a serial port, and stays fixed in what it can do. Dire Wolf spends CPU on the same job, which is why one process can also transmit position, digipeat, gate to the Internet and decode DTMF, and why six modem modes from 300 bps AFSK to 9600 bps GMSK/G3RUH live in one binary. The price is the protocol split described above: reach stops at whichever mode the operator configures.
Two alternatives face the same decision without these numbers behind them. Other soundcard modems decode AX.25 but ship fewer station roles, and no competing software package is named anywhere, so no software comparison exists to check. Hardware TNCs remain the safer pick for a station that must talk to anything, because AX.25 compatibility is what they are.
Editorial conclusion
Adopt Dire Wolf if you already run amateur radio and want digipeater, IGate, tracker or APRStt duty from one process on Linux, a Raspberry Pi or Windows. Leave it alone if every node you must reach is a hardware TNC, and do not switch to IL2P until both ends of the path support it, because IL2P is not AX.25 compatible. Before buying an interface adapter, read the doc directory in the cloned tree, build out of source the way the Makefile prints it, and confirm which modem rate your radio actually passes to the soundcard.
Frequently asked questions
Does Dire Wolf replace a hardware TNC, or does it still need one?
It replaces the hardware TNC: audio from the radio enters through the computer's soundcard interface and digital signal processing does the demodulation. You still need the radio itself and a compatible audio interface such as DRAWS, UDRC or SignaLink USB.
What is the difference between FX.25 and IL2P in Dire Wolf?
FX.25 adds Forward Error Correction to AX.25 and is described as completely compatible with existing systems, but the protection only helps when both ends speak it. IL2P arrived in version 1.7, carries less overhead and is not compatible with AX.25, so the two cannot hear each other.
Which operating systems does Dire Wolf run on?
Windows, Linux (PC/laptop, Raspberry Pi, etc.) and Mac OSX are all listed as supported. The project description headline still names Windows Or Linux fans, so the platform bullet is the fuller statement.
Can Dire Wolf be used with other packet radio programs?
Yes, through KISS over TCP/IP, a serial port or Bluetooth, and through the AGW network interface over TCP/IP. Named client software includes Xastir, APRSIS32, BPQ32 and Winlink Express, which treat it as a virtual TNC.
How many radios can one Dire Wolf station handle at once?
Concurrent operation with up to 3 soundcards and 6 radios is the stated limit. Modem rates from 300 bps AFSK for HF through 9600 bps GMSK/G3RUH run in the same software, along with AIS and EAS SAME reception.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/wb2osz-direwolf)