2026.09.24 - Package Updates - Beta Channel

AllStarLink
,
1

We continue to release updates to the ASL3 project. With all new packages, we start off sharing the updates with our developers. Then, the packages are moved to the “beta” package channel for those who want to test fixes to their problems or get the “latest and greatest” as quickly as possible. When we believe that the changes are OK for all we push them out to the production channel.

Before opting to install the "beta" (or "devel") packages we ask that you carefully read Beta Testing about the caveats and potential pitfalls of beta packages.

The following ASL3 packages are now available from the "beta" channel. The changes include:

asl3-asterisk 22.10.1+asl3-3.10.6-1

  • app_rpt

    • app_rpt: Prevent echolink and tlb retry loop without call PR #1171
    • app_rpt: Stop permanent links from reconnecting after ilink 11 PR #1217
    • app_rpt.c: Cleanup bridges on shutdown PR #1219
    • voter.c: Improve Code Readability PR #1222
    • app_rpt: Address incorrect unlock and case switch flow in rpt_tele_thread() PR #1224
    • app_rpt.c: detach audiohook before hanging up on the channel PR #1225
    • app_rpt.c: Check for channel hangups and ast_write errors to exit the link process PR #1226
    • chan_voter.c: Add documentation to high pass and de-emphasis filters PR #1228
    • app_rpt.c: Address audiohook locking hang. No need to detach an audiohook after hanging up PR #1229
    • chan_voter.c: Add comments about sending ADPCM frames PR #1230
    • general: Add license.md for GPLv2 PR #1231
    • app_rpt.c: wait on chan, not rxchannel in rpt_exec() thread PR #1232
    • app_rpt.c: Add reference protection around V option PR #1233
    • app_rpt.c: Create macro IS_NODE_EXTEN() PR #1235
    • app_rpt: Flush !!DISCONNECT!! before softhangup PR #1237
    • app_rpt: "connpgm" and "discpgm" program strings should allow arguments PR #1239
    • app_rpt.c: audiohook_attatch and remove from the correct channel PR #1241
    • app_rpt.c: Make sure audiohook is running before adding frames PR #1246
    • Reject invalid configuration during reload and channel startup PR #1247
    • app_rpt: correct DNS node domain configuration handling PR #1250
    • app_rpt: fix __ao2_ref SIGSEGV in mute detection PR #1251
    • chan_tlb.c: Correct naming for TLB PR #1255
    • app_rpt.c: optimize process_link_channel() if statement PR #1256
    • app_rpt: Replace ast_audiohook with custom mixer to address whisper frame leak PR #1260
    • app_rpt: Query remote mute on conference pchannel PR #1262
    • app_rpt.c: Fix typos, address mutex_destroy() PR #1263

These packages will be available for the next 1-2 weeks. If we do not hear of any issues or problems with the updates we will promote them to the production/main channel.

Again, please see Beta Testing for information on how to use package software and the caveats and warnings about beta test software.

Sincerely,
AllStarLink

2

Updated to 2026.09.24 packages a few days ago. The Exceptionally long voice queue length issue still persists. Had three nodes crash this morning.

[2026-09-27 08:46:32.726] WARNING[1847][C-0000018f] chan_iax2.c: Resyncing the jb. last_delay -1, this delay -65520, threshold 1002, new offset -90
[2026-09-27 08:46:40.393] WARNING[353875][C-0000022e] channel.c: Exceptionally long voice queue length (97 voice / 97 total) queuing to Announcer/IAXLink-0000233e;1
[2026-09-27 08:46:41.673] WARNING[353875][C-0000022e] channel.c: Exceptionally long voice queue length (97 voice / 97 total) queuing to Announcer/IAXLink-0000233e;1
[2026-09-27 08:46:42.953] WARNING[353875][C-0000022e] channel.c: Exceptionally long voice queue length (97 voice / 97 total) queuing to Announcer/IAXLink-0000233e;1
[2026-09-27 08:46:44.233] WARNING[353875][C-0000022e] channel.c: Exceptionally long voice queue length (97 voice / 97 total) queuing to Announcer/IAXLink-0000233e;1

3

Is this on a pi or an x86_64 machine?

4

Happening on both. Main hub node, which has been having this occur every other day, is on an x86_64 machine, but I have had it also occur since the update, on Pi5 nodes.

5

It's not specific to this beta release. This has been going on for awhile and we're trying to nail it. Unfortunately it's been very very difficult to track down the root cause.

6

on the x86_64 hub machine I found the best solution is to change the kernel to the rt kernel, that should take care of the problem there. If you could test that and report back on the hub would be very appreciated.

7

Not familiar with the rt kernel. What is it, and what is different about it?

8

sudo apt install linux-image-rt-amd64 linux-headers-rt-amd64 -y

Installing a real-time (RT) kernel on Debian—specifically using the PREEMPT_RT patch—gives your system deterministic response times, which is essential for low-latency tasks like audio processing, robotics, and industrial automation.

9

Only install the Linux "RT scheduler" kernels if you're on real hardware. It won't help on virtual machines / VPSs and will, in fact, make other things worse. Also, this doesn't "fix" the problem, it's just masking one of the symptoms.

10

@K2CB - Do you have Echolink users connected when these crashes occur?

11

Yes.

FWIW, I do notice Echolink events in the log usually around the time of failure. For example:

[2026-09-27 08:26:17.142] WARNING[1845][C-00000015] chan_iax2.c: Resyncing the jb. last_delay 0, this delay -1474, threshold 1022, new offset 425
[2026-09-27 08:26:58.009] ERROR[1927] chan_echolink.c: Cannot find database entry for IP address 99.144.75.209, Callsign N2RST.
[2026-09-27 08:26:58.010] ERROR[1927] chan_echolink.c: Cannot find database entry for IP address 99.144.75.209, Callsign N2RST.
[2026-09-27 08:30:49.348] WARNING[1840][C-00000015] chan_iax2.c: Resyncing the jb. last_delay 31, this delay 2281, threshold 1022, new offset -1856

12

Good point. My hub node has a pattern of crashing right before net times, and this is usually around the time Echolink users begin to connect.

13

Running on a VMS, so this would not be an option.

14

If possible, setting the debug level on app_rpt to 4 or higher, may help us figure out what is going on around one of these crashes. It seems to be some "non normal" path that is hiding from us....

15

I have now set it to level 4. I'll keep an eye on the log file.

Thank you.

16

Somewhat recently, ASL3 was installed on X64 hardware for a local repeater. I unfortunately don't have access to the machine or it's logs, but anecdotally, I can say that it tends to stop accepting connections around the time a few echolink users connect, and requires Asterisk to be restarted.

I know that isn't much to go on, as I have (not recently) seen the exceptionally long queue messages on systems not connected to echolink. I'm going to try and get access to that system soon, so I can look at it's debug logs when this happens, which seems to be every couple of days.

···