I recently set up a Clear Alpha from Node Ventures (node #58935). While it initially worked on my home LAN, it only intermittently works with other All-Star nodes when switching between my home network and my mobile AT&T hotspot.
What will occur is that when I try to connect to various All-Star nodes, it will attempt to establish a connection and then fail as other nodes see a different WAN IP than what is registered with All-Star’s DNS.
It would appear that when my Comcast WAN IP changes on the node to the AT&T WAN IP, the All-Star DNS servers are not updating with my new WAN IP. I’ve let the node sit for several hours multiple times, and DNS does not appear to update. I’ve also confirmed neither ISP is blocking port 4569.
Comcast WAN IP: 174.162.##.###
AT&T WAN IP: 166.199.##.###
Being new to All-Star, I’m curious if I need to add a proxy IP address to my All-Star server, or if there’s a way to force an update to the All-Star DNS servers when my node’s WAN IP changes? Or perhaps I need to update my All-Star registration?
I’ve searched through the forums, but not found anything specific to my question yet. Any help in going in the right direction would be appreciated. Thanks!
To add to Mike’s suggestions, you could try running the Asterisk console (sudo asterisk -rvvv) and looking in /var/log/syslog to see if register and stats packets are being sent to ASL and if there are any errors. Beyond that I believe ClearNodes run HamVOIP so you may need to inquire with Node-Ventures and/or HamVOIP.
Look at AT&T. They give out 2 ip addresses for their hot spots. I ran into this problem before. From what I recall one is for standard internet and one is for secure stuff. What happens is when your node registers Allstar sees one of the ip adresses and when you try to connect to someone they see the other ip address and can not authenticate because the ip is different then the one Allstar tells them to look for. AT&T is the only ISP that does this as far as I know. That is why it works fine on your home network. Read this post. Make sure you read the reply from ‘centro777’ … https://www.reddit.com/r/ATT/comments/6aeejw/hotspot_multiple_external_ips/
Another thing… curious… are you using the new 2.0 version? IAX2 should work fine on AT&T with IAX but the new versions of Allstar software are using http to register. So if the http is really https and your IAX is trying to connect using the old way that would explain it. To fix it simply tell Allstar to register the old way with IAX. Look at their docs toward the bottom for the explanation about http… ASL 2.0 Documentation - AllStarLink Wiki
I’ve looked at firewall issues, but after working with local repeater owners, the issues arise when my public WAN IP changes and repeaters think I’m spoofing my IP address. This is because the WAN IP with my All-Star registration isn’t updating. Not seeing any blocked traffic on my firewall so far.
Nobody thinks you are spoofing.
It is a simple and very direct forward IAX security.
When you register, your ip and port are recorded and piped to a file that is shared to all registered users.
When you connect attempt, the intended connectee station looks in the file for a match.
Only if it is found as a match is it allowed.
By the same token, when you attempt to connect, it looks in the same file for the ip and port info to make the connection.
So a rapidly changing IP is to fast for the network to update.
I say that so you for sure have a better understanding for troubleshooting.
The files are updated and broadcast to all registered nodes every 10-15 minutes or so.
/var/lib/asterisk/rpt_extnodes
Not knowing if there is any difference with hamvoip, know it works something similar.
So, if all is as you say it is and if you want some ideas for a fix, I would say 2 avenues to look would be dynamic-DNS or forcing a update to your registration sooner than it is. Or perhaps a script to look for changes and do an update.
I have to say, it seems a bit unusual for a IP to be updated every 10 min. That could be harsh for a lot of software. One other idea in the case they are doing something on purpose to VOIP streams is to change the iax port number to something out of the ordinary like 8115
To clarify, I didn’t mean repeater owners (or actual humans) think I’m spoofing IP addresses. As an IT professional, I know how DNS works. I’ve worked with fellow IT professionals to see error logs on other nodes, and the issue is that those nodes block my connection because they believe my node as spoofing the IP (when in reality, the DNS hasn’t updated yet).
Specifically, the issue is that the DNS all-star servers are not updating DNS properly, from what I can troubleshoot. Even after hours of being on the same WAN IP, All-Star DNS servers still do not update. It could be an issue on the client side, or it could be an issue on the server side.
Regarding how frequently IP’s are updated (that is, how fast DHCP allocations are renewed), that depends entirely on the organization’s policies. For some, it may be a week. For others, it may be under 30 minutes. I don’t know how fast All-Star updates, but it sounds like every 10-15 minutes from what you’re saying?
That’s a good thought about IAX port numbers possibly being different, depending on how various repeaters (i.e., nodes, etc.) are set up. I’ll circle back with some of the local ones in my area.
Specifically what I’m not familiar with the All-Star system (or HamVoip) is how to force an update to the registration to validate that DNS recognizes the new DHCP allocation.
I only use my nodes at home so haven’t had to deal with changing IPs, but I’d think this is such a common use case that there would already be a bunch of posts, articles, wiki pages, etc. on how to do it. Without having done such a search though some guesses would be (a) try a different cell carrier, I think T-Mobile and Verizon can provide static IPs, (b) DDNS might work if ASL can take a url (eg. 56789.ddns.com) instead of an IP but I have no idea if they support that?, (c) a cloud VM / proxy server that forwards registration packets to/from your DDNS IP, (d) Or just set up a node on a cloud VM and use that as your main node, then permanently connect from it to your portable node. Just some ideas. I’m sure 100’s of people have already solved this issue though so I look forward to see what solves it for you.
Collin,
At first I did not understand that you are ‘mobile on cellular’ with this issue. Yes I got mobile hotspot, but I did not see you were ‘mobile’ in the process.
if you are operating mobile from hotspot or tethered device, your information can change to rapidly for use with app_rpt/asl. This changes drastically when you are near cellular districts, or more commonly known as the ‘old ma bell districts’. But easily changes from tower to tower. Or at least past a string of towers on the same backbone.
And yes you can have a changing IP sitting stationary as well, but not nearly as often, just from changing tower requirements, so you can get bumped to a nearby tower with different addresses.
The only remedy that comes to mind is a more rapidly updating dynamic dns on your hotspot.
And I believe you would need it properly set that up in the user portal as well.
This way, your address is static in the registration system by domain name, but your IP gets updated as fast as your dyndns will update it to the name server.
So it does not have the wait for the registration list to update. The domain pointer (dynamic dns) does this for you.
There are still free DYN-DNS services out there.
No, I am not mobile as in traveling in a vehicle (as we hams typically think of “mobile” operations). I’m simply stationary using a “mobile hotspot”, i.e., a cellphone hotspot. Therefore, I’ve confirmed the cell towers aren’t actually changing.
I’ve done more experimentation, and found it comes down to two issues - AllStar often takes quite some time to update the DNS (which may be due to my node, as you said), and other nodes (such as with some repeaters and not others) can sometimes take hours (or days) to get the updated node information from All-Star.
I find it curious that this hotspot solution does not work as well as, say, Pi-Star with digital modes (which can quickly and consistently work on any network). Relying on the public WAN IP for registration seems like a rather strange concept in today’s age (especially with VPN’s being very common), as people are often moving from network to network or cell tower to cell tower. I’m uncertain as to why All-Star registration has to tie it to a specific WAN IP address, but I’ll see if I can read more documentation as to why this is required.
I appreciate everyone’s thoughts in this thread! I may pursue a different solution entirely for my use case, as All-Star seems to work best when used as a stationary solution in the shack. But I’ve found that when used stationary in the shack on the same network, it works quite well. I am specifically looking for a system that can continue to function regardless of the connected network or IP, and regardless of how quickly those change.
For better understanding to others reading this, a pi-star is a ‘unit of one’ and ‘directly updated’. No extra hoops to fill.
ASL is a unit of many thousands at a given time on a common registration system with a security loop in the mix and it is impossible to get instant updates for 10k+ nodes. Which is why the security update interval is about 10-15 minutes.
I probably should not say impossible,
but not likely admin can afford those kind of bandwidths on a open ‘free’ system.
So, no, it is not intended for such things. You have to create your own work around and I did provide you with a free work around idea that should work. Let me know if it works, If you should try it, so others will know the same.
That’s kinda how it works here.
Perhaps someone has a better idea yet.
If you have dvswitch mobile for android, you could connect and command one of your nodes for the connections you want.
I know several truckers who talk on AllStar all day no issues at all so there are definitely solutions. I would first look into a hotspot that comes with a static IP option, I’m pretty sure at least Verizon can do that. 2nd, nodes do know when their IP changes and should be able to send a registration update to ASL and connected nodes right away whenever that happens. If ASL is not properly accommodating that it’s probably not hard to fix and I would open a bug report on the ASL github page. Also the other couple options I mentioned before…
What I’ve found is that, as Mike mentuoned earlier, the updated registration for my node has to propagate to other nodes in order to be recognized. In some cases, it takes quite a long time (i.e., days) for my registration to propagate to all other nodes in my area. Some nodes appear to receive it almost immediately, whereas others do not.
As far as using another cell carrier, it’s entirely possible a different carrier would work better. However, I’m not going to purchase a new cellular hotspot specific just to All-Star, as that is added expense I’m not interested in. I appreciate your suggestion, though!
Hosting a cloud server and connecting a node to that may work for other nodes better, but I’ve experiemented with using a proxy server with a static IP and that has not made a difference.
It seems to ultimately come down to how All-Star requires authenticating a public WAN IP to validate a node’s identity. I need a solution where the IP is irrelevant and not used for registration, as it’s rare these days for endpoints to keep the same WAN IP unless they are static devices in an enterprise setting and/or always sitting behind the same VPN tunnel.
For now, I will pivot to using All-Star as a hotspot solution in my shack and pursue other options for use out in the field where WAN IP’s can and will constantly change.
The method I used years ago was that I took a wrt54g linksys router and loaded it with dd-wrt firmware,
And I ran it in reverse with the wifi being the wan.
The router wifi was tethered to my cell phone.
In the router, it has a dynamic DNS set-up built-in as I suspect your hotspot modem/router does as well, but I don’t know that.
Then you are using a static domain name for registration so everything is static within ASL network and the router/modem keeps updating the ip to the IP pointer in the name server in the ddns service.
Your results may very, it was some time ago I used this.