ASL 1.01 incoming connections doesn't appear to always work?

I have an AWS cloud server running Ubuntu 16.04 running ASL 1.01 from back in 2018. I run public nodes 48168 and 523800 and about 3 private nodes on it. I have recently started using 523800 to host a net twice a week and I’ve had reports of folks not being able to connect. After rebooting the server, it alleviated some connection issues. Last night node 48858 tried connecting and he said he tried about 5 times but no luck. I popped on another node I helped install 41607 and it connected first try. I had him try again and 48858 connected on the first try. I’ve got ports 5038 and some iax ports open as well.

Are there any other ports i can open to help with incoming connections?
Could 523800 being a nnx node have anything to do with it?
Is there anything I can set up for regular connections to have an easier time connecting?
Are there any connection status tools available for Allstar?
Can you help me test and see if you have issues connecting?

Does anyone have any ideas?

Watch the log (/var/log/asterisk/messages) while node is trying to connect.
Make sure the node list is current (/var/lib/asterisk/rpt_extnodes) is current

1 Like

Thanks Steve @N4IRS,

I looked at my node list and it had today’s date on it.

on the asterisk messages is there a way to add (or is that a good idea?) more logs information?

This is what mine looks like but it doesn’t show someone that connected just a few minutes ago. If i happen to have a terminal window pulled up i would use asterisk -rvvvvvvv and see more info but i don’t always have terminal open when someone connects.

[Mar 24 06:32:04] WARNING[1424] chan_iax2.c: REGISTER-LOG: Sending registration request for '523800#4569'
[Mar 24 06:32:05] WARNING[1421] chan_iax2.c: REGISTER-LOG: registry rereqquest
[Mar 24 06:32:13] WARNING[1417] chan_iax2.c: REGISTER-LOG: Sending registration request for '48168#4569'
[Mar 24 06:32:13] WARNING[1424] chan_iax2.c: REGISTER-LOG: registry rereqquest
[Mar 24 06:32:16] NOTICE[1194] dnsmgr.c: host 'register.allstarlink.org' changed from 162.248.92.131 to 34.105.111.212
[Mar 24 06:32:16] NOTICE[1194] dnsmgr.c: host 'register.allstarlink.org' changed from 34.105.111.212 to 162.248.92.131

Here is something for you to look at and consider…

If you or a node connected to your node has a private node number ‘connected’ and a new node attempts to connect that also has a private node ‘of the same number’ (like 1999),
the connection will be refused.

Choose a more odd number for your 4 digit private node number or use a unregistered NNX number for private nodes to avoid this. It was designed for ‘loopback protection’.

https://wiki.allstarlink.org/wiki/Private_nodes

1 Like

Mike, thanks for the reminder. Yes, I’ve experienced that in the past and have modified some of my private nodes to take that in acct. However, with this issue the folks that are connecting for the net are using personal simplex nodes and are very unlikely to be running private nodes but I will verify.

I know that checking this will be a pain.
But one user with a 1999 private node connected to your net will actually block anyone else with the same. there is no way to look at this on the ‘attempt’.
You can only look at those actually connected and make a note of the private nodes actually connected (bubble map works well) and take the issue of who cant connect with those node numbers if they will say.

It perhaps would be a good to note before the net to have folks disconnect unused private nodes before connecting for the net.

All in all, not a easy task. You can’t change users config. But you should ask for most to not use common node numbers like 199x for private nodes. Picking one that is more obscure.

I wrote a piece in the wiki on the issue as it is more common a issue than many think…
https://wiki.allstarlink.org/wiki/Private_nodes

You might reference it to some for better understanding.

On the other side, users must know they can’t just turn on a pi node and expect to connect to a system before their registration has processed and is seen by the server they are trying to connect to as a valid system. If it is not in the connectee’s nodelist yet, they will not be able to connect till it is.

Forcing a update to the nodeslist just before the net might help a little bit with that side of any issue.

additional note that many do not think important…
many users do not think that a node connected for ‘monitor’ counts, but it does. Connected is connected.

1 Like