Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chan_echolink: Echolink connections are coming through with random EL IDs #434

Open
jxmx opened this issue Dec 18, 2024 · 3 comments · May be fixed by #484
Open

chan_echolink: Echolink connections are coming through with random EL IDs #434

jxmx opened this issue Dec 18, 2024 · 3 comments · May be fixed by #484
Assignees
@KB4MDD
Labels
bug Something isn't working

Comments

@jxmx
Copy link
Member

jxmx commented Dec 18, 2024 •
edited
Loading

Spawned out of AllStarLink/Allmon3#261 there is an interesting issue with chan_echolink in that is either mis-processing or not properly receiving the Echolink ID number for connections. Upon connection, the Echolink ID appears to be a random number not related to the user. For example, KG5DRT connected to my test node (20.10.0+asl3-3.1.0-1.deb12) multiple times and was perceived as having a different ID each time when using the "RELAY" mode of connection which is the default on Android apparently.

[2024-12-18 10:11:48.429] DEBUG[760]: chan_echolink.c:3237 do_new_call: New Call - Callsign KG5DRT, IP Address 23.92.223.142, Node 198857, Name Jake.
[2024-12-18 10:17:56.257] DEBUG[760]: chan_echolink.c:3237 do_new_call: New Call - Callsign KG5DRT, IP Address 44.76.15.243, Node 825488, Name Jake.

The correct Echolink ID is 302884. According to KG5DRT this is only present when he's connecting via a "RELAY" mode. Not sure if this is a chan_echolink issue or not. The data as processed by a HamVOIP system appears to always be correct.
@jxmx jxmx mentioned this issue Dec 18, 2024
Closed
@Allan-N
Copy link
Collaborator

Allan-N commented Dec 18, 2024

I have repro'd this on my iPhone with the RepeaterPhone app (Proxy Type = Relay)

@jxmx jxmx added the bug Something isn't working label Dec 18, 2024
@dozment
Copy link

dozment commented Jan 28, 2025

I seem to be able to reproduce this at will also. I moved my production node back to my old Allstart node (Asterisk 1.4), and it is now working. I have a test node set up on the new one.

I'm now getting either "node not in DB" or the wrong node.

@KB4MDD
Copy link
Collaborator

KB4MDD commented Feb 4, 2025

I am recording information here based on my tests.

RELAY Mode
[2025-02-03 19:09:13.982] DEBUG[527456]: chan_echolink.c:3250 do_new_call: New Call - Callsign KB4MDD, IP Address 44.31.169.234, Node 958434, Name Danny.

[2025-02-03 19:18:14.492] DEBUG[527456]: chan_echolink.c:3250 do_new_call: New Call - Callsign KB4MDD, IP Address 44.31.169.235, Node 995929, Name Danny.

echolink dbget ipaddr 44.31.169.235
397918|NX1Q|44.31.169.235

echolink dbget ipaddr 44.31.169.235
339434|N2PBF|44.31.169.235

echolink dbget nodename 995929
Error: Entry for 995929 not found!

echolink dbget callsign KB4MDD
Error: Entry for KB4MDD not found!

Real node # from echolink.org
KB4MDD Dadeville AL [r] ON 19:21 904549

echolink page
W3CLF Essex, MD [r] BUSY 20:22 995929

Notes:

  • Each time I connect we are assigned a different ip address and node number.
  • The ipaddr associated with this connection has it's node number and call sign changing dynamically.
  • The reported node number we found with the connection's ip address is not the callers node number.
  • Trying to lookup the caller's call sign returns not on file.

KB4MDD added a commit that referenced this issue Feb 5, 2025
@KB4MDD
chan_echolink: dbget should look at connected nodes first
eccf17f 
This updates chan_echolink to make the dbget nodename and
dbget callsign commands look at the internal connected nodes
table first.

This modification is required due to the way the relay
servers operate.  They use one ip address for multiple
callsigns.  They also make up node numbers.  This causes
problems looking up relay mode nodes from the internal
node database.

This closes #434.
@KB4MDD KB4MDD linked a pull request Feb 5, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@KB4MDD KB4MDD

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

chan_echolink: dbget should look at connected nodes first AllStarLink/app_rpt
4 participants
@KB4MDD @jxmx @Allan-N @dozment