Date   

Re: DMR to analog gateway questions: Avoid ASL for analog linking, DV3000 vs md380-emulator for quality, local linking when Internet down, everything on one BBB

Steve N4IRS
 



On 3/2/19 7:08 PM, dvswitch-groupsio@... wrote:
Hello Everyone,

I'm new to the list and didn't find many search hits in either Google or dvswitch.groups.io so I thought I'd add a new topic on a few questions:

1) Analog linking without ASL:  The goal here is to link an existing DMR system on the Brandmeister network to an existing analog repeater which is already on IRLP and Echolink (EchoIRLP).  From what I can tell, most recommendations are to add Allstar to the setup for the analog side.  I don't necessarily want Allstar as it's an additional hop that maybe isn't required.   It seems that direct DMR to Echolink support isn't possible today w/o the ASL hop.  What about directly using IRLP?  Yes?  No?  I'm just trying to minimize complexity here and I'm not particular to any one technology.
For the most part to go to any of the analog networks, ASl is required. Though, ASL is not really a hop to go to EchoLink since both can be running on a private or non-published node. 

2) Audio quality.  Is there any audio quality differences between using say md380-emulator vs. say a hardware AMBE solution like the DV3000U?  There is a "Quality vs. Cost" bullet in
https://docs.google.com/document/d/1-Ot5pGaibmEGmmFh-l8HUq2LRyZoujiJYulr-VSga9s/edit but there is nothing under it.  I much rather buy some hardware here to minimize any poor digital audio artifact issues.
The absolute best audio quality is a DV3000. MD380 is a close second.

3) An ideal goal of ours is that if the Internet connection goes down, we could still have the DMR system (Motorola unit) and the analog system linked in a stand alone way.  Once the Internet comes back up, the link would resume to the BrandMeister TG.  I've seen some hints that HB_Bridge might allow for this but can anyone confirm this?   Can anyone share some URLs or documentation for examples?
To connect to a Motorola repeater you would use IPSC_Bridge. It will take some thinking to build a failover system you describe.

4) If my minimal and internet decoupled design is possible, is it realistic to run all this on a single Beagle Bone Black (BBB)?   Maybe only an RPI 3+ can do all this?  Maybe only an Intel i3+?   I'm ultimately looking for what compute hardware might be recommended to run everything on one host.  We do have a MicroNode RTCM device as well as a DMK URI device available which can be used or we can also put together our own soundcard+PTT setup.   My preference would be to have less compute hardware to maintain.
I would say all of the hardware you describe would work.

--David
KI6ZHD

73, Steve N4IRS


DMR to analog gateway questions: Avoid ASL for analog linking, DV3000 vs md380-emulator for quality, local linking when Internet down, everything on one BBB

David Ranch
 

Hello Everyone,

I'm new to the list and didn't find many search hits in either Google or dvswitch.groups.io so I thought I'd add a new topic on a few questions:

1) Analog linking without ASL:  The goal here is to link an existing DMR system on the Brandmeister network to an existing analog repeater which is already on IRLP and Echolink (EchoIRLP).  From what I can tell, most recommendations are to add Allstar to the setup for the analog side.  I don't necessarily want Allstar as it's an additional hop that maybe isn't required.   It seems that direct DMR to Echolink support isn't possible today w/o the ASL hop.  What about directly using IRLP?  Yes?  No?  I'm just trying to minimize complexity here and I'm not particular to any one technology.

2) Audio quality.  Is there any audio quality differences between using say md380-emulator vs. say a hardware AMBE solution like the DV3000U?  There is a "Quality vs. Cost" bullet in
https://docs.google.com/document/d/1-Ot5pGaibmEGmmFh-l8HUq2LRyZoujiJYulr-VSga9s/edit but there is nothing under it.  I much rather buy some hardware here to minimize any poor digital audio artifact issues.

3) An ideal goal of ours is that if the Internet connection goes down, we could still have the DMR system (Motorola unit) and the analog system linked in a stand alone way.  Once the Internet comes back up, the link would resume to the BrandMeister TG.  I've seen some hints that HB_Bridge might allow for this but can anyone confirm this?   Can anyone share some URLs or documentation for examples?

4) If my minimal and internet decoupled design is possible, is it realistic to run all this on a single Beagle Bone Black (BBB)?   Maybe only an RPI 3+ can do all this?  Maybe only an Intel i3+?   I'm ultimately looking for what compute hardware might be recommended to run everything on one host.  We do have a MicroNode RTCM device as well as a DMK URI device available which can be used or we can also put together our own soundcard+PTT setup.   My preference would be to have less compute hardware to maintain.

--David
KI6ZHD


Re: looking at my options

Mike AE4ML
 

Steve,
I have had too much fun putting this together. I appreciate your help .  Logg files are the biggest help out there and knowing how to use them as well as coming back to this group and seeing if there have been any past issues that are similar to what you are experiencing to help you resolve issues first. 

I laid out my idea on paper and then I created a spreadsheet. I loaded all of the programs on the system and then created 4 directories under /opt for each system I was building. I  copied all the files into each directory from a master. I kept that master on the system. 

I followed my design spreadsheet and tested each reflector and bridge before moving to the next.
The next step was to copy the systemctl files for each and every process. under /lib/systemctl/system directory I modified all of the startup files.
in all 20 files are created and are running. 8 analog bridges, 4 MMDVM Bridges, 4 P25Gateways and 4 P25Reflectors.

As you can see I have created the AWS Linux server with 4 P25 Reflectors and attached to those on the back end of each one is a DMR to P25 Bridge.
I'm not overly concerned about YSF as those radios can do YSF2P25 or YSF2DMR on the Pi-Star.

The next step is going to be learning how to cross link these when needed.

BM  1 (3107XX) <->  MMDVM  <->  Analog-DMR <-> Analog-P25 <-> MMDVM <-> P25Gateway <-> P25Reflector 1   41000
BM  2 (310XXX) <->  MMDVM  <->  Analog-DMR <-> Analog-P25 <-> MMDVM <-> P25Gateway <-> P25Reflector 2   41010
BM  3 (310XXX) <->  MMDVM  <->  Analog-DMR <-> Analog-P25 <-> MMDVM <-> P25Gateway <-> P25Reflector 3   41020
BM  4 (310XXX) <->  MMDVM  <->  Analog-DMR <-> Analog-P25 <-> MMDVM <-> P25Gateway <-> P25Reflector 4   41030

 System Status
--------------------------------------------------------------
 6905 ?        Ssl    0:00 /opt/310756/Analog_Bridge_DMR/Analog_Bridge /opt/310756/Analog_Bridge_DMR/Analog_Bridge_DMR-310756.ini
 6930 ?        Ssl    0:00 /opt/310756/Analog_Bridge_P25/Analog_Bridge /opt/310756/Analog_Bridge_P25/Analog_Bridge_P25-310756.ini
10974 ?        Ssl    0:03 /opt/310747/Analog_Bridge_DMR/Analog_Bridge /opt/310747/Analog_Bridge_DMR/Analog_Bridge_DMR-310747.ini
10999 ?        Ssl    0:02 /opt/310747/Analog_Bridge_P25/Analog_Bridge /opt/310747/Analog_Bridge_P25/Analog_Bridge_P25-310747.ini
13716 ?        Ssl    0:00 /opt/310764/Analog_Bridge_DMR/Analog_Bridge /opt/310764/Analog_Bridge_DMR/Analog_Bridge_DMR-310764.ini
13778 ?        Ssl    0:00 /opt/310764/Analog_Bridge_P25/Analog_Bridge /opt/310764/Analog_Bridge_P25/Analog_Bridge_P25-310764.ini
22528 ?        Ssl    0:00 /opt/310749/Analog_Bridge_DMR/Analog_Bridge /opt/310749/Analog_Bridge_DMR/Analog_Bridge_DMR-310749.ini
22548 ?        Ssl    0:00 /opt/310749/Analog_Bridge_P25/Analog_Bridge /opt/310749/Analog_Bridge_P25/Analog_Bridge_P25-310749.ini
--------------------------------------------------------------
 
--------------------------------------------------------------
10938 ?        Ssl    5:07 /opt/310747/MMDVM_Bridge/MMDVM_Bridge /opt/310747/MMDVM_Bridge/MMDVM_Bridge-310747.ini
24263 ?        Ssl    0:11 /opt/310749/MMDVM_Bridge/MMDVM_Bridge /opt/310749/MMDVM_Bridge/MMDVM_Bridge-310749.ini
24569 ?        Ssl    0:10 /opt/310756/MMDVM_Bridge/MMDVM_Bridge /opt/310756/MMDVM_Bridge/MMDVM_Bridge-310756.ini
24582 ?        Ssl    0:10 /opt/310764/MMDVM_Bridge/MMDVM_Bridge /opt/310764/MMDVM_Bridge/MMDVM_Bridge-310764.ini
--------------------------------------------------------------
 
--------------------------------------------------------------
17721 ?        Ssl    0:11 /opt/310747/P25Gateway/P25Gateway /opt/310747/P25Gateway/P25Gateway-310747.ini
17746 ?        Ssl    0:11 /opt/310756/P25Gateway/P25Gateway /opt/310756/P25Gateway/P25Gateway-310756.ini
17780 ?        Ssl    0:10 /opt/310764/P25Gateway/P25Gateway /opt/310764/P25Gateway/P25Gateway-310764.ini
22642 ?        Ssl    0:06 /opt/310749/P25Gateway/P25Gateway /opt/310749/P25Gateway/P25Gateway-310749.ini
--------------------------------------------------------------
 1474 ?        Ssl    4:59 /opt/310749/P25Reflector/P25Reflector /opt/310749/P25Reflector/P25Reflector-310749.ini
 8330 ?        Ssl    2:27 /opt/310756/P25Reflector/P25Reflector /opt/310756/P25Reflector/P25Reflector-310756.ini
11060 ?        Ssl    2:24 /opt/310747/P25Reflector/P25Reflector /opt/310747/P25Reflector/P25Reflector-310747.ini
14069 ?        Ssl    2:23 /opt/310764/P25Reflector/P25Reflector /opt/310764/P25Reflector/P25Reflector-310764.ini


bridging reflectors

John Azbill
 

Steve,

This is Dave K5NX in Houston Texas. 
  I would like to bridge our experimental IRLP 0070 reflector  to my YSF reflector #96014 .  Do you have any suggestions on how to do this and is there something with some step by step instructions?
We did help Rey build his Experimental IRLP reflector 0077 and he had someone else bridge his analog to digital bridge and it seems to work OK. We already have the easy stuff bridged IRLP, AllStar (HamVoip) and Echolink .

I you have any questions we could talk on the phone if needed.

Thanks David K5NX


IMPORANTE UPDATE: DMRlink, HBlink, HBlink3, DMRmonitor, HBmonitor, dmr_utils, dmr_utils3

Cort N0MJS <n0mjs@...>
 

radioid.net has updated their API for database exports.

Each time there is a change, the CSV format changes significantly and it causes me a fair amount of work to update 8 repos to use the new format. The CSV format is not preferred, but was the legacy format, and what I used. The preferred format is JSON. I have modified all of the following software packages to reflect the JSON formatted files. For most, this just means the sample configuration files, but for dmr_utils and dmr_utils3, starting with version 0.1.21, the database processing methods are now JSON based.

Any new downloads should all work correctly with the JSON loads. Please understand if you are using an older versions and/or branch of the others, and install new dmr_utils or dmr_utils3, you will have problems. The JSON parser cannot ingest CSV files.

I have been assured by radioid.net that the JSON format will not me messed with going forward – and if it is, updates are MUCH easier. If you want to know why, keep reading, otherwise you can just stop here :)



CSV files reference positional data. So we have to make assumptions about what information is in which column when processing and ingesting the data. The column headers are still only slightly useful since the names of those headers are not always consistent – capital letters vs. lowercase, etc. JSON is a better format because instead of the information being “positional”, it is “keyword” based. That is to say, each bit of information is labeled with a keywords that indicates what it is. I’ve chosen to follow radioid.net’s lead here and use JSON because that’s really the “right way” to do this, longer term.


0x49 DE N0MJS

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206


Unlinking from Reflector and not re-establishing link

Mike AE4ML
 

I'm not sure who else is having this problem and I'm entertaining better ways to do this. 
I have several remote sites where my Quantar repeaters aren't easily accessible.
I found out that if the internet burps or the reflector goes down and comes back up on the far end.
The  repeater looses its connectivity with the reflector and doesn't re-establish a
connection to the reflector.

I replicated the scenario here at home and started digging into it. Steve stated that the issue
is in the code for the p25gateway.  I found that a systemctl restart p25gateway resolved the problem.
How to run a watchdog to monitor this and re-establish the reflector connection.

I'm not sure how many other folks have run across this issue. I'm  hoping it more than just me. and maybe there is a better way to handle this .


I wrote a short script.
I run this script in the background.
#./watch-link 1>errors 2>info &

#!/bin/bash
#  Author Michael Lussier AE4ML
# 01 March 2019
# Description;  Reset P25Gateway in the event of a loss of connectivity with the reflector
#
if tail -F /var/log/mmdvm/P25Gateway-"$(date -d "0 day" "+%Y-%m-%d")".log | grep "unlinking"; then
   systemctl restart p25gateway.ini
   sleep 60
fi
#


Better status monitoring of dmrgateway (and other processes)

Doug Kingston
 

We have been using dmrgateway to front end a MMDVMHost based repeater using the Pi-Star distribution.  There is good monitoring of MMDVMHost and the connection between that an dmrgateway, but there is no explicit monitoring of the connection status of the various networks that dmrgateway could be trying to connect to.  The Pi-Star dashboard/admin webserver knows now to parse out Brandmeister connectivity on DMR Network 1 and query the BM server but that is no really reporting the connection status.  I would like to ask the developers what approach they would take to implement this monitoring and how they would suggest we export it out of the dmrgateway processes.

I can imagine a small HTTP server on assigned port that would return some status or even a simple socket from which you could read simple text status information.  This could be polled periodicly by the web interface or a monitoring service.  Do we want to consider this a generic approach to be applied to all our daemon processes?

Comments?
  -Doug-


Re: Pi image #dmrlink

Steve N4IRS
 

Sorry, there is no image.


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of ke2ems <ke2ems@...>
Sent: Friday, March 1, 2019 5:07:32 PM
To: main@DVSwitch.groups.io
Subject: [DVSwitch] Pi image #dmrlink
 
Do anyone have a working imiage they could share or point me to one. KE2EMS@... 

Thanks


Pi image #dmrlink

ke2ems
 

Do anyone have a working imiage they could share or point me to one. KE2EMS@... 

Thanks


Re: LAN address as FQDN in P25Hosts.txt?

Ray Harden
 

Missed your earlier msg ... until now ...
The environment includes:

Two MMDVM/Rpi's, one with P25 & DMR enabled radio is MSF5000 VHF; Second RPi  running the MMDVM/DVSwitch recently downloaded - configured.

Radios: XTS3000 UHF P25 enabled, Astro Spectra VHF P25 enabled, both have the TGs 31900 31901 set.

XTS3000 UHF is used to access a remote MSF5000 similarly configured for further testing.

LAN is 192.168.3.xx, both RPi's locally attached. Software running well, and considerable time running the port chains, .ini settings to get things this far.

"PTT ON" shows in log, attempting to transmit to erroneous IP address.  It comes down network addressing I think.

Thanks for your valuable time


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: Thursday, February 28, 2019 1:52:27 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
Ray,
Can you give me a better understanding of your configuration. hosts and LAN not .ini files.

On 2/28/2019 2:26 PM, Ray Harden wrote:
That was my first reaction too ... No way to know ... port 41000 is forwarded to 192. 168.3.130.  But no WAN access to modem.


Sent: Thursday, February 28, 2019 7:20:16 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
This is what I see in your reflector log:
M: 2019-02-28 04:34:22.684 Currently linked repeaters:
M: 2019-02-28 04:34:22.684     W0RAY      (97.125.17.237:42010) 2/120
M: 2019-02-28 04:35:58.149 Removing W0RAY      (97.125.17.237:42010) unlinked
M: 2019-02-28 04:35:58.155 Data received from an unknown source - 97.125.17.237:42010
M: 2019-02-28 04:35:58.155 Data
M: 2019-02-28 04:35:58.155 0000:  F1 57 30 52 41 59 20 20 20 20 20                   *.W0RAY     *
M: 2019-02-28 04:35:58.155 Data received from an unknown source - 97.125.17.237:42010
M: 2019-02-28 04:35:58.155 Data
M: 2019-02-28 04:35:58.156 0000:  F1 57 30 52 41 59 20 20 20 20 20                   *.W0RAY     *
M: 2019-02-28 04:36:22.794 No repeaters linked
M

W0RAY connected to the reflector from 97.125.17.237
W0RAY unlinked from the reflector
W0RAY sent more data to the reflector after it unlinked.

Usually that means the gateway requested a unlink but did not change to another IP address. So the next data the gateway sent the reflector said huh? Who is this source?
Now the question is where is the reflector getting 97.125.17.237 from?

Steve

On 2/28/2019 2:13 PM, Ray Harden wrote:
Both hosts now @ "mytest" ... only two terminals active are Reflector & Gateway

This time no 31900 Link message after revert to mytest host name

Sent: Thursday, February 28, 2019 7:02:39 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
No, don't revert anything yet. I'm asking that you try the same operation you did when you had 192.168.3.130 in the P25Host.ini

On 2/28/2019 2:00 PM, Ray Harden wrote:
Yes, from same P25 radio- select 31901 ... keyup & no response at Gateway, 39100 link disconnected

I think you wanted to revert from "mytest" back to 31900 host names - is that correct?

Sent: Thursday, February 28, 2019 12:49:21 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
If I remember, the error was after a disconnect. I assume from the log that you keyed up on another TG. Please do the same.

On 2/28/2019 1:47 PM, Ray Harden wrote:
Gateway displays "Linked at startup"

Polling

Sent: Thursday, February 28, 2019 12:30:26 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
OK good. Now test the gateway to reflector

On 2/28/2019 1:29 PM, Ray Harden wrote:
Ping sees 192.168.3.130

Sent: Thursday, February 28, 2019 6:13:15 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
One other thing, after you change the /etc/hosts file try to ping mytest.

On 2/28/2019 1:04 PM, Ray Harden wrote:
Yes, from P25Reflector log ... I attempted to include this log with the original post.

I edited /etc.hosts as you suggested, not sure of the format - added  192.168.3.130  31900. Not sure if this is the correct host name so please tell me if this what you suggested.

Sent: Thursday, February 28, 2019 10:33:35 AM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
OK, just for the heck of it so I can wrap my head around the problem. Add a entry in the /etc/hosts file for 192.168.3.130 Put the fqdn in P25Hosts.ini and retest.
Are you getting this" ( 97.125.17.237:42010) from the reflector log or from something else?
I know of no reason that 192.168.3.130 should not work.

Steve
 

On 2/28/2019 10:17 AM, harden.ray@... wrote:
P25Reflector<->P25Gateway<->AnalogBridgeP25<->AnalogBridgeDMR<->MMSVMHost <-> Brandmeister

I am close to finishing testing of "This Beast", software is working.  The P25 <=> DMR equipment is physically located in my lab in the same local area net- MMDVM-P25 Moto MSF5000  --  RPi -- TYT 2017-DMR

Substituting in P25Hosts.txt the LAN address 192.168.3.130 for the FDQN results in an erroneous IP address at the time to PTT on the P25 radio  ===  ( 97.125.17.237:42010) instead of the intended 192.168.3.130 as coded in P25Hosts.txt (attached).  (see attached P25Reflector.log)

Is it possible to use a LAN address as the FQDN in P25Hosts.txt?

For example:  31900 (tab) 192.168.3.130 (tab) 41000

   instead of:   31900 (tab) dvsw.org (tab) 41000 

The DVSWITCH software is running at address 192.168.3.4 so it seems the LAN should support what I am tying to do.  Eventually I will provide the P25Hosts 31900 entry with a proper FQDN.

Thanks to all support this effort.
 








Re: looking at my options

Steve N4IRS
 

I believe you are correct. That is one for Jonathan or some enterprising person to modify the gateway to retry. Or, some enterprising person to write a script that scrapes the GW log and restarts the GW after a period of time.

On 2/28/2019 3:11 PM, Mike AE4ML wrote:
2 gateways down and 2 to go....

Not to add another concern. Re-connections..
I have noticed that if the Reflector goes down then that is it. There doesn't appear to be a mechanism in place to attempt a  reconnect to the client  or the gateway at a set period of time.  if there is an issue and I take down the reflector or drop the internet connection then the only fix is to restart the gateway service to bring it back. 

Any thoughts


Re: looking at my options

Steve N4IRS
 

OK

On 2/28/2019 3:13 PM, Mike AE4ML wrote:
I fat fingered it in note pad.
that list was supposed to be 10282  - 10285


Re: looking at my options

Mike AE4ML
 

I fat fingered it in note pad.
that list was supposed to be 10282  - 10285


Re: looking at my options

Mike AE4ML
 

2 gateways down and 2 to go....

Not to add another concern. Re-connections..
I have noticed that if the Reflector goes down then that is it. There doesn't appear to be a mechanism in place to attempt a  reconnect to the client  or the gateway at a set period of time.  if there is an issue and I take down the reflector or drop the internet connection then the only fix is to restart the gateway service to bring it back. 

Any thoughts


Re: looking at my options

Steve N4IRS
 

I just noticed this:

On 2/28/2019 1:44 PM, Mike AE4ML wrote:
#Spotsylvania 442.400
10282           ec2-34-221-180-45.us-west-2.compute.amazonaws.com       41000
# Madison 147.030
10282           ec2-34-221-180-45.us-west-2.compute.amazonaws.com       41010
# Madison 442.575
10283        ec2-34-221-180-45.us-west-2.compute.amazonaws.com       41020
# Fredericksburg 442.850
10284           ec2-34-221-180-45.us-west-2.compute.amazonaws.com       41030
#


Re: looking at my options

Steve N4IRS
 

Never dull. ;)
I'll try to connect to REF2

On 2/28/2019 3:04 PM, Mike AE4ML wrote:
I dont know whats up Steve,
I just did a systemctl restart on GW2  and tried to connect a pi-star mdvm and it has connected . GW 2 is working.

GW1 RF1
M: 2019-02-28 20:00:45.379 Removing AE4ML      (50.205.158.209:42010) disappeared
M: 2019-02-28 20:01:35.673 Currently linked repeaters:
M: 2019-02-28 20:01:35.673     AE4ML      (127.0.0.1:42000) 1/120
M: 2019-02-28 20:01:35.673     DVSWITCH   (208.35.139.12:52010) 2/120
M: 2019-02-28 20:01:35.673     AE4ML      (50.205.158.209:1255) 0/120

GW2 RF2
M: 2019-02-28 19:58:25.663 Adding AE4ML      (127.0.0.1:42110)
M: 2019-02-28 19:58:55.453 Adding AE4ML      (50.205.158.209:42010)


Re: looking at my options

Steve N4IRS
 

REF1 is listening on 41000 it will reply to the connecting GW on the localport defined in the GW .ini file (42010)
REF2 is listening on 41010 it will reply to the connecting GW on the localport defined in the GW .ini file (42110)

The repeater ports do not matter except where 2 gateways are running on the same machine.


On 2/28/2019 2:54 PM, Mike AE4ML wrote:
Please correct me if I'm wrong here.
Each reflector talks to P25gateway via 2 UDP ports . If I have one reflector (REF 1)  listening 41000 and talking to the gateway 31020, 42010 then we have Reflector  2  (REF2)  listening 41010   and talking  to the gateway 31120 and 42110 .

If I shutdown GW 1 and tell gateway 2 to connect to REF 2 dont we have to adjust the  ports that they are using to allow communications ?


Re: looking at my options

Mike AE4ML
 

Please correct me if I'm wrong here.
Each reflector talks to P25gateway via 2 UDP ports . If I have one reflector (REF 1)  listening 41000 and talking to the gateway 31020, 42010 then we have Reflector  2  (REF2)  listening 41010   and talking  to the gateway 31120 and 42110 .

If I shutdown GW 1 and tell gateway 2 to connect to REF 2 dont we have to adjust the  ports that they are using to allow communications ?


Re: LAN address as FQDN in P25Hosts.txt?

Steve N4IRS
 

Ray,
Can you give me a better understanding of your configuration. hosts and LAN not .ini files.

On 2/28/2019 2:26 PM, Ray Harden wrote:
That was my first reaction too ... No way to know ... port 41000 is forwarded to 192. 168.3.130.  But no WAN access to modem.


Sent: Thursday, February 28, 2019 7:20:16 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
This is what I see in your reflector log:
M: 2019-02-28 04:34:22.684 Currently linked repeaters:
M: 2019-02-28 04:34:22.684     W0RAY      (97.125.17.237:42010) 2/120
M: 2019-02-28 04:35:58.149 Removing W0RAY      (97.125.17.237:42010) unlinked
M: 2019-02-28 04:35:58.155 Data received from an unknown source - 97.125.17.237:42010
M: 2019-02-28 04:35:58.155 Data
M: 2019-02-28 04:35:58.155 0000:  F1 57 30 52 41 59 20 20 20 20 20                   *.W0RAY     *
M: 2019-02-28 04:35:58.155 Data received from an unknown source - 97.125.17.237:42010
M: 2019-02-28 04:35:58.155 Data
M: 2019-02-28 04:35:58.156 0000:  F1 57 30 52 41 59 20 20 20 20 20                   *.W0RAY     *
M: 2019-02-28 04:36:22.794 No repeaters linked
M

W0RAY connected to the reflector from 97.125.17.237
W0RAY unlinked from the reflector
W0RAY sent more data to the reflector after it unlinked.

Usually that means the gateway requested a unlink but did not change to another IP address. So the next data the gateway sent the reflector said huh? Who is this source?
Now the question is where is the reflector getting 97.125.17.237 from?

Steve

On 2/28/2019 2:13 PM, Ray Harden wrote:
Both hosts now @ "mytest" ... only two terminals active are Reflector & Gateway

This time no 31900 Link message after revert to mytest host name

Sent: Thursday, February 28, 2019 7:02:39 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
No, don't revert anything yet. I'm asking that you try the same operation you did when you had 192.168.3.130 in the P25Host.ini

On 2/28/2019 2:00 PM, Ray Harden wrote:
Yes, from same P25 radio- select 31901 ... keyup & no response at Gateway, 39100 link disconnected

I think you wanted to revert from "mytest" back to 31900 host names - is that correct?

Sent: Thursday, February 28, 2019 12:49:21 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
If I remember, the error was after a disconnect. I assume from the log that you keyed up on another TG. Please do the same.

On 2/28/2019 1:47 PM, Ray Harden wrote:
Gateway displays "Linked at startup"

Polling

Sent: Thursday, February 28, 2019 12:30:26 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
OK good. Now test the gateway to reflector

On 2/28/2019 1:29 PM, Ray Harden wrote:
Ping sees 192.168.3.130

Sent: Thursday, February 28, 2019 6:13:15 PM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
One other thing, after you change the /etc/hosts file try to ping mytest.

On 2/28/2019 1:04 PM, Ray Harden wrote:
Yes, from P25Reflector log ... I attempted to include this log with the original post.

I edited /etc.hosts as you suggested, not sure of the format - added  192.168.3.130  31900. Not sure if this is the correct host name so please tell me if this what you suggested.

Sent: Thursday, February 28, 2019 10:33:35 AM
Subject: Re: [DVSwitch] LAN address as FQDN in P25Hosts.txt?
 
OK, just for the heck of it so I can wrap my head around the problem. Add a entry in the /etc/hosts file for 192.168.3.130 Put the fqdn in P25Hosts.ini and retest.
Are you getting this" ( 97.125.17.237:42010) from the reflector log or from something else?
I know of no reason that 192.168.3.130 should not work.

Steve
 

On 2/28/2019 10:17 AM, harden.ray@... wrote:
P25Reflector<->P25Gateway<->AnalogBridgeP25<->AnalogBridgeDMR<->MMSVMHost <-> Brandmeister

I am close to finishing testing of "This Beast", software is working.  The P25 <=> DMR equipment is physically located in my lab in the same local area net- MMDVM-P25 Moto MSF5000  --  RPi -- TYT 2017-DMR

Substituting in P25Hosts.txt the LAN address 192.168.3.130 for the FDQN results in an erroneous IP address at the time to PTT on the P25 radio  ===  ( 97.125.17.237:42010) instead of the intended 192.168.3.130 as coded in P25Hosts.txt (attached).  (see attached P25Reflector.log)

Is it possible to use a LAN address as the FQDN in P25Hosts.txt?

For example:  31900 (tab) 192.168.3.130 (tab) 41000

   instead of:   31900 (tab) dvsw.org (tab) 41000 

The DVSWITCH software is running at address 192.168.3.4 so it seems the LAN should support what I am tying to do.  Eventually I will provide the P25Hosts 31900 entry with a proper FQDN.

Thanks to all support this effort.
 








Re: looking at my options

Steve N4IRS
 

What I have yet to understand is how a gateway will stop a reflector from operating unless there is a port conflict.

On 2/28/2019 2:44 PM, Mike AE4ML wrote:
gateway 2 stopped
systemctl stop p25gateway-310749

I dont expect any problems with gateway 1 ,. Its been rock solid

6501 - 6520 of 9882