Slow (destination) network, or my issue?

Setup Information

********** AllStarLink [ASL] Version Info **********

OS : Debian GNU/Linux 13 (trixie)
OS Kernel : 6.12.88+deb13-amd64

Asterisk : 22.8.2+asl3-3.8.3-1.deb13
ASL [app_rpt] : 3.8.3

Installed ASL packages :

Package Version
============================== ==============================
allmon3 1.8.1-1.deb13
asl3 3.17-1.deb13
asl3-appliance 2.1.0-2.deb13
asl3-asterisk 2:22.8.2+asl3-3.8.3-1.deb13
asl3-asterisk-config 2:22.8.2+asl3-3.8.3-1.deb13
asl3-asterisk-modules 2:22.8.2+asl3-3.8.3-1.deb13
asl3-menu 1.18-1.deb13
asl3-update-nodelist 2.0.0-1.deb13
asl-apt-repos 2.0-1.deb13
cockpit 337-1+deb13u1
cockpit-bridge 337-1+deb13u1
cockpit-networkmanager 337-1+deb13u1
cockpit-packagekit 337-1+deb13u1
cockpit-sosreport 337-1+deb13u1
cockpit-storaged 337-1+deb13u1
cockpit-system 337-1+deb13u1
cockpit-wifimanager 1.2.0-1.deb13
cockpit-ws 337-1+deb13u1
dahdi 1:3.1.0-2.1
dahdi-linux 1:3.4.0-11.asl.deb13

Inquiry

I caught these in my messages.log while I was trying to diagnose why my node was randomly dropping off of another node:

[2026-05-20 08:11:41.570] WARNING[1341] chan_iax2.c: Max retries exceeded to host 172.251.117.162 on IAX2/172.251.117.162:4569-11958 (type = 6, subclass = 1, ts=10, seqno=0)
[2026-05-20 08:11:44.718] NOTICE[2370] app_rpt.c: Reconnect Attempt to 2085 in progress
[2026-05-20 08:11:48.717] NOTICE[1345] chan_iax2.c: Auto-congesting call due to slow response
[2026-05-20 08:12:16.718] WARNING[1345] chan_iax2.c: Max retries exceeded to host 172.251.117.162 on IAX2/172.251.117.162:4569-5086 (type = 6, subclass = 1, ts=18, seqno=0)
[2026-05-20 08:12:19.769] NOTICE[2370] app_rpt.c: Reconnect Attempt to 2085 in progress
[2026-05-20 08:12:23.769] NOTICE[1340] chan_iax2.c: Auto-congesting call due to slow response

Is there a retry I can increase to a non-insane amount, or do I just resort to a 'permanent" connection paradigm?

Carl/K6CRS

[2026-05-20 08:11:48.717] NOTICE[1345] chan_iax2.c: Auto-congesting call due to slow response

This means one of two things:

  1. Your node is not perceived as registered and the remote node is ignoring your connection attempt (as it should).

  2. The remote node has network connectivity issues. As UDP is connectionless, if something's blocking the traffic without sending back the proper ICMP Port Unreachable message or the host is simply not responding, you'll see that.

In either case, a retry or permanent connection isn't going to fix the underlying issue.

My node shows as registered in ASL, so I'm going to reach out to the other node owner. He could just have a ratty internet connection...it's just a Pi in his house.

Thanks.

Carl/K6CRS