Bob, Doug and all,
I fully understand why you would think that. It is so poorly
written.
And as I have watched this conversation get out of hand at least 2
times as you have Doug.
This is the first time I thought I would clarify how I was reading
their email statement before anyone gets elevated on it again.
other VoIP connections not Radio Sourced RoIP
connections and only if you can't verify the VoIP.
They are saying VOIP connections from non-radio sources...ie phone
and web portal without a security check. I have many non-experimental
phone and web ports but nobody knows what it is so it is not a open port.
I don't provide links to it from a web page or post a phone number and it
"does" have multilevel security checks. Even if folks stumbled on it by
accident or not, they would not have open access.
There are a lot of folks experimenting with asterisk side of the
set-up. Many of us that have been using asterisk for many years know that
we can port just about any kind of streaming audio or other services to
asterisk and thereby app_rpt. Hard to tell what interfaces/ports are open
on them and to where they go.
Because some folks don't think about the implications of their
actions, things happen. We all know that even from the radio side of the
equation.
Problems can also occur if a unauthorized station/system is connected
to others who are connected to you and there is no way to track that on
the echolink side.
They are asking that when "you" have a open port like that
(unverified VoIP), to disable the echolink port while it is active so a
unverified user does not get access to echolink through VoIP, not RoIP or
Radio. And I'm sure we feel the same way about that through
allstar.
By the way some of you guys are interpreting this, the iPhone and
Android apps and/or repeater to repeater echolink connects and PC to PC
echolink connects would not be legal to them.
Has anyone ever asked them to clarify the statement? Please tell
us/me "exactly" what they said !
If nobody answers that, perhaps one of us needs to ask them so we can
set the record straight as most of us use it on our systems and left
unanswered definitively, this will come up many more times.
And perhaps a text of a definitive rule could be included as a
default comment in the echolink.conf so there is no ignorance of what they
expect if you use it.
Bob (kk6ecm), you win the prize since you asked the question from the
email you received.
Would you Send them a message/reply to clarify the type of
connections "by example" they do not want and ask they not use the text
from the email that you do not understand ? or what type of VoIP
connections they are speaking of exactly.
Sure would put a end to the silliness of it time and time
again.
I think what leads folks to get one of those emails is basically a
list report of connected systems when a breach has been noticed. Problem
is, they have a security problem with some of the proxies on their system.
I have seen many a connect through a echo-proxy without an ID (callsign)
and more. I don't think anyone could ever know it's true source. Hence the
poorly worded generic email notice to all connected systems and obviously,
they are not familiar with the other systems to word it correctly.
Sorry to be long winded, but I don't want to this get elevated again
without good reason.
...mike/kb8jnm
-------- Original Message --------
Subject:
Re: [App_rpt-users] Echolink and app_rpt: Looking for
more
information on permit=*-*
From: Doug Crompton <
doug@crompton.com>
Date: Wed, November 12, 2014
1:13 am
To: "
app_rpt-users@ohnosec.org" <
app_rpt-users@ohnosec.org>
Mike,
I am going to
break my own rule and respond here! I don't think you are interpreting
there statement correctly...
They say....
"If you are running Asterisk with app_rpt and an
EchoLink channel, be sure it is configured not to allow other VoIP
connections when an EchoLink station is connected."
They go on to
specifically prohibit connections to Allstar, Wires, and many others is
not to be connected to Echolink. Bottom line is they think their
validation process is better than ours or others. I say we police it
just fine. A non ham popping up would stick out like a sore
thumb.
Bottom line they don't want us connected. In other words
they want it like IRLP with echolink. You can either connect to a
echolink station or an IRLP node, NOT both at the same time.
My
assertion still stands, ignore it but on the other hand like any good
ham make sure you police the activity on your nodes. There is no way to
practically isolate echolink from Allstar unless you somehow disconnect
all allstar nodes when an echolink call comes in and this would be crazy
to do.
73
Doug
WA3DSP
http://www.crompton.com/hamradio
From:
mike@midnighteng.comTo:
App_rpt-users@ohnosec.orgDate: Tue, 11 Nov 2014
21:15:26 -0700
Subject: Re: [App_rpt-users] Echolink and app_rpt:
Looking for more information on permit=*-*
Like many times before you, you don't seem to understand their
statement.
So nobody needs to go off on a tangent again.
You only need to be concerned if you do something like
"have a web portal to your system that has no limitation to who
uses it" (as in non-hams).
If you do then they have the possibility to use the echolink system
through your system and that is what they do not want.
Neither do we with allstar or via radio.
I'm sure there are a few bad actors out there somewhere allowing
access.
just make sure it is not you.
They could use better wording to keep the confusion/fuss
down.
As far as permit or deny...
permit= a list that only allows calls you place in the list to
connect.
deny= a list of calls that can not connect.
See the drupal site for info.
...mike/kb8jnm
-------- Original Message
--------
Subject: [App_rpt-users] Echolink and app_rpt: Looking for
more
information on permit=*-*
From: "Bob" <
kk6ecm@gmail.com>
Date: Tue, November 11, 2014
10:13 pm
To: <
App_rpt-users@ohnosec.org>
OK...
Echolink quality aside, I’m looking for some clarification how
app_rpt works with Echolink.
Attempting to understand the
statement from Echolink, “If you are running Asterisk
with app_rpt and an EchoLink channel, be sure it is configured not
to allow other VoIP connections when an EchoLink station is
connected. If this isn't practical, please disable the EchoLink
channel.” It seems that “other VoIP” means non-Echolink nodes; not
sure how Allstar can do this.
How does permit=*-*
(“prohibit computer-based connections”) work with an incoming
Echolink computer based node, or with an app_rpt hosted Echolink
node in an Echolink to Echolink configuration. When the user enters
*33 to connect, is it actually Echolink nodes connecting, or is
there a difference?
I think I get
their point they don’t want an Allstar node with Echolink node, to
simultaneously connect to another Allstar node that does not support
Echolink, but not sure why... still licensed amateurs
involved.
I am dismayed
with Echolink’s assertion that the use of a copy of a paper license
is more official than the FCC recognized ULS site, which it
appears Allstarlink.org uses to validate the users
license.
Thanks,
Bob
kk6ecm
_______________________________________________
App_rpt-users
mailing list
App_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-usersTo
unsubscribe from this list please visit
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom
of the page. Enter your email address and press the "Unsubscribe or
edit options button"
You do not need a password to unsubscribe, you
can do it via email confirmation. If you have trouble unsubscribing,
please send a message to the list detailing the problem.
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list
please visit
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom
of the page. Enter your email address and press the "Unsubscribe or edit
options button" You do not need a password to unsubscribe, you can do it
via email confirmation. If you have trouble unsubscribing, please send a
message to the list detailing the problem.
_______________________________________________
App_rpt-users mailing
list
App_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-usersTo
unsubscribe from this list please visit
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom
of the page. Enter your email address and press the "Unsubscribe or edit
options button"
You do not need a password to unsubscribe, you can do
it via email confirmation. If you have trouble unsubscribing, please
send a message to the list detailing the problem.
and scroll down to the bottom of
the page. Enter your email address and press the "Unsubscribe or edit
options button"
You do not need a password to unsubscribe, you can do
it via email confirmation. If you have trouble unsubscribing, please send
a message to the list detailing the problem.