Topics

Followup on Network Watchdog timeout message FCS to DMR bridge


David Young
 

I posted an issue several months ago concerning getting the error message 'Network Watchdog Timeout' after any FCS transmission using an MMDVM_Bridge between FCS and DMR.  Specifically this caused another bridge which I am running 'NXDN to DMR', same DMR TG, to stop working.  What happens is that the NXDN MMDVM_Bridge log file sees the Network Watchdog Timeout error message and does not see any subsequent Tx Stop message so NXDN thinks that the FCS bridge is still talking and stays in listen mode.  So the Tx Stop message does not get passed to the NXDN Bridge after the Network Watchdog Timeout message.  I had a suggestion that possibly to prevent the Network Watchdog Timeout error message from occurring that in G4KLX's MMDVM.ini configuration file there is a software switch in the "System Fusion" stanza labeled "RemoteGateway=".  Setting this switch to a numeric 1 might prevent the Network Watchdog Timeout error and resulting error message in the FCS MMDVM_Bridge.  Looking at the DVSwitch MMDVM_Bridge configuration 'ini' file, there is no software switch suggested in the "System Fusion" stanza.  Is it possible to add this switch or would this be of any help to my problem with the NXDN bridge?
--
Dave WB6DTB


Steve N4IRS
 

Dave,
We thought this was resolved. I am going to setup a test FCS <-> NXDN bridge. I will report my findings. I expect I'll do it first thing tomorrow morning.

Steve

On 12/11/20 7:45 PM, David Young wrote:
I posted an issue several months ago concerning getting the error message 'Network Watchdog Timeout' after any FCS transmission using an MMDVM_Bridge between FCS and DMR.  Specifically this caused another bridge which I am running 'NXDN to DMR', same DMR TG, to stop working.  What happens is that the NXDN MMDVM_Bridge log file sees the Network Watchdog Timeout error message and does not see any subsequent Tx Stop message so NXDN thinks that the FCS bridge is still talking and stays in listen mode.  So the Tx Stop message does not get passed to the NXDN Bridge after the Network Watchdog Timeout message.  I had a suggestion that possibly to prevent the Network Watchdog Timeout error message from occurring that in G4KLX's MMDVM.ini configuration file there is a software switch in the "System Fusion" stanza labeled "RemoteGateway=".  Setting this switch to a numeric 1 might prevent the Network Watchdog Timeout error and resulting error message in the FCS MMDVM_Bridge.  Looking at the DVSwitch MMDVM_Bridge configuration 'ini' file, there is no software switch suggested in the "System Fusion" stanza.  Is it possible to add this switch or would this be of any help to my problem with the NXDN bridge?
--
Dave WB6DTB


Steve N4IRS
 

Dave,
One question. You reference "Network Watchdog Timeout" Are you seeing those words in the log?
You should be seeing this:
M: 2020-12-12 14:37:26.510 YSF, received network end of transmission (expired), 1.5 seconds, 0% packet loss, BER: 1.3%


 

On 12/11/20 7:45 PM, David Young wrote:
I posted an issue several months ago concerning getting the error message 'Network Watchdog Timeout' after any FCS transmission using an MMDVM_Bridge between FCS and DMR.  Specifically this caused another bridge which I am running 'NXDN to DMR', same DMR TG, to stop working.  What happens is that the NXDN MMDVM_Bridge log file sees the Network Watchdog Timeout error message and does not see any subsequent Tx Stop message so NXDN thinks that the FCS bridge is still talking and stays in listen mode.  So the Tx Stop message does not get passed to the NXDN Bridge after the Network Watchdog Timeout message.  I had a suggestion that possibly to prevent the Network Watchdog Timeout error message from occurring that in G4KLX's MMDVM.ini configuration file there is a software switch in the "System Fusion" stanza labeled "RemoteGateway=".  Setting this switch to a numeric 1 might prevent the Network Watchdog Timeout error and resulting error message in the FCS MMDVM_Bridge.  Looking at the DVSwitch MMDVM_Bridge configuration 'ini' file, there is no software switch suggested in the "System Fusion" stanza.  Is it possible to add this switch or would this be of any help to my problem with the NXDN bridge?
--
Dave WB6DTB


k7wby@...
 

I thought network watchdog errors were XLX/AMBED related?


David Young
 

Steve,

Tx on FCS00379
The log message is on the NXDN MMDVM_Bridge:  "M: 2020-12-12 14:37:26.510 DMR Slot 2, received network voice header from WB6DTB to TG 30639"
"M: 2020-12-12 14:37:26.510 DMR Slot 2, network watchdog has expired, 2.4 seconds, 12% packet loss, BER: 0.0%"

So we are sending both NXDN and various FCS rooms to HBlink3 master using DVSwitch MMDVM_Bridge modules.  FCS uses YSFGateway and I guess because we are then going from FCS through YSFGateway through MMDVM_Bridge to HBlink3 that is why the log shows DMR instead of YSF for the two log entries as above.  This is all running on cloud servers.
--
Dave WB6DTB


k7wby@...
 

On Sun, Dec 13, 2020 at 09:09 AM, David Young wrote:
network watchdog has expired, 2.4 seconds, 12% packet loss, BER: 0.0%
That is an AMBE error. It's important to remember that when you bridge from YSF to DMR the transition is done by stripping the unique data from YSF leaving only what is common to both modes and then reapplying (when possible) the data to destination mode. The process of vocoding is important and both modes should use the same process. If one is using the md380 and the other OP25 you may experience these errors. 


Steve N4IRS
 

Dave,
Please show me the result of:
/opt/MMDVM_Bridge -v

Also please show the log with some sample FCS transmissions.

On 12/13/20 12:09 PM, David Young wrote:
Steve,

Tx on FCS00379
The log message is on the NXDN MMDVM_Bridge:  "M: 2020-12-12 14:37:26.510 DMR Slot 2, received network voice header from WB6DTB to TG 30639"
"M: 2020-12-12 14:37:26.510 DMR Slot 2, network watchdog has expired, 2.4 seconds, 12% packet loss, BER: 0.0%"

So we are sending both NXDN and various FCS rooms to HBlink3 master using DVSwitch MMDVM_Bridge modules.  FCS uses YSFGateway and I guess because we are then going from FCS through YSFGateway through MMDVM_Bridge to HBlink3 that is why the log shows DMR instead of YSF for the two log entries as above.  This is all running on cloud servers.
--
Dave WB6DTB


David Young
 

Steve,

Not sure about the command you are asking me to execute  /opt/MMDVM_Bridge -v
This results in command not found.  I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge.

Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log.  These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge.  As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode.  The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master.

Dave
--
Dave WB6DTB


Steve N4IRS
 

Sorry.
Show the output of:
/opt/MMDVM_Bridge/MMDVM_Bridge -v

Sent by smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of David Young <dly2@...>
Sent: Sunday, December 13, 2020 11:59:05 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Followup on Network Watchdog timeout message FCS to DMR bridge
 
Steve,

Not sure about the command you are asking me to execute  /opt/MMDVM_Bridge -v
This results in command not found.  I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge.

Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log.  These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge.  As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode.  The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master.

Dave
--
Dave WB6DTB


Steve N4IRS
 

Dave,
Mike and I tested FCS bridging this weekend. Here is what we ran:

Mike:
FCS00290 to NXDN 3166

Steve
FCS00290 to DMR 3112138

In each case, audio is clean and EOT is being received by a station monitoring to bridge output. Admittedly, we were listening to the output on DVSwitch based nodes.
We did not test with HBlink3 in the mix. Can you give me a simple diagram of what your are doing to bridge the 3 modes?

Steve

On 12/13/2020 11:59 PM, David Young wrote:
Steve,

Not sure about the command you are asking me to execute  /opt/MMDVM_Bridge -v
This results in command not found.  I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge.

Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log.  These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge.  As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode.  The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master.

Dave
--
Dave WB6DTB


Steve N4IRS
 

David,
What processor are you running your bridges on? uname -a

On 12/13/2020 11:59 PM, David Young wrote:
Steve,

Not sure about the command you are asking me to execute  /opt/MMDVM_Bridge -v
This results in command not found.  I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge.

Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log.  These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge.  As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode.  The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master.

Dave
--
Dave WB6DTB


David Young
 

Steve,
Result of -v command:  MMDVM_Bridge version 20201105_V1.6.1 git #0a3bff0
We are running all bridging on cloud server running 'Debian 10 Buster x64' and using the DVSwitch module 'MMDVM_Bridge.amd64'
Didn't consider that HBlink3 might be causing the problem.  We have the HBlink3 configuration set to:  Repeat=true
I will attach with the simple bridge diagram additional config files including the hblink.cfg.  This is the first time I have used HBlink3 so you may see something wrong in my configuration causing this problem.  We are using the same TG number for both TGIF DMR and NXDN.

Thanks for your help,
Dave
--
Dave WB6DTB


Steve N4IRS
 

Dave,
I have uploaded a proposed for your FCS EOT issue. It is located in the testing branch on github at <https://github.com/DVSwitch/MMDVM_Bridge/blob/Testing/raw/MMDVM_Bridge.amd64>
To install:
cd /opt/MMDVM_Bridge
systemctl stop mmdvm_bridge
mv MMDVM_Bridge MMDVM_Bridge.old
wget https://github.com/DVSwitch/MMDVM_Bridge/raw/Testing/bin/MMDVM_Bridge.amd64
mv MMDVM_Bridge.amd64 MMDVM_Bridge
systemctl start mmdvm_bridge

retest and report.
For anyone else that wants to play, I also pushed a update to armhf.

Steve N4IRS

On 12/14/2020 12:12 PM, David Young wrote:
Steve,
Result of -v command:  MMDVM_Bridge version 20201105_V1.6.1 git #0a3bff0
We are running all bridging on cloud server running 'Debian 10 Buster x64' and using the DVSwitch module 'MMDVM_Bridge.amd64'
Didn't consider that HBlink3 might be causing the problem.  We have the HBlink3 configuration set to:  Repeat=true
I will attach with the simple bridge diagram additional config files including the hblink.cfg.  This is the first time I have used HBlink3 so you may see something wrong in my configuration causing this problem.  We are using the same TG number for both TGIF DMR and NXDN.

Thanks for your help,
Dave
--
Dave WB6DTB


David Young
 

Steve,
Yes, success!!!
Works perfectly.  On you install instructions,  a note:
Installing the new MMDVM_Bridge module, just doing the systemctl stop command and replacing the existing MMDVM_Bridge module and restarting using systemctl start, did not fix the problem although the module did restart.  I needed to reboot the server and restart from cold and that then did the trick and all works now.  I had to also do a:  chmod +x MMDVM_Bridge, to get my script to execute without a permission denied error.

Thanks much Steve, I've been struggling with this for some time.
--
Dave WB6DTB