George, did you ever get that statpost 401 error resolved? I’m having the same issue on my ASL3 server at a remote site, returning the same error on all 4 nodes on the server, yet they are all registered up and running (426090,091,095,099). The statpost_url line is under the node stanza for each node in rpt.conf. I have a Hamvoip node at the same site and not receiving that error. My ASL3 node can ping stats.allstarlink.org and I don’t see where the router at the site would be blocking anything outgoing port 80. I can connect inbound on http for the servers ALS3 web portal login page. Maybe one of the ASL admins can chime in on this. For the time being I’m going to have to comment out the stats url as the errors are clogging up my terminal in asteriks verbose mode.
Nope, I just gave up and ignore the error messages. I have two other nodes same site, no problems except they are ASL v1. I don’t know much about hamvoip so cannot make any comparison there.
I think I might know what’s going on now, on my end anyway. Check the ASL3 manual under IAX registrations. I’m using an LTE modem at the site on T-Mobile, and like AT&T, outgoing http traffic may end up being directed through a proxy/web accelerator, and then any registration requests getting passed through end up with a different IP being used by the node. This is an issue with those noded using rpt_http_registrations.conf in the new ASL3. I had to resort my node registration back to iax.conf (per those instructions). So my guess is the stats node registration which is using http, is sending a proxy IP back to Allstarlink which doesn’t like that mismatch, thinking the node is unregistered.
Failing with error 401 is “HTTP 401” which means bad password. The only way that happens is if the statpost line inside of rpt.conf isn’t within the configuration stanza for your particular node. If it’s anywhere else, it lacks the credentials because it doesn’t know what node is belongs to.
I’ll need to check that. I didn’t mess with that during installation. But that thin client is put away for now, it will replace the one on 490891 sometime soon.
There is no password being sent in those requests. Its a simple HTTP post like this: GET /uhandler.php?node=xxxxxx&time=1733781858&seqno=1&nodes=&apprptvers=3.1.0&apprptuptime=1733781858&totalkerchunks=0&totalkeyups=0&totaltxtime=0&timeouts=0&totalexecdcommands=0 HTTP/1.1\r\n
Someone else pointed out if you’re being proxied by your ISP, it fails. I concur, I’ve got two nodes, one with a static nat and one which has source/global nat. The global nat node gets this same error message consistently. I would assume handler is looking for nodes with the same apparent IP (STUN) as the web request. This mismatches because the web proxy for the statpost path of traffic is not the same as the global IP for all other traffic.
If I get adventurous, I’ll prove it on my home network/node by removing the static nat and seeing if the message starts after forcing a squid proxy in the middle of the http path.
Another option might be to get a VPN service and route all of your traffic through it.
Yeah, there’s no password in the line I was thinking about the node number being missing not the registration password. My bad - too much multitasking.
An HTTP 401 error comes from when the IP sending the GET’s URI node doesn’t match the registration IP address. So if for some reason your IP egress from a proxy or SNAT is flopping around then yes, you will get the 401s.
The other two nodes are not static IP. they work fine. When I went to run up the ASL3 box (HP Thin Client) it has a filesystem error, need to run fsck on it then check. But my lack of sleep last night has caught up. This will wait
GeorgeC
Light just went on. There must be an IP address mismatch. that never seemed to matter before. I was working on the replacement node 490891 but using the same node number. Switched to node 490892 and checked. Now statpost gives error 404. Is there a published list of error codes published, that would be a great idea.
GeorgeC W2DB
