So I have a simple node setup with a USB device based on the SA818. No it’s not a cheap knockoff this time. Still getting used to using an HT instead of DVSwitch Mobile.
However I just discovered to my dismay a certain node would only accept Web Transceiver or WT mode connections. I’m a newbie and curious if an RF based node such as mine could ever connect to another node in WT mode?
I have a hunch about possible workarounds, but will hold off until I hear some educated opinions.
de Steve N6VL
If a node is only accepting connections via WT mode, then there is one of a couple of things going on.
However, I don’t think establishing a connection to allstar-public will be as simple as creating an autopatchup/dialplan that establishes a connection to a remote node, because the allstar-public context dialplan also includes logic to check for a registered callsign on allstarlin.org based on the callerid. I’m also pretty sure that just setting the callerid in a dialplan to your callsign won’t work either, but I’ve never had a need to try.
Also, I’m pretty sure even if you were to straight up IAX dial an extension on a remote allstar-public context, as the call is answered, it would keep your node transmitting continuously until the connection is dropped, unlike a normal call to a node using app_rpt.
Interestingly, ASL3’s allstar-public dialplan includes this lines, but I don’t know what database it’s looking at. I have a box running three nodes, one of which is a whitelist, but that node still accepts WT mode connections. This is by design, in my case, but if I want to blacklist a particular WT user,I don’t think I could easily do that at this point without making some changes to the dialplan. It’s commented out by default.
;exten => s,n,GotoIf($[${DB_EXISTS(whitelist/${CALLSIGN})}]?:hangit) ; Not in whitelist
FWIW, which node is rejecting your normal ASL connection?
I doubt there is a path for that.
Steve, it is possible the node is part of a wide network.
Sometimes in managing that, you can create specific nodes for purpose.
A node for WT’s (connects by callsign) Limited to callsign not node number.
A node for echolink
A node for digital inputs
etc.
The nodes may all be connected together. All tied to a asl hub
The WAN system used something similar at one time. Not sure if that holds true now.
It is a way to keep the network operational when a problem exists with only one segment.
Especially interference.
It may sound a little funny, but if you had to manage a lot of traffic it is a means to an end.
You might look at it on a bubble map or give me the node number and I’ll at least look at it.
Look at the connections it has and try a connect with one of them. But a bubble map will often show you which one if you look…
But it is only a guess.
The node is 60568. I’ll reach out to the node owner. It’s a node for a small group of people. I’m mostly curious as to why I can’t get it. I’m a kid with a new toy trying to figure the rules to this new t me universe.
is connected to 60658 which also does not accept connections.
Sounds intentional unless it is just bad configured inbound port.
FWIW, I can connect to that node from a local HamVoIP node, but I just tried connecting from an ASL3 node on another ISP, and it failed.
This is from a local HamVoIP node, because it was the easiest to get to at the moment:
-- Call accepted by <redacted> (format ulaw)
-- Format for call is ulaw
radioless3a*CLI> ```
And this is from an ASL3 node on another ISP:
``` asl*CLI> rpt fun 506318 *260568
[2024-11-10 17:11:47.738] NOTICE[2194985]: chan_iax2.c:4790 __auto_congest: Auto-congesting call due to slow response
asl*CLI> ```
I tried with a few other ASL3 nodes, and they all time out. However, every HamVoIP node I've tried so far works.
Here is another HamVoIP node connecting, but this one seems to prefer G726 for some reason.
``` plano*CLI> rpt fun 506315 *260568
-- Call accepted by <redacted> (format g726aal2)
-- Format for call is g726aal2
plano*CLI> rpt fun 506315 *10
-- Hungup 'IAX2/<redacted>:4569-7739'
-- Hungup 'DAHDI/pseudo-410448663'
plano*CLI> ```
And here is yet another local HamVoIP node:
``` linkbox*CLI> rpt fun 508425 *260568
-- Call accepted by <redacted> (format ulaw)
-- Format for call is ulaw
linkbox*CLI> ```
So, this suggests to me that, for some reason, ASL and HamVoIP lookup don't agree on the server address and/or port of this node.I am not sure what info you derived that from.
But you should check your own info.
Perhaps take a read on this first to give you some ideas on checks you can do yourself.
The 5 most popular reasons for connection failure
The audio format is a matter of the host and is a asterisk thing you can look-up online.
The host gets to pick it in a tier of priority of preferred and available formats.
Never an issue unless there are no common formats to negotiate.
And I would still communicate with that node owner for some details before you loose to much hair on this…
Yep, the format was a local configuration error on my part.
Anyway, HamVoIP uses DNS lookup.
60568.ip.hamvoip.org resolves to 72.107.154.3, and that works.
It looks like that node is considering itself a remote base, which probably explains why ASL3 won’t connect to it. I bet this is the entire problem. If it is not really a remote base, the node owner should turn that flag off in the allstarlink portal. Otherwise, if I understand correctly, if one connection is already established, then new connections, at least from ASL3, can’t be made.
patrick@asl:~$ sudo asl-node-lookup 60568
SRV (_iax._udp.60568.nodes.allstarlink.org)
10 10 4569 60568.remotebase.nodes.allstarlink.org.
A (60568.remotebase.nodes.allstarlink.org)
72.105.38.164
TXT (60568.nodes.allstarlink.org)
NN=60568
RT=NULL
RB=1
IP=72.105.38.164
PIP=NULL
PT=4569
RH=NULL
RPT LOOKUP (60568)
radio@72.105.38.164:4569/60568,72.105.38.164
radio@72.105.38.164:4569/60568,72.105.38.164
radio@72.105.38.164:4569/60568,72.105.38.164
patrick@asl:~$
That is correct .
a remote base designation allows only for one connection.
Apparently this was a temporary problem. Things have fixed themselves without any changes on my end so far as I’m aware.
Probably the node owner changed something? I messaged him on Discord but never got a reply.