I’ll try to keep this short and to the point. We have a new node that is behind an ISP (Team Mobile) that failed during a normal install (HTTP registration) so moved it to IAX2 and was up and running……for a couple days.
After a reboot, node is showing IAX2 registration, but can’t connect to outbound nodes. a connect to 55553 works fine. Strangely, online “whats my IP” websites return an internet IP address different than asterisk CLI node lookup. A remote user (me) trying to help can’t ping the IP of the asterisk CLI node lookup.
The node shows up in allstar as registered (green) but not reporting data. The asterisk CLI is reporting statposts failed with an error of 401 (unauthorized).
We’ve doublechecked all the changes to the config files required for IAX and everything seems to be all fine. Triple checked the node/password combo in iax.conf. I don’t believe this is a password problem as the node is showing registered (although I really don’t know that for sure).
Problem node 66957. IAX2 registry shows registered. Nothing glaring from check-install.
IT WAS WORKING before, so I don’t think this is a config problem but at this point I’m running out of things to check. Any suggestions?
NIJ meant T-Mobile as the provider.
Any further thoughts on how or why this could possibly stop working?
IAX2 is pretty braindead simple in terms of maintaining a registration even behind NAT.
Also we should have a number of other folks here using T-Mobile home routers & hotspots if you are able to chime in on any problems that would be very helpful.
It’s pretty expected that inbound connections are not going to work, but outbound should!
And the green registered status on the Allstarlink.org webpage nodes list being green and registered but with NO data make no sense.
I think it may be open a trouble ticket time.
Also if OP (original poster) could update the title to include “T-Mobile” I think that that would be really good in general and for future search hits.
NIJ meant T-Mobile as the provider.
Any further thoughts on how or why this could possibly stop working?
IAX2 is pretty braindead simple in terms of maintaining a registration even behind NAT.
Also we should have a number of other folks here using T-Mobile home routers & hotspots if you are able to chime in on any problems that would be very helpful.
It’s pretty expected that inbound connections are not going to work, but outbound should!
And the green registered status on the Allstarlink.org webpage nodes list being green and registered but with NO data make no sense.
I think it may be open a trouble ticket time.
Also if OP (original poster) could update the title to include “T-Mobile” I think that that would be really good in general and for future search hits.
Has a solution been found for this ? I’m having the exact same problem. Have a new node that’s been online for about a week. One day it will work fine, the next it won’t connect to anything. I edited the IAX.conf and modules.conf to exactly to what they should be. I also get that “unauthorized” 401 message in asterisk CLI. I’m running a T-Mobile hotspot also.
If you are saying that you're getting an HTTP 401 Unauthorized from the "statpost" call, then that would be expected if you're behind a CGN setup like T-Mobile. Undoubtedly, the perceived IP from the CGN pool is different than your IAX-perceived IP address. If you're behind a complex CGN system like T-Mobile and Verizon operate, you cannot use statpost reliably. But that has nothing to do with your ability to register.
So we spent many hours on the phone with the person that had the problem node and we were never able to fix it. We thought it had to do with something to do with statpost (as that was showing errors as listed above as well). Everything we did wouldn't allow us to connect. It was VERY frustrating that there wasn’t any information we could find on some type of process flow to help people get through the connection issue. I personally think all the statpost errors as well just confuse people. The responses from folks saying RTFM were not helpful as this problem is different than the 1000 other people having issues with connections of the “more common” types. I’ll just leave it at that.
So what did we do? After all that, we reburned an image with the same credentials as before and set up the node with the main menu node settings. Then we changed the node to IAX registration (following the ASL instructions) and the node registered and worked. More importantly, we are 18 days into this change and the node has not been touched, from a config standpoint, and continues to work. Some days the ASL stats pages will report the “Node is not reporting statistical data or is offline”, other days it reports normal. Today, it looks normal. The IP has changed at least once.
We chose not to touch it and so far it has worked fine. I think one important point is that we needed this node to be for outbound connections only. The point of VPN’s and static IP’s (and probably others) I’m sure would fix inbound connections, which we didn’t bother with, at least at this point.
As there are others that have been posting about this, I’d think there should be some work to create a small “how-to” when people are behind these T-Mobile routers. It was not obvious or easy to find anything on this subject, and we can’t be alone. I would help with this but I don’t have this ISP although at this point I’d consider getting it if that would be of help to the greater group. I would only require someone that really understands the WHYS behind what is happening on the T-Moble side as well as helping with some sort of super secret decoder ring for the statpost errors on the asterisk CLI. It’s very difficult to know if something is needed if all the messages are in bright red saying WARNING.
Thanks for your reply. I really do like your suggestion for a group to figure this out. There’s bound to be a bunch of others trying to use T-Mobile hotspot encountering this problem. My hotspot is actually through Calyx institute that uses T-Mobile. The hotspot is an Inseego MiFi X Pro 5G. It’s really fast connection and I like that is has a built in Ethernet port. The router has all the settings / features of a home router. I run another network radio from this hotspot and am able operate Echolink, BlueDV Ambe Server, and Peanut fine.
The really frustrating part is that the problem isn’t consistent. Once I ever get it to connect it seems to be fine for hours on end. But if I shut everything down, like I do of the night. Then start everything back the next morning, it can take hours to be able to connect to anything. This morning when I started it up it wouldn’t connect to anything except HUBNET in the U.K. Then after rebooting and restarting the node and hotspot half a dozen times I was finally able to connect to ECR and other nodes here in the US. Even after I’m able to connect to other nodes and talk fine, it still reports errors in asterisk CLI -rvvvv. Also very seldom does the Allstarlink website show my node reporting statistics.
This is not, and should not be the definitive answer, but I can tell you from experience that the way to achieve consistent results from behind a TMobile 4g/5g router is to tunnel your Allstarlink node through a VPN, where the IP address is consistent, both LAN and WAN as far as the node is concerned. Even HTTP registration works here, since the reported IP address will always match. This will often times give you a better route to your preferred node as well, depending on the end-point.
I have not experienced any of this with Verizon, and I haven’t tried AT&T.
Regarding the interplay of ASL and large mobile network providers, there really isn't a lot that can be "fixed" with the current AllStarLink use of the various protocols. The ASL design hails from a time when all devices had standard-addressed connections - i.e. late 1990s/early 2000s. Yes, ASL has been around that long. Then, the use of IP-matching as an authentication mechanism worked. However, massive networks like mobile telephone networks that use multiple strategies to deal with IPv4 scarcity and optimize bandwidth utilization are, by and large, indeterminately problematic for ASL.
Now that we have a good stable base for ASL3 and the massive infrastructure upgrade out of the way, one of the things I want to turn my attention to is the "next generation" authentication/call-tracking mechanism for AllStarLink that would render these issues moot. However, this is not a modest undertaking. And there are some major issues of how much backwards compatibility we will need. There are a great many legacy HamVOIP installs out there and some even go all the way back to ASL DIAL and some of the earliest systems from the mid-2000s. It's a significant problem that requires changes on the server-side, the client-side, and getting ~32K active users to take action.
Overall, there's roughly 10 people who are reasonably active at maintaining AllStarLink in all of its dimensions and it's not a small endeavor. This work is all volunteer and part-time. We're working to simultaneously keep ASL going and develop improvements.
