Hi,
Is there a way to find the callsign attached to a Echolink node number that appears on the Allmon Dashboard ?
This number is NOT a native Echolink node number which is shorter.
Here a screen copy of what we see :
73 Patrick TK5EP
Patrick,
I suspect what you are seeing a a hacker in your system
He does not know this is a radio system and is probing. Likely does not understand if he is even looking and not just running a script.
You need to look at your firewall a but. Something is open in SIP or IAX.
But I do believe, what shows in allmon is a reflection od your announcement option in rpt.conf
eannmode=2 ;0=no announcements, 1=node number(Allstar-xlated), 2=callsign, 3=both
Hi Mike,
Thanks for the answer.
It is not a hacking problem. Weâre on a private LAN with a lot of firewalls and protections.
Yesterday evening, I myself made a test and connected/disconnected 4 times with Echolink and I got a different 7 digit node number at each connection.
A normal Echolink node number is a fixed 6 digit number.
https://www.echolink.org/validation/node_lookup.jsp
I will have a look on the eanmode parameter, but afaik, I have a different parameter settings in rpt.conf :
eannmode = 1 ; 1 = Say only node number on echolink connects (default)
; 2 = say phonetic call sign only on echolink connects
; 3 = say phonetic call sign and node number on echolink connects
73, Patrick
AllStar prefixes all Echolink numbers with a 3.
I suspect your connections are going through a proxy and the node number you are seeing is associated with the proxy.
I have Echolink announcements enabled on my node. When I connect from my phone it announces the proxy callsign.
Danny
Patrick,
If you watch asterisk in the foreground, it may shed a little light on what is happening.
asterisk -rvvv
There are a lot of possibilities as I have seen them over the years.
Sometimes itâs a relay or proxy agentâs software corruption.
But you could try to set earnmode to 3. This will not change anything except how it is displayed or announced. And likely, it is not in the echolink DB anyway. So that will not get you far.
Now, when I mentioned the hack, as I have witnessed, they have come though the firewall in a allowed exception on the port. Our security for the software port has to be sealed up. They are looking for asterisk boxes. They try all extensions and normally do not find much as they are looking for open/unsecured extensions and most of us do not have 3 digit extensions/nodes as they likely then try 4 digits and then 5. The area they are most likely to pop up is echolink from a improperly guarded iax or sip extension in the conf.
But if you watch asterisk in the foreground, you can quickly determine what it is. Since the hack scripts issue a lot of extensions very quickly. And you would likely see them in the verbose output. And they are relentless. They do not sit there manually, but work from automated scripts.
echolink security is kinda like our own, But if the injection point is our system, our software sees it as a valid echolink connection, even though it is not. It is the caller id of the hack starting with exten 3x(x).
Think of it as a spoofed CID.
When they run though the scripts and find nothing of interest to work from, they often just give up. But there will be others down the line. You can capture their IP and just block them in the firewall.
When you have a firewall, you have allowed ports and allowed address destinations for those ports. It is up to the software at the destination to continue/maintain security of those ports in your server. They are allowed through the firewall just by port. Our ASL-iax are cross check against the rpt_extnodes list to be allowed in the iax connection for the âASL networkâ system connections. That part is very very secure.
Everything else in extensions and trunks, if not secure, opens up new can of wormholes.
If you later determine it is a hack, contact me off-list. I can help.
If you can determine it is the relay or proxy, try to ID it so they can be informed.
But do not change your config much until you know what it is.
1 Like
take the 3 off. the node number is 997287. look it up in the echolink node list
Hi ,
After some investigations :
The eanmode parameter is âonlyâ changing the Echolink vocal announce, but never annoucing a callsign, only the node number. Not very usefull.
Indeed does ASL add a 3 at the start of the node number.
But this node number is not always a valid Echolink node.
With my Echolink AndroĂŻd app, I had a different number at each connection.
Looking in the âNetwork connectionâ settings, there are different choices :
- direct, relay, public proxy, custom proxy
My settings was ârelayâ and that caused the problem. Changing the setting to âdirectâ or âpublic proxyâ, the node number was correct.
So, it seems impossible to have a reliable method to retrieve a callsign from the node number if it depends on the user settings.
Is there another way to find the CALLSIGN of the connected station ?
According to : https://wiki.allstarlink.org/wiki/Echolink.conf_-_Echolink_Channel_Driver
there is a callsign based DENY and PERMIT possibility.
Where is the database located ?
Sorry for all these quetions and thanks,
Patrick
Here is an old dialplan app I built some years ago to do db lookup for elink,
however, without a dialing context example, probably worthless to you unless you build your own.
Mine is a bit complex to just paste here.
But you could provide a extension number and call it from the dialplan using the phone patch or using the context [echo_lookup] .
But I will highlight the asterisk command to do this from the command line.
[echo_lookup]
exten =_X.,1,Playback(connecting)
exten =_X.,n,System(âasterisk -rx âecholink dbget n ${EXTEN}ââ > /etc/asterisk/log/node-lookup.txt)
exten =_X.,n,ReadFile(NODEID=/etc/asterisk/log/node-lookup.txt,34)
exten =_X.,n,Wait,1
exten =_X.,n,SayAlpha(${NODEID})
exten =_X.,n,Playback(silence/1&vm-goodbye)
exten =_X.,n,Hangup
asterisk -rx âecholink dbget n ${EXTEN}â
where ${EXTEN} is the elink node#
here is a sample result from my system from command line implementation.
root@eoh:~# asterisk -rx âecholink dbget n 155783â
155783|KB8JNM-L|64.154.38.103
Hope that helps some
Now maybe I am imagining things (happens), but I thought there was a allow/block list in the echolink.conf
Perhaps someone knows more about this and can speak to it allow/block in the file.
It could be that it moved to the ASL white / black list after ACID version ?
But the issue, as you have now described it, seems more of a relay issue. So, whoever is running those relay servers may be mal-configed or there is something of issue in the protocol.
There are howtoâs on the elink site for folks that want to start a relay or proxy server.
I always use proxy servers where a direct connection is not possible. The callsign should be the users that way. But the folks that run the relays always seem to have issues with whose ID is forwarded.
With that I am likely out of ideas to help.
I did find the allow / deny in the echolink.conf file.
I have no entries myself, so I did not see it with all the other comments I have in the file
;permit=-
;deny=call,sign,sep,by,comma
The db of users is in the system, downloaded periodically just like the asl nodeslist.
It represents registered elink nodes.
But the location now escapes me.
I see this too on my system. No callsigns for connected echolink stations.
It is almost like the script that looks up the node number does not strip the leading â3â before populating the table. I also suspect that the connecting node is NOT in the current DB. If the lookup were to happen after the station connected AND after the DB was refreshed it might yield the callsign? Most phone based Echolink users turn on their app and then immediately make a connection so it is unlikely that they are in the current copy of the EL database.
Only when a phone user makes an Echolink connection via the iPhone RepeaterPhone app does a callsign get populated in my system. Clearly some work has been done at the iPhone end before the connection is made.
NI2O
AllStarLink/app_rpt can only know what the Echolink system tells it. You can see what it knows with the commands echolink dbget nnnnnn or echolink dbdump. Any corrupted information about a node # comes from the Echolink system.