Asymmetric/stale connection state with remote repeater

Allmon
1

After converting my hub node 573880 to ASL3, I am seeing an asymmetric/stale connection state with remote repeater node 573902.

From 573902:
rpt lstats 573902 shows 573880 OUT ESTABLISHED for 69+ hours.
rpt stats 573902 says nodes currently connected to us: 573880, NW4A.

From 573880 hub:
rpt lstats 573880 does not show 573902 at all.
Allmon3/Grafana also show 573902 not connected/down.

So the remote node believes it is linked to the hub, but the ASL3 hub does not list the remote node as connected. This started after moving the hub to ASL3. Is this related to the recent ASL3 loopback protection / stale topology state issue where ASL3 thinks nodes are still connected after disconnect/reconnect events?

What is the recommended way to clear this state without restarting Asterisk, and is there a known fix or setting to prevent it?

2

When this happens, are there other things connected to 573902? The other thread is about "one hop away" problems where the one hub believes something two hops away from it is/was already connected.

Also, what is 573902 running? ASL3 or something else?

Is there a possibility you can do full package captures of the IAX2 traffic? I suspect that telemetry is being corrupted, omitted, or not properly being generated by some clients.

3

573902 has been running running hamvoip for years. Never seen this issue until I upgraded the HUB to ASL3. I was connected to 573902 through DV-Switch to monitor .

4

If you replace HamVOIP with ASL3 for 573902 does the issue persist?

5

To add to this:

Specifically with HamVoIP nodes that don't have radios attached, I.E. that are performing the roll of a hub or just a jump point for IAX connections (DAHDI/PSEUDO), by default, a lot of telemetry is blocked upstream from the node. There is a switch that can be added in such cases to the node's stanza in rpt.conf, should you not want that behavior. Keep in mind that the links list is still truncated after a while, and I don't remember how much that while is.
telemenabled=255

The behavior of telemetry is essentially the same as adding telemenabled=255 if there is a sound fob attached. Changing this switch just stops it from turning all that stuff off when there is no sound fob.

So, if that node is switched to ASL3, the problem shouldn't exist anymore, in theory, because it doesn't do anything like that.

I have found that telemetry is still a bit odd with telemenabled=255 and/or a sound fob connected with HamVoIP nodes, so there's that.