Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

David Ranch-3

Hello Everyone,

One of the reason why I wanted to ugrade from the old Svxlink code to the new GIT Maint release (April 12, 2015) was to a) get rid of the beeping sounds from IOS-based devices and to also get, what I understood, were the fixes for remote stations coming from a mismatched IP.

Item a)  I haven't had all that many stations connect to me yet but I am still hearing similar beeps very occasionally inteleaved in with different QSOs.  I don't think this is the roger beep but is there any way to make packet drops, etc. just be silent?

Item b) I just saw today that someone tried to connect but the system rejected them due to a different IP being registered to the Echolink server.  I understood that there was fix commited to refresh the Echolink directory when this happens.  Did that patch make it in?  It seems this tried three times but that last line is rather worrysome but I did try connecting to my station from Android and it connected just fine.

Any thoughts?

Ps.  I know there was a Python hack that someone mentioned many months ago but is there any chance to add time stamping to the STDOUT messages when Svxlink is run in the foreground?

--David
KI6ZHD


Spurious audio packet received from 107.23.11.57
Incoming EchoLink connection from AD6UN (iPhone) at 107.23.11.57
*** WARNING: Ignoring incoming connection from AD6UN since the IP address registered in the directory server (107.23.146.139) is not the same as the remote IP address (107.23.11.57) of the incoming connection
Spurious audio packet received from 107.23.11.57
Incoming EchoLink connection from AD6UN (iPhone) at 107.23.11.57
*** WARNING: Ignoring incoming connection from AD6UN since the IP address registered in the directory server (107.23.146.139) is not the same as the remote IP address (107.23.11.57) of the incoming connection
Spurious audio packet received from 107.23.11.57
Incoming EchoLink connection from AD6UN (iPhone) at 107.23.11.57
*** WARNING: Ignoring incoming connection from AD6UN since the IP address registered in the directory server (107.23.146.139) is not the same as the remote IP address (107.23.11.57) of the incoming connection
*** ERROR: Command timeout while communicating to the directory server
   

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

Rob Janssen
David Ranch wrote:

Hello Everyone,

One of the reason why I wanted to ugrade from the old Svxlink code to the new GIT Maint release (April 12, 2015) was to a) get rid of the beeping sounds from IOS-based devices and to also get, what I understood, were the fixes for remote stations coming from a mismatched IP.

Item a)  I haven't had all that many stations connect to me yet but I am still hearing similar beeps very occasionally inteleaved in with different QSOs.  I don't think this is the roger beep but is there any way to make packet drops, etc. just be silent?

You can do this yourself in the TCL script.
#
# Timestamp of last echolink carrier loss
#
variable last_carrier_loss 0;

#
# Executed when a transmission from an EchoLink station is starting
# or stopping
#
proc is_receiving {rx} {
  variable last_carrier_loss;

  if {$rx == 0} {
    set now [clock clicks -milliseconds];
    if { ($now - $last_carrier_loss) > 2500 } {
     ...  put your desired tone here
    }

    set last_carrier_loss $now;
  }
}

Ok it does not completely suppress them but at least it does not beep-beep-beel when there is regular packet loss.

The problem is that there is no difference between lost packets and end-of-transmission in Echolink.
To make it more reliable you need to increase the buffering, increasing the latency.  That is far worse.

You can also just remove the beep.


Item b) I just saw today that someone tried to connect but the system rejected them due to a different IP being registered to the Echolink server.  I understood that there was fix commited to refresh the Echolink directory when this happens.  Did that patch make it in?  It seems this tried three times but that last line is rather worrysome but I did try connecting to my station from Android and it connected just fine.

Any thoughts?


There is an open issue for that, see https://github.com/sm0svx/svxlink/issues/93 to find how to test it.
Please test it and report your findings.

Rob

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
* Rob Janssen <[hidden email]> [2015-04-29 09:53]:

> David Ranch wrote:
> >
> > Item b) I just saw today that someone tried to connect but the
> > system rejected them due to a different IP being registered to the
> > Echolink server.  I understood that there was fix commited to
> > refresh the Echolink directory when this happens.  Did that patch
> > make it in?  It seems this tried three times but that last line is
> > rather worrysome but I did try connecting to my station from Android
> > and it connected just fine.
>
> There is an open issue for that, see https://github.com/sm0svx/svxlink/issues/93 to find how to test it.
> Please test it and report your findings.

I'm a little confused by the comments in issue93.  Is that fix in the
master or not?  If it *is* in the master, I can tell you that it doesn't
work.  I consistently get the errors with the current master if I
connect and quickly try to reconnect with my phone.

--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

Rob Janssen
David Rock wrote:

> * Rob Janssen <[hidden email]> [2015-04-29 09:53]:
>> David Ranch wrote:
>>> Item b) I just saw today that someone tried to connect but the
>>> system rejected them due to a different IP being registered to the
>>> Echolink server.  I understood that there was fix commited to
>>> refresh the Echolink directory when this happens.  Did that patch
>>> make it in?  It seems this tried three times but that last line is
>>> rather worrysome but I did try connecting to my station from Android
>>> and it connected just fine.
>> There is an open issue for that, see https://github.com/sm0svx/svxlink/issues/93 to find how to test it.
>> Please test it and report your findings.
> I'm a little confused by the comments in issue93.  Is that fix in the
> master or not?  If it *is* in the master, I can tell you that it doesn't
> work.  I consistently get the errors with the current master if I
> connect and quickly try to reconnect with my phone.
>

No it is not in the master, see the comment about how to install the branch issue93.

Rob

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
* Rob Janssen <[hidden email]> [2015-04-29 16:13]:
> David Rock wrote:
> > I'm a little confused by the comments in issue93.  Is that fix in the
> > master or not?  If it *is* in the master, I can tell you that it doesn't
> > work.  I consistently get the errors with the current master if I
> > connect and quickly try to reconnect with my phone.
>
> No it is not in the master, see the comment about how to install the branch issue93.

I've never really worked with git before, and I'm trying to understand
how it works.  I was able to clone the repository and checkout the
issue93 branch, but how do I pull out just the branch files for
building?  

I'm using a Rasp Pi and building in memory in /tmp rather than
maintaining all the git code locally.  What I'm trying to figure out is
how do I know that I'm actually building against the files I think I am,
and how do I make a copy of just the files from issue93 (in a zip file
or whatever) that I can drop onto the Pi for building?


--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

Rob Janssen
David Rock wrote:
* Rob Janssen [hidden email] [2015-04-29 16:13]:
David Rock wrote:
I'm a little confused by the comments in issue93.  Is that fix in the
master or not?  If it *is* in the master, I can tell you that it doesn't
work.  I consistently get the errors with the current master if I
connect and quickly try to reconnect with my phone.
No it is not in the master, see the comment about how to install the branch issue93.
I've never really worked with git before, and I'm trying to understand
how it works.  I was able to clone the repository and checkout the
issue93 branch, but how do I pull out just the branch files for
building?  

I'm using a Rasp Pi and building in memory in /tmp rather than
maintaining all the git code locally.  What I'm trying to figure out is
how do I know that I'm actually building against the files I think I am,
and how do I make a copy of just the files from issue93 (in a zip file
or whatever) that I can drop onto the Pi for building?


In a directory on a PC do the commands that are in the issue93:

git clone https://github.com/sm0svx/svxlink
git checkout issue93

Then it has created a subdir svxlink that you can tar and copy to the Pi.
On the pi you untar it and then:

cd svxlink/src
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DSYSCONF_INSTALL_DIR=/etc -DLOCAL_STATE_DIR=/var -DUSE_QT=no -DCMAKE_BUILD_TYPE=Release ..
make
make install
ldconfig


Rob


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
* Rob Janssen <[hidden email]> [2015-04-29 17:03]:

> David Rock wrote:
> >
> > I'm using a Rasp Pi and building in memory in /tmp rather than
> > maintaining all the git code locally.  What I'm trying to figure out is
> > how do I know that I'm actually building against the files I think I am,
> > and how do I make a copy of just the files from issue93 (in a zip file
> > or whatever) that I can drop onto the Pi for building?
> >
>
> In a directory on a PC do the commands that are in the issue93:
>
> |git clone https://github.com/sm0svx/svxlink
> git checkout issue93
>
> Then it has created a subdir svxlink that you can tar and copy to the Pi.
> On the pi you untar it and then:
>
> cd svxlink/src
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DSYSCONF_INSTALL_DIR=/etc -DLOCAL_STATE_DIR=/var -DUSE_QT=no -DCMAKE_BUILD_TYPE=Release ..
> make
> make install
> ldconfig

Ok, I was under the impression that git has all code from all branches in
the cloned directory, and it was setting up symlinks or some other magic to
switch between branches.  When you checkout a specific branch, does it
actually replace/update all the files so that everything in the
directory is only from that specific branch?

--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

Rob Janssen
David Rock wrote:
> Ok, I was under the impression that git has all code from all branches in
> the cloned directory, and it was setting up symlinks or some other magic to
> switch between branches.  When you checkout a specific branch, does it
> actually replace/update all the files so that everything in the
> directory is only from that specific branch?
>

Yes.  You can switch between branches using git checkout.
Of course you should be careful when doing that and rebuilding, I just remove and re-create
the build directory to be safe.   But it should work without that when the makefiles are perfect,
and cmake of course tries to ensure that.

Rob

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
* Rob Janssen <[hidden email]> [2015-04-29 18:51]:

> David Rock wrote:
> > Ok, I was under the impression that git has all code from all branches in
> > the cloned directory, and it was setting up symlinks or some other magic to
> > switch between branches.  When you checkout a specific branch, does it
> > actually replace/update all the files so that everything in the
> > directory is only from that specific branch?
> >
>
> Yes.  You can switch between branches using git checkout.
> Of course you should be careful when doing that and rebuilding, I just remove and re-create
> the build directory to be safe.   But it should work without that when the makefiles are perfect,
> and cmake of course tries to ensure that.

Using branch issue93 appears to work.

Wed Apr 29 13:07:59 2015: SvxLink v1.4.99.0 (Apr 29 2015) Copyright (C)
2003-2014 Tobias Blomberg / SM0SVX


I still see a few of these errors (8 in one case, only 2 in another):

  Wed Apr 29 13:12:27 2015: *** WARNING: Ignoring incoming connection from
  K9DWR since the IP address registered in the directory server
  (107.23.11.57) is not the same as the remote IP address (107.23.158.3)
  of the incoming connection

But instead of it continuing to do that, it now continues as expected
and eventually connects with the new IP address:

  Wed Apr 29 13:12:27 2015: Spurious audio packet received from
  107.23.158.3
  Wed Apr 29 13:12:29 2015: Incoming EchoLink connection from K9DWR
  (David) at 107.23.158.3
  Wed Apr 29 13:12:29 2015: EchoLink: Using GSM codec only
  Wed Apr 29 13:12:29 2015: SimplexLogic: Activating module EchoLink...


So far, things look promising.  I'll add my notes to the issue as well
and keep an eye on things for a while to see if anything changes.

--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
* David Rock <[hidden email]> [2015-04-29 13:24]:
>
>
> So far, things look promising.  I'll add my notes to the issue as well
> and keep an eye on things for a while to see if anything changes.

I noticed one odd thing running the issue93 code.  Everything seems to
be doing fine except my most recent test connecting with my phone
doesn't allow me to transmit.  I connect just fine and can hear audio,
but keying up on my iPhone doesn't fire the PTT.  I know the PTT works
because I see my remote link keying up for the idents.

I'm trying to see if I still have the issue with the master branch (that
I know was working before).  Wondering if there's a difference in the
svxlink.conf file (like the change in the PTT_TYPE or something like
that) where there's an incompatibility in the config.

--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

Tobias Blomberg
On Wednesday 29 April 2015 17:28:18 David Rock wrote:
> * David Rock <[hidden email]> [2015-04-29 13:24]:
> > So far, things look promising.  I'll add my notes to the issue as well
> > and keep an eye on things for a while to see if anything changes.
>
> I noticed one odd thing running the issue93 code.  Everything seems to
> be doing fine except my most recent test connecting with my phone
> doesn't allow me to transmit.  I connect just fine and can hear audio,
> but keying up on my iPhone doesn't fire the PTT.  I know the PTT works
> because I see my remote link keying up for the idents.

Issue #93 is now merged to both master and maint so forget about the issue93
branch. Thanks for testing it!

73's de SM0SVX / Tobias


> I'm trying to see if I still have the issue with the master branch (that
> I know was working before).  Wondering if there's a difference in the
> svxlink.conf file (like the change in the PTT_TYPE or something like
> that) where there's an incompatibility in the config.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
* SM0SVX <[hidden email]> [2015-04-30 10:42]:

> On Wednesday 29 April 2015 17:28:18 David Rock wrote:
> > * David Rock <[hidden email]> [2015-04-29 13:24]:
> > > So far, things look promising.  I'll add my notes to the issue as well
> > > and keep an eye on things for a while to see if anything changes.
> >
> > I noticed one odd thing running the issue93 code.  Everything seems to
> > be doing fine except my most recent test connecting with my phone
> > doesn't allow me to transmit.  I connect just fine and can hear audio,
> > but keying up on my iPhone doesn't fire the PTT.  I know the PTT works
> > because I see my remote link keying up for the idents.
>
> Issue #93 is now merged to both master and maint so forget about the issue93
> branch. Thanks for testing it!

Glad to help.  I'll be running with the new master shortly.  I'll let
you know if I run into any issues with it.  I have not been able to
reproduce the PTT weirdness I mentioned earlier, so I'll be keeping an
eye on it.

--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

David Ranch-3
In reply to this post by Rob Janssen

Hello Rob,

Thanks for the help here..



Item a)  I haven't had all that many stations connect to me yet but I am still hearing similar beeps very occasionally inteleaved in with different QSOs.  I don't think this is the roger beep but is there any way to make packet drops, etc. just be silent?

You can do this yourself in the TCL script.

I'm not in front of the machine right now but beyond grep'ing for some of this matching text, can you tell me what file this should be?

There is an open issue for that, see https://github.com/sm0svx/svxlink/issues/93 to find how to test it.
Please test it and report your findings.

Ok... it blows me away this was so long ago!  Considering that branch is so old, would the better route be to try to merge this 93 branch into MAINT?  I also see that Tobias updated this ticket - https://github.com/sm0svx/svxlink/issues/93 where it now shows as "merged" but merged to WHERE?  The "master" branch or "Maint"?   It's not obvious where it went from the Web UI and I'm not familiar with Git enough to tell (but I'm willing to learn if anyone would be willing to give me the commands).

--David
KI6ZHD

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

David Ranch-3
In reply to this post by Tobias Blomberg

Hey Tobias,


Issue #93 is now merged to both master and maint so forget about the issue93 
branch. Thanks for testing it!

Ok, thanks for doing that and I'll pull a new copy of MAINT.  Curious, is there any reason why the new code doesn't show when an Echolink DB refresh is required?  I personally love lots of logging vs. just "magic" occurring.

--David

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

David Ranch-3
In reply to this post by David Ranch-3

I should clarify here..

> Ok... it blows me away this was so long ago!  Considering that branch
> is so old,

It was *my bad* that I never tested this when Tobias fixed it for me.  
So sorry about that but it honestly doesn't seem like it was a YEAR
ago!  Fortunately, I have updated all my RPM scripts and packaging to
pull Git whenever required so upgrades should now be pretty simple.

--David

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
In reply to this post by David Ranch-3
* David Ranch <[hidden email]> [2015-04-30 13:55]:
>
> https://github.com/sm0svx/svxlink/issues/93 where it now shows as
> "merged" but merged to WHERE?  The "master" branch or "Maint"? It's not

It's in both.  He commented in another part of the thread:

"Issue #93 is now merged to both master and maint so forget about the
issue93 branch."


--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

Rob Janssen
In reply to this post by David Ranch-3
David Ranch wrote:

Hello Rob,

Thanks for the help here..



Item a)  I haven't had all that many stations connect to me yet but I am still hearing similar beeps very occasionally inteleaved in with different QSOs.  I don't think this is the roger beep but is there any way to make packet drops, etc. just be silent?

You can do this yourself in the TCL script.

I'm not in front of the machine right now but beyond grep'ing for some of this matching text, can you tell me what file this should be?

The rogerbeep towards the radio listeners is sent from proc is_receiving in EchoLink.tcl

There is also proc squelch_open that sends the rogerbeep towards the EchoLink user.

Rob

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

Rob Janssen
Rob Janssen wrote:

The rogerbeep towards the radio listeners is sent from proc is_receiving in EchoLink.tcl

There is also proc squelch_open that sends the rogerbeep towards the EchoLink user.

As a general warning to casual TCL users (probably many in this group):

DO NOT USE the # sign to "comment out" parts of TCL code until you completely understand
how the # sign works in TCL.  Better not do it at all.  Just putting # marks at arbitrary places
in TCL scripts will lead to very mysterious errors and unexplainable problems.  About the only
thing that is safe, is putting a # in front of a simple "playTone 1000 100 100" line, i.e. a procedure
call with only fixed parameters and no braces.

The # sign in TCL is interpreted as part of the language syntax rather than as part of reading
the program text (like in the C/C++ "preprocessor").  This means that # signs in TCL are only
allowed where a statement is otherwise allowed, not halfway inside a statement or block.
Note that both a ; and a newline terminate a statement, so you can only put a # comment after
a statement when you first terminate it with a semicolon.

Also, { signs inside a # comment will cause trouble.  So you cannot "comment out" a block of
TCL code that uses { signs.

TCL manuals state that you should use something like

if { 0 } {
.....
}

To remove a block of code you temporarily don't want, but that does not work when the code is
not syntactically correct and/or has unbalanced braces.

Rob

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

David Ranch-3

Oh.. wow.. I didn't know that and I had put in some #comments in my patches too!  I wonder if that was part of my issue!  Seems pretty bad that TCL doesn't support comments like that.  That lends itself to unreadable code as the author can't explain some of the more complex areas of it. Hmmm..

--David


On 04/30/2015 02:35 PM, Rob Janssen wrote:
Rob Janssen wrote:

The rogerbeep towards the radio listeners is sent from proc is_receiving in EchoLink.tcl

There is also proc squelch_open that sends the rogerbeep towards the EchoLink user.

As a general warning to casual TCL users (probably many in this group):

DO NOT USE the # sign to "comment out" parts of TCL code until you completely understand
how the # sign works in TCL.  Better not do it at all.  Just putting # marks at arbitrary places
in TCL scripts will lead to very mysterious errors and unexplainable problems.  About the only
thing that is safe, is putting a # in front of a simple "playTone 1000 100 100" line, i.e. a procedure
call with only fixed parameters and no braces.

The # sign in TCL is interpreted as part of the language syntax rather than as part of reading
the program text (like in the C/C++ "preprocessor").  This means that # signs in TCL are only
allowed where a statement is otherwise allowed, not halfway inside a statement or block.
Note that both a ; and a newline terminate a statement, so you can only put a # comment after
a statement when you first terminate it with a semicolon.

Also, { signs inside a # comment will cause trouble.  So you cannot "comment out" a block of
TCL code that uses { signs.

TCL manuals state that you should use something like

if { 0 } {
.....
}

To remove a block of code you temporarily don't want, but that does not work when the code is
not syntactically correct and/or has unbalanced braces.

Rob


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y


_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beeps coming through on QSOs : Incoming Echolink connection IP mismatch

k9dwr
* David Ranch <[hidden email]> [2015-04-30 16:47]:
>
> Oh.. wow.. I didn't know that and I had put in some #comments in my
> patches too!  I wonder if that was part of my issue!  Seems pretty bad
> that TCL doesn't support comments like that.  That lends itself to
> unreadable code as the author can't explain some of the more complex
> areas of it. Hmmm..
>

Yeah, it's very subtle and can really throw you off if you aren't used
to it.  A good reference is http://wiki.tcl.tk/1669

--
David, K9DWR
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
12