Consider this thread "static". Apparently the node update had not processed until several minutes later: [Sep 19 12:25:17] NOTICE[15356]: chan_echolink.c:2102 do_el_directory: Directory pgm done downloading(full,compressed), 4345 records Connection is fine. NO3M Eric Tichansky wrote:

Left out some information:

Asterisk CLI: [Sep 19 12:21:12] ERROR[15355]: chan_echolink.c:2185 do_new_call: Cannot find DB entry for a/ipaddr/XX.XX.XX.XX

The IP (XX.XX.XX.XX) is consistent with the public IP where the client is initiating a connection from; the echolink master servers are also reflecting the correct client IP. I assume the DB entries are being updated periodically, but even after waiting a while, connects are still "un-authorized".

73 - Eric - NO3M

Eric Tichansky wrote:

...

Is there anything specific that needs to be configured to permit certain connections to the repeater via echolink? Specifically, when attempting to connect as user X to X-R (repeater), the client returns "Un-authorized". The echolink.conf file has no permit/deny parameters, so by default all connections should be accepted?

Hopefully this hasn't been asked elsewhere, if so, please direct me to that thread; otherwise, any pointers appreciated.

73 - Eric - NO3M _______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users

_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users

The problem that keeps coming up is that while the updates are attempted, it often fails throwing complaints about zlib, et.al. Between what seems to be a long delay in acquiring the node list and frequent failures, I've found there are times when it may be more than 30-45 minutes before the current IP becomes part of the locally cached listing. This isn't so good when trying to connect to the system using an echolink client on a laptop while mobile, where mobile broadband connectivity may be in and out periodically. Is anyone else seeing these same frequent echolink node list update failures? We are running asterisk/app_rpt/chan_echolink/zaptel from the 1.4.23-pre svn trunk over Gentoo Linux vs. ACID or limey linux. 73 - eric no3m

Bingo.

When run the echolink app on your pc, chan_echolink will not accept connections until it downloads an update to the authorized nodes list with your PC's node number in the update.

The thing to remember is that you must wait 5-10 minutes before trying to connect so that a node update includes your PC's node number.

Steve WA6ZFT

At 06:13 AM 9/21/2009, you wrote:

We just can't let anyone connect if we don't see a known IP because that poses a big security issue.

Other software (e.g. thebridge) falls back to a realtime lookup on the Echolink servers, if an unknown IP commects to it, under the assumption that it's a new node (e.g. someone who's just fired up Echolink on their PC) that is not in the local hosts cache. You can see this in action if you fire up Echolink on your PC and immediately connect to a conference. Instead of being immediate, it takes around 10 seconds, during which time, your unknown IP is being checked. Any reason chan_echolink can't do this and then add the result to the local cache/host list? I believe something similar happens when making an outbound call to an unknown node (been a while since I've talked to Skip about this area though). Skip and I often talk a lot about thebridge and related software, because I use it in all sorts of ways (EchoIRLP, etc). 73 de VK3JED / VK3IRL http://vkradio.com