I finally got AllStar installed,
HamVoIP Firmware - RPi2-3-4 Version 1.7-03
HamVOip AllStar - Asterik 1.4.23-pre-voip-V1.7.1-04
I can dial everything locally, and I get good tones, etc.
BUT I have AT&T and I’m having issues with their firewall/router, I think. I have port 4569 port forwarded to the RPI4
As per attached pic, I can dial out, but I never connect to said node.
Any other suggestions?
Hi Rod. I don’t see your attachment. I had a similar issue with an AT&T wireless hotspot from netgear. I was not able to get it resolved as there are too many NATs (network address translations) between your node and the outside world. Someone with better networking skills than I may be able to offer some suggestions similar to these from the hamvoip site https://hamvoip.org/howto/Configuration_of_a_Reverse_Tunnel.pdf
hope this helps - I never got around to trying it…
That’s weird. I know I attached it.
Thank you for replying. Seems what I did have setup is working. I was just attempting to dialing a node that was offline
well since you did have it working, what was the trick? was it a wireless AT&T or like a home connection? If you figured out the wireless NAT, I’d love to know.
wifi is dhcp, could not get a static IP for it.
Port forwardng , i used this as a template
https://www.att.com/support/article/u-verse-high-speed-internet/KM1215101
It has to do with convincing debian to use IPv4 instead of IPv6 and using an IAX registration instead of http. I can now make outgoing connections just fine using the htspot but incoming still won't work because of the CGNAT. Here's the session synopsis from ChatGPT.
AllStarLink IAX Registration: IPv6 Timeout and IPv4 Preference
Workaround
Field report: November 1, 2026 | Node: 419736 (HT-Portable-Node) | Platform: ASL3 on Debian | Network:
T-Mobile cellular hotspot, carrier-grade NAT (CGNAT)
Summary
A portable ASL3 node configured for IAX registration timed out when Asterisk resolved the AllStarLink registration hostname to an IPv6 destination. Temporarily substituting a DNS-resolved IPv4 server address immediately produced a successful registration, and the node successfully initiated an outbound AllStarLink connection. The hostname was then restored and Debian address-selection precedence adjusted to prefer IPv4. Following a reboot, registration and outbound linking both succeeded. This is a single field observation, not a claim of general IPv6 incompatibility or long-term reliability.
Objective and environment
Use the AllStarLink documentation procedure "Using IAX Registration Instead of HTTP Registration" for a portable node operating behind T-Mobile CGNAT. The operational requirement was successful IAX registration and outbound-initiated node connections; unsolicited inbound connections were not required or tested.
Documentation: IAX-Based Registration - AllStarLink Manual
Observed failure
DNS returned both IPv4 A and IPv6 AAAA records for register.allstarlink.org. The Asterisk CLI showed an IPv6 registration destination and a timeout:
HT-Portable-Node*CLI> iax2 show registry
Host: [2607:7700:0:57::3415:a9c5]:4569
Username: 419736
Perceived:
Refresh: 60
State: Timeout
This established that Asterisk was attempting registration via IPv6. It did not independently establish why the IPv6 attempt timed out.
Controlled IPv4 test
A DNS-resolved IPv4 address for the same registration hostname (52.21.169.197) was temporarily used as the destination in the existing register => entry in /etc/asterisk/iax.conf, preserving the existing credentials. After restarting Asterisk, the registry showed:
Host: 52.21.169.197:4569
Username: 419736
Perceived: 172.56.7.109:62158
Refresh: 180
State: Registered
The perceived address and translated UDP source port were consistent with NAT traversal. An outbound connection to another AllStarLink node was also successful. This strongly implicated IPv6 destination selection in the earlier registration failure.
Persistent configuration change
The original registration hostname was restored in iax.conf to avoid reliance on a fixed server IP. The following address-selection precedence entry was added or uncommented in /etc/gai.conf:
precedence ::ffff:0:0/96 100
This requests preference for IPv4-mapped addresses in applications that follow the system address-selection policy; it does not disable IPv6. After a full reboot, IAX registration succeeded and the node again initiated an outbound connection successfully. The exact post-reboot registration destination was not recorded, so the evidence supports the practical workaround but does not independently confirm which address family Asterisk used after reboot.
Verification and limitations
Verified: dual-stack DNS answers; initial IPv6 registration timeout; successful registration using a temporary IPv4 destination; successful outbound linking; successful registration and outbound linking after restoring the hostname, changing gai.conf, and rebooting.
Not verified: repeated reconnects across hotspot IP changes; long-term stability; inbound initiation through CGNAT; whether the gai.conf policy is consistently honored across all Asterisk/ASL3 builds; root cause of the IPv6 timeout.
Suggested wiki troubleshooting note
If an ASL3 node using IAX registration shows Timeout and iax2 show registry displays a bracketed IPv6
registration host, check both A and AAAA DNS results. As a diagnostic, temporarily test a current IPv4 address resolved for the registration hostname (do not treat it as a permanent endpoint). If registration succeeds, restore the hostname and consider the IPv4 precedence entry in /etc/gai.conf, followed by a reboot and another registry/linking test. Document that this is an observed workaround, not a universal fix.
The issue with your ASL3 node registering using an IPv6 address should now be fixed. For a short time we had inadvertently added an AAAA (IPv6) record for the
"register.allstarlink.org" servers when only the A (IPv4) record should have been present.
Changes to your /etc/gai.conf file should no longer be needed.
Update : It looks like I misunderstood some internal communications and only A records should have been present for "register.allstarlink.org". Please see @N8EI's question below.
The host register.allstarlink.org should never have returned an AAAA record. What's the output of dig +short register.allstarlink.org aaaa reporting on your Linux OS?