Package: direwolf
Version: 1.8~beta1+dfsg-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: [email protected]
Hello,
after the end of an AGWPE session between a client and direwolf,
direwolf crashes with a segfault. Following is a minimal
testcase to be run without having a radio connected:
$ sudo apt install direwolf pat
$ cat > /tmp/direwolf.conf <<EOF
ADEVICE pulse
CHANNEL 0
MYCALL N0CALL
MODEM 1200
AGWPORT 8000
FX25TX 1
EOF
$ cat >/tmp/pat-config.json <<EOF
{
"mycall": "N0CALL",
"secure_login_password": "verysecret",
"agwpe": {
"addr": "localhost:8000",
"radio_port": 0
}
}
EOF
$ direwolf -c /tmp/direwolf.conf -p
Open a new shell and run:
$ pat-winlink --config /tmp/pat-config.json connect "ax25+agwpe:///DB0ABC"
This results in:
-----8<----------8<----------8<----------8<----------8<----------8<-----
Dire Wolf version 1.8 (Oct 15 2025) BETA TEST 1
Includes optional support for: gpsd hamlib cm108-ptt
Reading config file /tmp/direwolf.conf
Audio device for both receive and transmit: pulse (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate, Tx FX.25.
Note: PTT not configured for channel 0. (OK if using VOX.)
When using VOX, ensure that it adds very little delay (e.g. 10-20) milliseconds
between the time that transmit audio ends and PTT is deactivated.
For example, if using a SignaLink USB, turn the DLY control all the
way counter clockwise.
Using VOX built in to the radio is a VERY BAD idea. This is intended
for voice operation, with gaps in the sound, and typically has a delay of about
a
half second between the time the audio stops and the transmitter is turned off.
When using APRS your transmiter will be sending a quiet carrier for
about a half second after your packet ends. This may interfere with the
the next station to transmit. This is being inconsiderate.
If you are trying to use VOX with connected mode packet, expect
frustration and disappointment. Connected mode involves rapid responses
which you will probably miss because your transmitter is still on when
the response is being transmitted.
Read the User Guide 'Transmit Timing' section for more details.
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Virtual KISS TNC is available on /dev/pts/7
Created symlink /tmp/kisstnc -> /dev/pts/7
Attached to AGW client application 0...
Ready to accept AGW client application 1 on port 8000 ...
Attempting connect to DB0ABC ...
[0L] N0CALL>DB0ABC:(SABME cmd, p=1)
[0L] N0CALL>DB0ABC:(SABME cmd, p=1)
[0L] N0CALL>DB0ABC:(SABME cmd, p=1)
[0L] N0CALL>DB0ABC:(SABM cmd, p=1)
[0L] N0CALL>DB0ABC:(SABM cmd, p=1)
[0L] N0CALL>DB0ABC:(SABM cmd, p=1)
[0L] N0CALL>DB0ABC:(SABM cmd, p=1)
[0L] N0CALL>DB0ABC:(SABM cmd, p=1)
[0L] N0CALL>DB0ABC:(SABM cmd, p=1)
[0L] N0CALL>DB0ABC:(SABM cmd, p=1)
Failed to connect to DB0ABC after 10 tries.
Segmentation fault direwolf -c /tmp/direwolf.conf -p
-----8<----------8<----------8<----------8<----------8<----------8<-----
The problem also exists in the upstream 1.8 release and in the
current upstream 1.9 dev branch, but not in the 1.7 release.
Git bisecting points to the following upstream commit as the
change that introduced the segfault:
-----8<----------8<----------8<----------8<----------8<----------8<-----
commit c317511f7a5159b2611dfc0fc6a7b883a7c83338
Author: Martin Cooper <[email protected]>
Date: Thu Sep 18 17:33:47 2025 -0700
Clean up AGWPE connection data upon termination
Per-connection data for an AGWPE connection was being cleaned up only
when the client itself went away, rather than when each connection
was terminated. This led to reuse of stale state machine instances,
which in turn led to incorrect connection attempts and statistics.
The following changes have been made to address this:
* Per-connection cleanup code from dl_client_cleanup has been moved
to a new function, dl_connection_cleanup. dl_client_cleanup now
calls this new function from within its existing loop, walking
though all connections for the client being cleaned up.
* A new function, dl_connection_terminated, encapsulates the removal
of a single state machine instance from the list and the cleanup of
that connection instance, calling dl_connection_cleanup for the
latter.
* Everywhere that server_link_terminated is being called, a new call
to dl_connection_terminated has been added nearby, to ensure the
connection is cleaned up. The call is "nearby" because invocations
of server_link_terminated differ in their surrounding calls to
other timer and state functions, and the order of those calls, so
simply wrapping server_link_terminated is not appropriate.
Many, but not all, existing calls to server_link_terminated have
nearby calls to set the state machine state to disconnected. While
this is also done in dl_connection_cleanup, the existing calls have
been left to minimize disruption. (There is no real cost associated
with changing state from disconnected to disconnected.)
These changes have been tested in as many situations as possible, with
Direwolf started using '-d ac' to watch debug output for both AGWPE
and connection / state machine related activity.
Fixes #534, Fixes #535
-----8<----------8<----------8<----------8<----------8<----------8<-----
Kind regards,
Karsten
P.S.: I have already sent this bug report to upstream.
-- System Information:
Debian Release: forky/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.17.6+deb14-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages direwolf depends on:
ii adduser 3.153
ii libasound2t64 1.2.14-2
ii libc6 2.41-12
ii libgps30t64 3.25-5
ii libhamlib4t64 4.6.5-5
ii libudev1 258.1-2
direwolf recommends no packages.
Versions of packages direwolf suggests:
ii gpsd 3.25-5
ii python3 3.13.7-1
-- no debconf information
