Date   
Re: No audio from home

Carl Sorensen
 

Mic is set at 54.  Line is 47.

Is there anything I should look at?

Carl NB7C

On Tuesday, June 16, 2020, 4:03:20 PM MDT, David Cameron - IRLP <dcameron@...> wrote:


Do the people hear a dead transmission (it starts to transmit but has no
audio) or nothing at all?

Have you looked at the mixer settings?

Dave Cameron
VE7LTD

On 2020-06-16 10:00 a.m., Carl Sorensen via groups.io wrote:
> Hi Guys,
> I discovered my embedded node (#3417) wasn't putting out audio.  The
> DTMF is working fine.  I can connect but not heard.  Audio coming back
> sounds great but I can't be heard.
>
> I did the troubleshoot and it said everything passed except #10, the
> enviromental files.
>
> My PI node is working great (#3407)
>
> Carl Sorensen, NB7C
>


Re: No audio from home

Carl Sorensen
 

Yes, it transmits a carrier, no audio. I hate to say it, but I didn't think about the mixer. Since it worked well before, I didn't think anything as would have changed.

Carl, NB7C

On Tuesday, June 16, 2020, 04:03:20 PM MDT, David Cameron - IRLP <dcameron@...> wrote:


Do the people hear a dead transmission (it starts to transmit but has no
audio) or nothing at all?

Have you looked at the mixer settings?

Dave Cameron
VE7LTD

On 2020-06-16 10:00 a.m., Carl Sorensen via groups.io wrote:
> Hi Guys,
> I discovered my embedded node (#3417) wasn't putting out audio.  The
> DTMF is working fine.  I can connect but not heard.  Audio coming back
> sounds great but I can't be heard.
>
> I did the troubleshoot and it said everything passed except #10, the
> enviromental files.
>
> My PI node is working great (#3407)
>
> Carl Sorensen, NB7C
>


Re: No audio from home

David Cameron - IRLP
 

Do the people hear a dead transmission (it starts to transmit but has no audio) or nothing at all?

Have you looked at the mixer settings?

Dave Cameron
VE7LTD

On 2020-06-16 10:00 a.m., Carl Sorensen via groups.io wrote:
Hi Guys,
I discovered my embedded node (#3417) wasn't putting out audio.  The DTMF is working fine.  I can connect but not heard.  Audio coming back sounds great but I can't be heard.
I did the troubleshoot and it said everything passed except #10, the enviromental files.
My PI node is working great (#3407)
Carl Sorensen, NB7C

No audio from home

Carl Sorensen
 

Hi Guys,
I discovered my embedded node (#3417) wasn't putting out audio.  The DTMF is working fine.  I can connect but not heard.  Audio coming back sounds great but I can't be heard.

I did the troubleshoot and it said everything passed except #10, the enviromental files.

My PI node is working great (#3407)

Carl Sorensen, NB7C

Re: IP Address

Rick Szajkowski
 

Thanks so much Dave !

This helps a lot , again thank you

Richard Szajkowski
VA3 RZS VA3ZJ VE3BTE

On Jun 15, 2020, at 8:15 PM, David Cameron - IRLP <dcameron@...> wrote:

The IP will always have the hostname: stn2120.ip.irlp.net

dcameron@irlp:~$ host stn2120.ip.irlp.net
stn2120.ip.irlp.net has address 24.138.163.221


Dave Cameorn

On 15/06/2020 5:12 p.m., Rick Szajkowski wrote:
Trying to find the IP address of my node

I am away from the system and would like to know the static public up address of my node

Node 2120

Thanks

Richard Szajkowski
VA3 RZS VA3ZJ VE3BTE_


Re: Up address

David Cameron - IRLP
 

The IP will always have the hostname:  stn2120.ip.irlp.net

dcameron@irlp:~$ host stn2120.ip.irlp.net
stn2120.ip.irlp.net has address 24.138.163.221


Dave Cameorn

On 15/06/2020 5:12 p.m., Rick Szajkowski wrote:
Trying to find the IP address of my node

I am away from the system and would like to know the static public up address of my node

Node 2120

Thanks

Richard Szajkowski
VA3 RZS VA3ZJ VE3BTE_

Up address

Rick Szajkowski
 

Trying to find the IP address of my node 

I am away from the system and would like to know the static public up address of my node

Node 2120

Thanks 

Richard Szajkowski 
VA3 RZS VA3ZJ VE3BTE_

Re: Host name of node not correct number and outgoing audio fails.

Rick NK7I
 

Perhaps the also active stn3249 (correct node#) and 3248 is causing a network error at the DNS level?

That's a weird one anyway and they're not too far away from each other.

73,
Rick NK7I


On 6/15/2020 1:36 PM, k9dc wrote:
To close this out (in case someone else has a similar problem).

This turned out to be a typo in the file /etc/hostname which sets the hostname of the machine at boot up. That file was incorrectly set to stn3249 instead of stn3248. Not exactly sure why, but correcting that minor error, fixed everything.

-k9dc

On Jun 15, 2020, at 11:50, k9dc <dave@...> wrote:

On Jun 15, 2020, at 11:23, Bob Sampson <k6mby@...> wrote:

Good day,
At some point and in an unknown way the host name of node 3248 has been changed to 3249. Troubleshoot-IRLP runs without errors.  Node 3248, however, has a one way audio issue that I have been unable to sort out.  I am wondering if the audio issue is being caused by the host name being wrong and how might I go about correcting the name.  I have tried correcting the node name in the hosts file but then Troubleshoot_IRLP fails the PGP test.





Re: Host name of node not correct number and outgoing audio fails.

k9dc
 

To close this out (in case someone else has a similar problem).

This turned out to be a typo in the file /etc/hostname which sets the hostname of the machine at boot up. That file was incorrectly set to stn3249 instead of stn3248. Not exactly sure why, but correcting that minor error, fixed everything.

-k9dc

On Jun 15, 2020, at 11:50, k9dc <dave@...> wrote:

On Jun 15, 2020, at 11:23, Bob Sampson <@k6mby> wrote:

Good day,
At some point and in an unknown way the host name of node 3248 has been changed to 3249. Troubleshoot-IRLP runs without errors. Node 3248, however, has a one way audio issue that I have been unable to sort out. I am wondering if the audio issue is being caused by the host name being wrong and how might I go about correcting the name. I have tried correcting the node name in the hosts file but then Troubleshoot_IRLP fails the PGP test.

Re: Host Refleector

David Cameron - IRLP
 

IRLP nodes set the RTP NAME and ID in calls to refectors and experimental nodes:

# Modification for integrated reflector - VK3JED March 29 2005.
# Set Environment Variables for Speak Freely
# NOTE: $REFLECT_PASSWORD currently not used. Reserved for future use
export SPEAKFREE_CNAME="${CALLSIGN}"
export SPEAKFREE_ID="${CONVERTED_STATIONID} IRLP"::"${REFLECT_PASSWORD}"

These show up in the "active_ips" file of IRLP reflectors and somehow in the TLB and TBD programs.

You can also use monitors to see what IPs connect. You could do a blanket allow to allow all IRLP IPs by default, or choose what to do as each system connects.

Dave Cameron
VE7LTD

On 2020-06-14 10:46 p.m., Tony Langdon wrote:
On 13/06/20 13:00, Nosey Nick VA3NNW wrote:
k9dc wrote:
Experimental nodes/reflector (same thing) are not really part of the IRLP network per se. We simply offer a number, mapped to a specific public IP address or name. There are no keys issued and no security at all. [...]
Take a look on your node, at the file scripts/exp-x-reference
Oooooooooh, I see, it's essentially "just" a regular SpeakFreely host
that happens to be in an IRLP phone-book? ... and they connect on the
default SpeakFreely port?
For all intents and purposes, yes.  And yes, the default port (2074) is
used.

So in fact I probably can't even particularly tell what IRLP node ID
has connected to me, well I s'pose unless I rsync the IRLP hosts file
from time to time and hope the connecting IP address is listed? Or
does the node identify itself (albeit unauthenticated) as part of the
SpeakFreely protocol?
IRLP nodes should set the Speak Freely variables when they make the
connection.  If your experimental reflector runs tbd or tlb, the IRLP
nodes will be listed as "stnXXXX" (XXXX being the node number).  Other
stations (and nodes which aren't setting the variables correctly) will
appear as their IP address.  I can't comment on how sfreflect sees
connections to it from IRLP nodes.

Re: Host name of node not correct number and outgoing audio fails.

 

k9dc.

Both incoming and outgoing ports test OK using Troubleshoot-IRLP.  I did fix an echolink port (5999) that tested bad.  Router port configured wrong.

I will drop a note to installs.

Thanks,

Bob
K6MBY
Sequim, WA

Re: Host name of node not correct number and outgoing audio fails.

k9dc
 

The actual hostname is set with the ‘hostname’ command, and has nothing to do with the hosts file. The IP address of stn3248 = 172.92.92.156, but there appears to be no port forwarding established. Did ’troubleshoot-irlp’ indicate any other problems? (I am expecting the incoming ports to fail). This is fixed by configuring your ROUTER, not the IRLP node itself.

The node number is set in the environment file, and must be consistent with the PGP key, otherwise the PGP test will fail, but again this is not based upon anything in the hosts file. So I agree, something is very wonky with your set up.

If you would like someone to log in and take a look at it for you, send a request describing your problem to installs@ irlp.net.

-k9dc

On Jun 15, 2020, at 11:23, Bob Sampson <@k6mby> wrote:

Good day,
At some point and in an unknown way the host name of node 3248 has been changed to 3249. Troubleshoot-IRLP runs without errors. Node 3248, however, has a one way audio issue that I have been unable to sort out. I am wondering if the audio issue is being caused by the host name being wrong and how might I go about correcting the name. I have tried correcting the node name in the hosts file but then Troubleshoot_IRLP fails the PGP test.

The audio issue shows up when using the command line "audio_level_test"... The voice response is "clipping zero, audio level zero." I have swapped the Pi, the IRLP board, and the sound card trying to fix the audio issue. Testing using 9990.... connects to the reflector but gives no response back.

Any thoughts?

Bob
K6MBY
Sequim, WA
Node 3248

Host name of node not correct number and outgoing audio fails.

 

Good day,
At some point and in an unknown way the host name of node 3248 has been changed to 3249. Troubleshoot-IRLP runs without errors.  Node 3248, however, has a one way audio issue that I have been unable to sort out.  I am wondering if the audio issue is being caused by the host name being wrong and how might I go about correcting the name.  I have tried correcting the node name in the hosts file but then Troubleshoot_IRLP fails the PGP test.

The audio issue shows up when using the command line "audio_level_test"...  The voice response is "clipping zero, audio level zero."  I have swapped the Pi, the IRLP board, and the sound card trying to fix the audio issue.  Testing using 9990.... connects to the reflector but gives no response back.

Any thoughts?

Bob
K6MBY
Sequim, WA
Node 3248

Re: Host Refleector

 

On 13/06/20 13:00, Nosey Nick VA3NNW wrote:
k9dc wrote:
Experimental nodes/reflector (same thing) are not really part of the IRLP network per se. We simply offer a number, mapped to a specific public IP address or name. There are no keys issued and no security at all. [...]
Take a look on your node, at the file scripts/exp-x-reference
Oooooooooh, I see, it's essentially "just" a regular SpeakFreely host
that happens to be in an IRLP phone-book? ... and they connect on the
default SpeakFreely port?
For all intents and purposes, yes.  And yes, the default port (2074) is
used.

So in fact I probably can't even particularly tell what IRLP node ID
has connected to me, well I s'pose unless I rsync the IRLP hosts file
from time to time and hope the connecting IP address is listed? Or
does the node identify itself (albeit unauthenticated) as part of the
SpeakFreely protocol?
IRLP nodes should set the Speak Freely variables when they make the
connection.  If your experimental reflector runs tbd or tlb, the IRLP
nodes will be listed as "stnXXXX" (XXXX being the node number).  Other
stations (and nodes which aren't setting the variables correctly) will
appear as their IP address.  I can't comment on how sfreflect sees
connections to it from IRLP nodes.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: Networking failing using openvpn

 

On 11/06/20 07:58, David McAnally wrote:
These changes are now applied to my github repository <https://github.com/wd5m/echoirlp> for new installs. Thank you Dave Cameron! I should have done this long ago.
Thanks David.    I thought there was a GitHub out there somewhere, saves me creating one. :)


-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: Networking failing using openvpn

 

On 11/06/20 04:07, David Cameron - IRLP wrote:
Klaus,

Someone needs to fix the EchoIRLP scripts in the download repository
and/or update the install script. I spent a lot of time to fix the
broken scripts and it went nowhere. You will see my comments in the
scripts.

The problem is the use of SoX (command is sox) and how it handles
arguments. IRLP fixed this in 2015. There are also reasons to use aoss
and aplay versus other programs and play in many cases. It happens in
5 scripts in the EchoIRLP/scripts directory:
Thanks Dave, I've got a copy, will have a look.  There's a couple of us
talking about some updates.  I'm not yet in a position to take this on,
but I will take a look.   First step might be making a GitHub repository
(if there isn't already one) then learning how to use it. :)

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: Networking failing using openvpn

 

On 11/06/20 03:01, David Cameron - IRLP wrote:
To me it is a bit of a "hang"... The VPN drops, but the gateway is not
returned to the local LAN. It gets stuck on the VPN, but can not
reconnect.

I think the only solution is to have an external script that tries to
ping the private IP of the VPN server you are connected to, and if
fails a few times in a row, then restart the VPN.

It appears to be a bug in the older openvpn, as it does not seem to
recover from certain situations. You should be able to adjust some of
the keepalive parameters, etc.
Yes, older versions of OpenVPN do seem to get into a state where the
tunnel appears to be "up", but it can't pass traffic.  I have an old
OpenVPN router here, and I manage this with a cron job that runs ever
minute.  First it checks for connectivity using ping.  If connectivity
fails, then it kills the active OpenVPN process, waits 30 seconds and
restarts OpenVPN.  As a result, I've had a reliable tunnel for years.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: Experimental nodes

 

On 09/06/20 09:58, Craig - K1BDX - Node 8724 wrote:
Tony, yes, thanks for pointing that out.

Where can we get some introductory tutelage on how to set up and
operate a "linkbox" reflector? I have always wanted to learn how to
do that.
I'm happy to help.  As a first installment, there's a few things to get
you started.  To use tlb or tbd as a reflector, the first thing you need
to do is enable the Speak Freely protocol.  This is the protocol that
IRLP audio uses.  You do this with:

SF_Enable = 1

In addition, I would also set these to the following values:
SF_Port = 2074
SF_ReplyPort = 2074

If your server has multiple IP addresses, you should set
SFBind2IP = <IP of experimental reflector>

If the latter is not set, and the reflector is running on an alias IP,
it may reply using the main IP of the interface, which will cause the
security mechanisms on the IRLP node to reject the packets.  Binding the
specific IP ensures that the replies are sent with the correct IP.

If you're planning on setting up a conventional style of reflector, you
need to tell tbd/tlb what codec the reflector will use, which is done
with the CompressionType directive.  Here are the possible values

CompressionType = 0 #UNCOMP
CompressionType = 3 #GSM
CompressionType = 5 #ADPCM

However, for transcoding, full duplexx reflectors, you have to use tlb,
and things are done very differently.  You actually disable the standard
conference facilities with

ConfEnable = 0

And you don't need to bother with CompressionType, because the packet
conference is disabled anyway.  Instead, the conferencing is handled
using the port linking facilities - the same features used to link radio
ports.  This requires an EventScript that looks for stations that have
connected, then connects the new station to all existing ports using the
"link" command.  On the integrated reflectors, this is done using a pair
of scripts.  The first is called "linkports" and has the following code.

#!/bin/bash

if ! [ "$PORT" = "" ]; then ARGS="-p$PORT" ; fi
export ARGS
"$TBDCMD" $ARGS ..port | xargs -r -l1 "$SCRIPT"/addlink

The other script is called "addlink"

#!/bin/bash

PORTNAME=$1

if [ "$1" = "0" ];then exit 0 ; fi         
if [ "$1" = "tbdcmd" ];then exit 0 ; fi
if [ "$1" = "Available" ];then exit 0 ; fi
if [ "$1" = "$NEWCALL" ];then exit 0 ; fi
#echo "linking $NEWCALL to $1" >> ./link.log
$TBDCMD $ARGS ..link $NEWCALL $1

These scripts were written to run in a specific environment, but the
explanation of the extra variables is as follows:

$SCRIPT is where you keep your scripts to run the system.

$TBDCMD is the path to tlbcmd, usually /usr/local/bin/tlbcmd

$PORT is the CmdPort from the configuration file.  For most purposes, it
can be statically defined if it's not the default (5198).  I use a
variable, because the scripts can be run on one of 10 configuration
files, and the correct value is read from the relevant config file then
saved in the $PORT variable locally. 

$NEWCALL is the callsign of the station that just connected.  It is set
and exported by the EventScript when it runs on a "connected" event.

Here's a sample part of an EventScript that should work.  This one can
work with both transcoding and non transcoding by looking for the
"linkports" script.

if [ "$1" = "connected" ]; then
  # Check for a transcoding conference (presence of ./linkports symlink
in curr$
  if [ -f ./linkports ]; then
    NEWCALL=$3
    export NEWCALL
    ./linkports
  fi
fi

Another consideration is security.  IRLP's experimental reflectors
feature, by default, provides no security (see the sample tlb.conf to
find out how to disable audio packet passwords).  However, if you do
want to implement your own security mechanisms, look up the allow
commands (allow add, allow delete, etc), which will allow you to enforce
a degree of security, similar to how the reflectors do it.  But the
mechanisms of authentication and issuing the allow commands is for you
to work out. :)


And anyone else who has information to share about building reflectors
of any kind that are compatible with IRLP pleas jump in and share your
knowledge.
Anyway, that should get you started.  You need to read the README and
SCRIPTING files in the tlb archive, they will give you a LOT of useful
information, along with the sample tlb.conf.sample and other sample
config files.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: APRS script for Debian 10

Nosey Nick VA3NNW
 

John wrote:
Not that the irlp status page setting would have any bearing on
the status beacon of your node, it was just a stab in the dark.
Well actually... I'm hoping to fix that pretty soon, and was intending
to beta-test with all the VE3/VA3 nodes first. Then nobody needs to run
these scripts on their nodes, they just update status.irlp.net in the
usual way, and within a minute or so it should get to APRS, and *IF* you
have any local igates willing to send it back to RF, it will get back to
RF too.

Not enabled yet, was trying to clarify some details like FROMCALL,
TOCALL, etc. I'll announce here as soon as it's online.

I believe the O stands for operational, buggered if I recall what U
means.
Officially I0 (india zero) mean IRLP and E0 (echo zero) means EchoLink,
/L (slash Lima) means "Link", /r (slash romeo) means "voice repeater"
and there are no other official repeater symbols I'm aware of in any
official APRS documentation.

... however the most popular undocumented defacto standard seems to use
I0 for idle, C0 for connected, B0 for busy, O0 (Oscar zero) for offline.

I'm not aware of U being used, at least not for IRLP objects, in any
notable numbers, not in my "big data analysis" of all of April/May/June.

... but I think you're referring to something else - the "AVRS Status"
field? I never found a good description of what those MEAN, but they are
"Open", "Closed", "Assisted", or "Unknown".


73! Nick VA3NNW

--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer; sig@...
You cannot kill time without injuring eternity.

Re: Deb 13.03

David Cameron - IRLP
 

Funny enough, in describing the problem in my reply, I found the reason. The DTMF binary uses the "OSS Method" to mute the sound input, therefore it will not work without being called inside the aoss wrapper. This is going to require a re-write of a number of scripts, which I will work on in the coming days.

Dave Cameron

On 12/06/2020 12:09 p.m., Klaus Rung via groups.io wrote:
I am using the same pc and sound card as I used with the deb 7 that worked fine and muted the audio. The only change is the updated operating system.

On Friday, June 12, 2020, 1:18:01 p.m. EDT, k9dc <dave@...> wrote:



Actually the default method works just like before (switching from LINE to CD).  The problem is, modern sound cards no longer support a CD input. Thus a script with amixer commands is required to perform the muting. Every sound chip is different requiring different commands be used.  This has to be figured out using the labels inside alsamixer and is site specific.

-k9dc

On Jun 12, 2020, at 13:06, Klaus Rung via groups.io
<k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:

Ok thanks Dave, guess it has changed from being default of mute on
as standard.

Klaus
ve3kr

On Friday, June 12, 2020, 12:32:58 p.m. EDT, k9dc <dave@...
<mailto:dave@...>> wrote:



On Jun 12, 2020, at 12:17, Klaus Rung via groups.io
<k_rung=yahoo.com@groups.io <mailto:yahoo.com@groups.io>> wrote:

I recently installed the latest 13.03 debian, added EchoIRLP using
the new updated Echolink audio fixes and all works fine now except the dtmf is not muting during any dialing sequence or 73. Is this a problem generally or is it just in my node and if it is a general problem with all the new installs is there a fix for this to bring back muting of the dtmf so it does not get to the other end of the link?

Klaus
ve3kr
249