Exceptionally long voice queue length error message causing node to fail

AllStarLink
1

For the past few weeks, my hub node is failing. Symptoms are:

  1. Allmon show other previously connected nodes now in a "CONNECTING" status
  2. No new nodes can connect.
  3. Numerous error messages appear in the messages.log file:

[2026-07-26 00:08:52.291] Asterisk 22.9.0+asl3-3.9.3-1.deb13 built by builder @ allstarlink.org on a x86_64 running Linux on 2026-05-28 18:41:49 UTC
[2026-07-26 00:08:52.792] WARNING[56266][C-00000093] channel.c: Exceptionally long voice queue length (97 voice / 99 total) queuing to Announcer/IAXLink-0000125e;1
[2026-07-26 00:08:53.092] WARNING[15613][C-0000004d] channel.c: Exceptionally long voice queue length (97 voice / 99 total) queuing to Announcer/IAXLink-00000351;1
[2026-07-26 00:08:54.072] WARNING[56266][C-00000093] channel.c: Exceptionally long voice queue length (97 voice / 99 total) queuing to Announcer/IAXLink-0000125e;1
[2026-07-26 00:08:54.372] WARNING[15613][C-0000004d] channel.c: Exceptionally long voice queue length (97 voice / 99 total) queuing to Announcer/IAXLink-00000351;1
[

If I reboot the node, sometimes it will be fine for a day, other times only a few hours.
Any suggestions as to what may be causing this? I have not made any configuration changes in a long time. This seemed to start after updating to the latest version.

Current version info:
OS : Debian GNU/Linux 13 (trixie)
│ OS Kernel : 6.12.96+deb13-amd64
│
│ Asterisk : 22.9.0+asl3-3.9.3-1.deb13
│ ASL [app_rpt] : 3.9.3
│
│ Installed ASL packages :
│
│ Package Version
│ ============================== ==============================
│ allmon3 1.9.1-1.deb13
│ asl3 3.18.2-2.deb13
│ asl3-asterisk 2:22.9.0+asl3-3.9.3-1.deb13
│ asl3-asterisk-config 2:22.9.0+asl3-3.9.3-1.deb13
│ asl3-asterisk-modules 2:22.9.0+asl3-3.9.3-1.deb13
│ asl3-menu 1.18-1.deb13
│

Eric
K2CB

2

This is a known bug caused by network conditions relating to either misbehaving peer clients or internet port scans. We're hopeful the next release will fix this.

3

It "should" be harmless assuming it's the same issue. When an outbound connection has failed the redial function can take a long time looking up the DNS name which causes these queue errors. Once the DNS is back and/or internet is stable it should just continue to work.
I have something "cooked up" to handle the frames in this condition but it should not be a problem.

That said, there is another bug I've been chasing where we have long queues on the repeater channels. Still hunting for that elusive one, so it happens PLEASE share logs.

4

Let me know which logs specifically, and I will be happy to post them.

Thank you.