How to retrieve callsign from Echolink node number?

App_rpt-users
1

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 :

unnamed
unnamed866×153 9.51 KB

73 Patrick TK5EP

2

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

3

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

4

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

5

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
6

take the 3 off. the node number is 997287. look it up in the echolink node list

7

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

8

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.

9

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.