Date   
Re: Help linking P25 to DMR

Steve N4IRS
 

Jake,
A DMR to P25 bridge will look like this:
BM <-> MB_DMR <-> AB_DMR <-> AB_P25 <-> MB_P25 <-> P25Gateway <-> P25Reflector

You can use one instance of MB for both DMR and P25
The DMR mode of MB will feed the AB for DMR
The P25 mode will feed AB for P25
You will need to have two instances of AB

We need to see the traffic flow all the way through the bridge. Start with clean logs of ALL the instances.
Bring up the programs and transmit on DMR ONE time.
Stop all the programs.
Show each of the following logs:
MB_DMR
AB_DMR
AB_P25
MB_P25

Please keep each log in a seperate file. They should be plain text files.
We may then request copies of a config file. Same requirement, a plain text file.

This is a port map of a DMR <-> P25 bridge.
<https://dvswitch.groups.io/g/main/wiki/Port-Diagram>

Steve N4IRS



On 10/16/2019 3:47 PM, Jake Litwin wrote:
Having a some difficulty getting this going. MMDVM Bridge log shows the P25 traffic and the traffic coming from DMR and the P25Reflector log shows the P25 traffic nothing comes out the DMR side and no traffic from DMR comes out the P25 side. I've attached the log files and my configs. Would someone be able to take a look and let me know if I missed something?

Re: Help linking P25 to DMR

Jake Litwin
 

I forgot to attach the P25 Gateway config and it's log

Re: Help linking P25 to DMR

Jake Litwin
 

Having a some difficulty getting this going. MMDVM Bridge log shows the P25 traffic and the traffic coming from DMR and the P25Reflector log shows the P25 traffic nothing comes out the DMR side and no traffic from DMR comes out the P25 side. I've attached the log files and my configs. Would someone be able to take a look and let me know if I missed something?

Re: DMR to Allstar "blocked"

Steve N4IRS
 

Chris,

minTxTimeMS will keep a short transmission from triggering the “hot spot looping block” setting it to 2000 ms (2 seconds) is minimum to try to defeat the blocker. More is better, until it’s too long. 2500 to 3000 should be good.

 

Steve N4IRS.

 

From: Chris K7AZ via Groups.Io
Sent: Tuesday, October 15, 2019 2:14 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMR to Allstar "blocked"

 

For my similiar Blocked problem, I was told to set Min TX to 2500 so is 3000 more better?

 

I'm attempting to transcode a Monday evening ASL net and have no control over guys short keying but could reduce their hang tails from 2 sec to 1/2 sec....?

 

Thank you,

Chris K7AZ 

 

 

 

Sent from my Verizon, Samsung Galaxy smartphone

 

-------- Original message --------

From: Adam Liette <w8flh@...>

Date: 10/12/19 12:08 (GMT-08:00)

To: main@DVSwitch.groups.io

Subject: Re: [DVSwitch] DMR to Allstar "blocked"

 

Thank you!

From: main@... <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: Saturday, October 12, 2019 2:12:29 PM
To: main@dvswitch.groups.io <main@dvswitch.groups.io>
Subject: Re: [DVSwitch] DMR to Allstar "blocked"

 

In Analog_Bridge.ini set:

minTxTimeMS = 3000 it will help.

Steve N4IRS

Sent by smoke signal (AT&T)

 

From: main@... <main@DVSwitch.groups.io> on behalf of w8flh@... <w8flh@...>
Sent: Saturday, October 12, 2019 1:40:00 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: [DVSwitch] DMR to Allstar "blocked"

 

Hello. I've been experimenting with DVSwitch for a very short time, and it's working for the most part. I'm bridging a stand-alone Allstar node (no radio) to a Brandmeister talkgroup.

Enter my issue... My bridge is announcing "Blocked" and "User Blocked" on occasion. It's audible on the Allstar side, but not DMR Would this be due to frequent key ups, and being blocked on Brandmeister? I know the blocks usually last an hour or so, but it's annoying to hear the announcement. Ha. Is there any sort of kerchunk delay that would avoid this?

Thanks,

Adam, W8FLH
Greenville, Ohio

 

Re: DMR to Allstar "blocked"

Chris K7AZ
 

For my similiar Blocked problem, I was told to set Min TX to 2500 so is 3000 more better?

I'm attempting to transcode a Monday evening ASL net and have no control over guys short keying but could reduce their hang tails from 2 sec to 1/2 sec....?

Thank you,
Chris K7AZ 



Sent from my Verizon, Samsung Galaxy smartphone

-------- Original message --------
From: Adam Liette <w8flh@...>
Date: 10/12/19 12:08 (GMT-08:00)
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMR to Allstar "blocked"

Thank you!

From: main@... <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: Saturday, October 12, 2019 2:12:29 PM
To: main@dvswitch.groups.io <main@dvswitch.groups.io>
Subject: Re: [DVSwitch] DMR to Allstar "blocked"
 
In Analog_Bridge.ini set:
minTxTimeMS = 3000 it will help.

Steve N4IRS

Sent by smoke signal (AT&T)


From: main@... <main@DVSwitch.groups.io> on behalf of w8flh@... <w8flh@...>
Sent: Saturday, October 12, 2019 1:40:00 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: [DVSwitch] DMR to Allstar "blocked"
 

Hello. I've been experimenting with DVSwitch for a very short time, and it's working for the most part. I'm bridging a stand-alone Allstar node (no radio) to a Brandmeister talkgroup.

Enter my issue... My bridge is announcing "Blocked" and "User Blocked" on occasion. It's audible on the Allstar side, but not DMR Would this be due to frequent key ups, and being blocked on Brandmeister? I know the blocks usually last an hour or so, but it's annoying to hear the announcement. Ha. Is there any sort of kerchunk delay that would avoid this?

Thanks,

Adam, W8FLH
Greenville, Ohio

Re: Crosslink ircddbgateways

SP2ONG Waldek
 

Thank you Steve for the hint

Re: Crosslink ircddbgateways

Steve N4IRS
 

2 copies of MMDVM_Bridge. Each MB connected to ircddbgateway Cross connect the D-Star in DVSwitch.ini(s)


On 10/13/19 10:05 AM, Waldek SP2ONG wrote:
I would like bridge reflector D-Star REFxxx with XLXreflecor use DPlus protocol conenction between REFxxx and XLXxxx

I have idea connect ircddbgatewy to D-Star REFxxx and run sencond ircddbgatewy which connect to XLXxxx reflector use DPlus protocol.

REFxxx reflector (DPlus)     <--> ircddbgateway  <-     ??????   ->  ircddbgateway -> (DPlus) XLXxxx reflector

but how to interconenct ircddbgateways  ?

Crosslink ircddbgateways

SP2ONG Waldek
 

I would like bridge reflector D-Star REFxxx with XLXreflecor use DPlus protocol conenction between REFxxx and XLXxxx

I have idea connect ircddbgatewy to D-Star REFxxx and run sencond ircddbgatewy which connect to XLXxxx reflector use DPlus protocol.

REFxxx reflector (DPlus)     <--> ircddbgateway  <-     ??????   ->  ircddbgateway -> (DPlus) XLXxxx reflector

but how to interconenct ircddbgateways  ?

Re: Switch Between BM and TGIF

Steve N4IRS
 

Pretty much like you change modes. Build two MMDVM.ini One for BM and one for TGIF. have the script copy the BM or TGIF version over the running MMDVM_Bridge.ini and restart MMDVM_Bridge.

On 10/13/19 9:10 AM, Tom Corcoran wrote:
Right now, I change address in MB to switch DMR networks. Is there any way to use a macro to the same function?
--
Tx ... Tom VE3NY

Switch Between BM and TGIF

Tom Corcoran
 

Right now, I change address in MB to switch DMR networks. Is there any way to use a macro to the same function?
--
Tx ... Tom VE3NY

Re: DMR to Allstar "blocked"

Adam Liette
 

Thank you!


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: Saturday, October 12, 2019 2:12:29 PM
To: main@dvswitch.groups.io <main@dvswitch.groups.io>
Subject: Re: [DVSwitch] DMR to Allstar "blocked"
 
In Analog_Bridge.ini set:
minTxTimeMS = 3000 it will help.

Steve N4IRS

Sent by smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of w8flh@... <w8flh@...>
Sent: Saturday, October 12, 2019 1:40:00 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: [DVSwitch] DMR to Allstar "blocked"
 

Hello. I've been experimenting with DVSwitch for a very short time, and it's working for the most part. I'm bridging a stand-alone Allstar node (no radio) to a Brandmeister talkgroup.

Enter my issue... My bridge is announcing "Blocked" and "User Blocked" on occasion. It's audible on the Allstar side, but not DMR. Would this be due to frequent key ups, and being blocked on Brandmeister? I know the blocks usually last an hour or so, but it's annoying to hear the announcement. Ha. Is there any sort of kerchunk delay that would avoid this?

Thanks,

Adam, W8FLH
Greenville, Ohio

Re: DMR to Allstar "blocked"

Steve N4IRS
 

In Analog_Bridge.ini set:
minTxTimeMS = 3000 it will help.

Steve N4IRS

Sent by smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of w8flh@... <w8flh@...>
Sent: Saturday, October 12, 2019 1:40:00 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: [DVSwitch] DMR to Allstar "blocked"
 

Hello. I've been experimenting with DVSwitch for a very short time, and it's working for the most part. I'm bridging a stand-alone Allstar node (no radio) to a Brandmeister talkgroup.

Enter my issue... My bridge is announcing "Blocked" and "User Blocked" on occasion. It's audible on the Allstar side, but not DMR. Would this be due to frequent key ups, and being blocked on Brandmeister? I know the blocks usually last an hour or so, but it's annoying to hear the announcement. Ha. Is there any sort of kerchunk delay that would avoid this?

Thanks,

Adam, W8FLH
Greenville, Ohio

DMR to Allstar "blocked"

Adam Liette
 

Hello. I've been experimenting with DVSwitch for a very short time, and it's working for the most part. I'm bridging a stand-alone Allstar node (no radio) to a Brandmeister talkgroup.

Enter my issue... My bridge is announcing "Blocked" and "User Blocked" on occasion. It's audible on the Allstar side, but not DMR. Would this be due to frequent key ups, and being blocked on Brandmeister? I know the blocks usually last an hour or so, but it's annoying to hear the announcement. Ha. Is there any sort of kerchunk delay that would avoid this?

Thanks,

Adam, W8FLH
Greenville, Ohio

Re: Bridging a P25Reflector and a YSFReflector?

Jake Litwin
 

Thanks Steve for all of the guidance through this! Thank you too Adrian for the feedback and pointing me back towards my ini configs. Yeah was my own dumb fault for trying to change up ports and then losing track in the process.

On Fri, Oct 11, 2019 at 1:12 PM Steve N4IRS <szingman@...> wrote:
No,
The gateway logging leaves a lot to be desired. Just look for startup connect and possible disconnect.

On 10/11/19 2:07 PM, Jake Litwin wrote:
So this is my own dumb &$& fault.. I started changing ports because I originally thought 41000 was being used by the YSF reflector I have installed. It's not. I put both the P25Reflector.ini and P25Gateway.ini files back to their original states. Yes 41000 is the port Reflector should be using.

Reflector Log:

M: 2019-10-11 18:01:42.055 Adding N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:01:46.066 Currently linked repeaters:
M: 2019-10-11 18:01:46.066     N9KRG      (127.0.0.1:42010) 4/120
M: 2019-10-11 18:01:46.066     N9KRG      (174.253.82.128:42722) 3/120
M: 2019-10-11 18:01:57.349 Transmission started from N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:01:57.374 Transmission from N9KRG at N9KRG      to TG 420
M: 2019-10-11 18:01:59.484 Received end of transmission
M: 2019-10-11 18:02:10.898 Transmission started from N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:02:10.908 Transmission from N9KRG at N9KRG      to TG 420
M: 2019-10-11 18:02:12.826 Received end of transmission

Gateway Log:
M: 2019-10-11 17:14:04.641 Linked at startup to reflector 420
W: 2019-10-11 17:16:04.647 No response from 420, unlinking
I: 2019-10-11 17:19:50.623 Opening P25 network connection
I: 2019-10-11 17:19:50.623 Opening P25 network connection
I: 2019-10-11 17:19:50.893 Loaded 13 P25 reflectors
I: 2019-10-11 17:19:50.893 Loaded P25 parrot (TG10)
I: 2019-10-11 17:19:50.934 Loaded 145704 Ids to the callsign lookup table
M: 2019-10-11 17:19:50.934 Starting P25Gateway-20180409
I: 2019-10-11 17:19:50.934 Started the DMR Id lookup reload thread
M: 2019-10-11 17:19:50.934 Linked at startup to reflector 420

I think I'm all set right? Or should I be seeing some activity on the Gateway log for traffic?


On Fri, Oct 11, 2019 at 11:56 AM Adrian Fewster <vk4tux@...> wrote:

42020 UDP has nothing to do with the P25Reflector, it is the gateway comms port along with 32010 between P25Gateway and MMDVM_Bridge.


Check the P25 Network gateway port matches the local port between P25Gateway.ini and MMDVM_Bridge.ini and vice versa.


Adrian ... vk4tux


On 12/10/19 2:31 am, Jake Litwin wrote:
Changing the P25Hosts file to 42020 would not connect to the reflector. Keeping it on 41000 gateway connects to the reflector but that's where I get

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*
 

I did a port check and Reflector is listening on 41000

root@SuperFreq:/var/log/mmdvm# sudo lsof -i:41000
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Reflec 20357 root    4u  IPv4 1373306      0t0  UDP *:41000
root@SuperFreq:/var/log/mmdvm# sudo lsof -i:42020
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Gatewa 21266 root    4u  IPv4 1378574      0t0  UDP *:42020


On Fri, Oct 11, 2019 at 7:31 AM Steve N4IRS <szingman@...> wrote:
So,
The reflector startup looks normal but I expect the gateway will timeout since it is trying to connect to reflector 420 on port UDP 41000 as reflected in p25hosts. The P25Reflector is listening on UDP port 42020. So, the Gateway never connects or logs into the reflector. The error you get:

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*


Is caused by the gateway sending data but not logged into the the reflector. Change p25hosts to reflect the port the reflector is actually listening on. Since you can connect to the reflector from your MMDVMHost:

M: 2019-10-11 01:27:49.733 Adding N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.375 Transmission started from N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.385 Transmission from N9KRG at N9KRG      to TG 420


I would expect the published UDP port of 42020 is correct.

Steve N4IRS

On 10/10/19 10:45 PM, Jake Litwin wrote:
hmmm. This is all I"m seeing on the live output for gateway

root@SuperFreq:/opt/P25Gateway# ./P25Gateway
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.324 Loaded 13 P25 reflectors
I: 2019-10-11 02:44:53.324 Loaded P25 parrot (TG10)
I: 2019-10-11 02:44:53.359 Loaded 145619 Ids to the callsign lookup table
M: 2019-10-11 02:44:53.359 Starting P25Gateway-20180409
M: 2019-10-11 02:44:53.359 Linked at startup to reflector 420
I: 2019-10-11 02:44:53.359 Started the DMR Id lookup reload thread


Re: Bridging a P25Reflector and a YSFReflector?

Steve N4IRS
 

No,
The gateway logging leaves a lot to be desired. Just look for startup connect and possible disconnect.

On 10/11/19 2:07 PM, Jake Litwin wrote:
So this is my own dumb &$& fault.. I started changing ports because I originally thought 41000 was being used by the YSF reflector I have installed. It's not. I put both the P25Reflector.ini and P25Gateway.ini files back to their original states. Yes 41000 is the port Reflector should be using.

Reflector Log:

M: 2019-10-11 18:01:42.055 Adding N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:01:46.066 Currently linked repeaters:
M: 2019-10-11 18:01:46.066     N9KRG      (127.0.0.1:42010) 4/120
M: 2019-10-11 18:01:46.066     N9KRG      (174.253.82.128:42722) 3/120
M: 2019-10-11 18:01:57.349 Transmission started from N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:01:57.374 Transmission from N9KRG at N9KRG      to TG 420
M: 2019-10-11 18:01:59.484 Received end of transmission
M: 2019-10-11 18:02:10.898 Transmission started from N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:02:10.908 Transmission from N9KRG at N9KRG      to TG 420
M: 2019-10-11 18:02:12.826 Received end of transmission

Gateway Log:
M: 2019-10-11 17:14:04.641 Linked at startup to reflector 420
W: 2019-10-11 17:16:04.647 No response from 420, unlinking
I: 2019-10-11 17:19:50.623 Opening P25 network connection
I: 2019-10-11 17:19:50.623 Opening P25 network connection
I: 2019-10-11 17:19:50.893 Loaded 13 P25 reflectors
I: 2019-10-11 17:19:50.893 Loaded P25 parrot (TG10)
I: 2019-10-11 17:19:50.934 Loaded 145704 Ids to the callsign lookup table
M: 2019-10-11 17:19:50.934 Starting P25Gateway-20180409
I: 2019-10-11 17:19:50.934 Started the DMR Id lookup reload thread
M: 2019-10-11 17:19:50.934 Linked at startup to reflector 420

I think I'm all set right? Or should I be seeing some activity on the Gateway log for traffic?


On Fri, Oct 11, 2019 at 11:56 AM Adrian Fewster <vk4tux@...> wrote:

42020 UDP has nothing to do with the P25Reflector, it is the gateway comms port along with 32010 between P25Gateway and MMDVM_Bridge.


Check the P25 Network gateway port matches the local port between P25Gateway.ini and MMDVM_Bridge.ini and vice versa.


Adrian ... vk4tux


On 12/10/19 2:31 am, Jake Litwin wrote:
Changing the P25Hosts file to 42020 would not connect to the reflector. Keeping it on 41000 gateway connects to the reflector but that's where I get

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*
 

I did a port check and Reflector is listening on 41000

root@SuperFreq:/var/log/mmdvm# sudo lsof -i:41000
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Reflec 20357 root    4u  IPv4 1373306      0t0  UDP *:41000
root@SuperFreq:/var/log/mmdvm# sudo lsof -i:42020
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Gatewa 21266 root    4u  IPv4 1378574      0t0  UDP *:42020


On Fri, Oct 11, 2019 at 7:31 AM Steve N4IRS <szingman@...> wrote:
So,
The reflector startup looks normal but I expect the gateway will timeout since it is trying to connect to reflector 420 on port UDP 41000 as reflected in p25hosts. The P25Reflector is listening on UDP port 42020. So, the Gateway never connects or logs into the reflector. The error you get:

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*


Is caused by the gateway sending data but not logged into the the reflector. Change p25hosts to reflect the port the reflector is actually listening on. Since you can connect to the reflector from your MMDVMHost:

M: 2019-10-11 01:27:49.733 Adding N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.375 Transmission started from N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.385 Transmission from N9KRG at N9KRG      to TG 420


I would expect the published UDP port of 42020 is correct.

Steve N4IRS

On 10/10/19 10:45 PM, Jake Litwin wrote:
hmmm. This is all I"m seeing on the live output for gateway

root@SuperFreq:/opt/P25Gateway# ./P25Gateway
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.324 Loaded 13 P25 reflectors
I: 2019-10-11 02:44:53.324 Loaded P25 parrot (TG10)
I: 2019-10-11 02:44:53.359 Loaded 145619 Ids to the callsign lookup table
M: 2019-10-11 02:44:53.359 Starting P25Gateway-20180409
M: 2019-10-11 02:44:53.359 Linked at startup to reflector 420
I: 2019-10-11 02:44:53.359 Started the DMR Id lookup reload thread


Re: Bridging a P25Reflector and a YSFReflector?

Jake Litwin
 

So this is my own dumb &$& fault.. I started changing ports because I originally thought 41000 was being used by the YSF reflector I have installed. It's not. I put both the P25Reflector.ini and P25Gateway.ini files back to their original states. Yes 41000 is the port Reflector should be using.

Reflector Log:

M: 2019-10-11 18:01:42.055 Adding N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:01:46.066 Currently linked repeaters:
M: 2019-10-11 18:01:46.066     N9KRG      (127.0.0.1:42010) 4/120
M: 2019-10-11 18:01:46.066     N9KRG      (174.253.82.128:42722) 3/120
M: 2019-10-11 18:01:57.349 Transmission started from N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:01:57.374 Transmission from N9KRG at N9KRG      to TG 420
M: 2019-10-11 18:01:59.484 Received end of transmission
M: 2019-10-11 18:02:10.898 Transmission started from N9KRG      (174.253.82.128:42722)
M: 2019-10-11 18:02:10.908 Transmission from N9KRG at N9KRG      to TG 420
M: 2019-10-11 18:02:12.826 Received end of transmission

Gateway Log:
M: 2019-10-11 17:14:04.641 Linked at startup to reflector 420
W: 2019-10-11 17:16:04.647 No response from 420, unlinking
I: 2019-10-11 17:19:50.623 Opening P25 network connection
I: 2019-10-11 17:19:50.623 Opening P25 network connection
I: 2019-10-11 17:19:50.893 Loaded 13 P25 reflectors
I: 2019-10-11 17:19:50.893 Loaded P25 parrot (TG10)
I: 2019-10-11 17:19:50.934 Loaded 145704 Ids to the callsign lookup table
M: 2019-10-11 17:19:50.934 Starting P25Gateway-20180409
I: 2019-10-11 17:19:50.934 Started the DMR Id lookup reload thread
M: 2019-10-11 17:19:50.934 Linked at startup to reflector 420

I think I'm all set right? Or should I be seeing some activity on the Gateway log for traffic?


On Fri, Oct 11, 2019 at 11:56 AM Adrian Fewster <vk4tux@...> wrote:

42020 UDP has nothing to do with the P25Reflector, it is the gateway comms port along with 32010 between P25Gateway and MMDVM_Bridge.


Check the P25 Network gateway port matches the local port between P25Gateway.ini and MMDVM_Bridge.ini and vice versa.


Adrian ... vk4tux


On 12/10/19 2:31 am, Jake Litwin wrote:
Changing the P25Hosts file to 42020 would not connect to the reflector. Keeping it on 41000 gateway connects to the reflector but that's where I get

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*
 

I did a port check and Reflector is listening on 41000

root@SuperFreq:/var/log/mmdvm# sudo lsof -i:41000
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Reflec 20357 root    4u  IPv4 1373306      0t0  UDP *:41000
root@SuperFreq:/var/log/mmdvm# sudo lsof -i:42020
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Gatewa 21266 root    4u  IPv4 1378574      0t0  UDP *:42020


On Fri, Oct 11, 2019 at 7:31 AM Steve N4IRS <szingman@...> wrote:
So,
The reflector startup looks normal but I expect the gateway will timeout since it is trying to connect to reflector 420 on port UDP 41000 as reflected in p25hosts. The P25Reflector is listening on UDP port 42020. So, the Gateway never connects or logs into the reflector. The error you get:

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*


Is caused by the gateway sending data but not logged into the the reflector. Change p25hosts to reflect the port the reflector is actually listening on. Since you can connect to the reflector from your MMDVMHost:

M: 2019-10-11 01:27:49.733 Adding N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.375 Transmission started from N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.385 Transmission from N9KRG at N9KRG      to TG 420


I would expect the published UDP port of 42020 is correct.

Steve N4IRS

On 10/10/19 10:45 PM, Jake Litwin wrote:
hmmm. This is all I"m seeing on the live output for gateway

root@SuperFreq:/opt/P25Gateway# ./P25Gateway
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.324 Loaded 13 P25 reflectors
I: 2019-10-11 02:44:53.324 Loaded P25 parrot (TG10)
I: 2019-10-11 02:44:53.359 Loaded 145619 Ids to the callsign lookup table
M: 2019-10-11 02:44:53.359 Starting P25Gateway-20180409
M: 2019-10-11 02:44:53.359 Linked at startup to reflector 420
I: 2019-10-11 02:44:53.359 Started the DMR Id lookup reload thread

Re: Bridging a P25Reflector and a YSFReflector?

Adrian Fewster <vk4tux@...>
 

42020 UDP has nothing to do with the P25Reflector, it is the gateway comms port along with 32010 between P25Gateway and MMDVM_Bridge.


Check the P25 Network gateway port matches the local port between P25Gateway.ini and MMDVM_Bridge.ini and vice versa.


Adrian ... vk4tux


On 12/10/19 2:31 am, Jake Litwin wrote:
Changing the P25Hosts file to 42020 would not connect to the reflector. Keeping it on 41000 gateway connects to the reflector but that's where I get

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*
 

I did a port check and Reflector is listening on 41000

root@SuperFreq:/var/log/mmdvm# sudo lsof -i:41000
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Reflec 20357 root    4u  IPv4 1373306      0t0  UDP *:41000
root@SuperFreq:/var/log/mmdvm# sudo lsof -i:42020
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Gatewa 21266 root    4u  IPv4 1378574      0t0  UDP *:42020


On Fri, Oct 11, 2019 at 7:31 AM Steve N4IRS <szingman@...> wrote:
So,
The reflector startup looks normal but I expect the gateway will timeout since it is trying to connect to reflector 420 on port UDP 41000 as reflected in p25hosts. The P25Reflector is listening on UDP port 42020. So, the Gateway never connects or logs into the reflector. The error you get:

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*


Is caused by the gateway sending data but not logged into the the reflector. Change p25hosts to reflect the port the reflector is actually listening on. Since you can connect to the reflector from your MMDVMHost:

M: 2019-10-11 01:27:49.733 Adding N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.375 Transmission started from N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.385 Transmission from N9KRG at N9KRG      to TG 420


I would expect the published UDP port of 42020 is correct.

Steve N4IRS

On 10/10/19 10:45 PM, Jake Litwin wrote:
hmmm. This is all I"m seeing on the live output for gateway

root@SuperFreq:/opt/P25Gateway# ./P25Gateway
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.324 Loaded 13 P25 reflectors
I: 2019-10-11 02:44:53.324 Loaded P25 parrot (TG10)
I: 2019-10-11 02:44:53.359 Loaded 145619 Ids to the callsign lookup table
M: 2019-10-11 02:44:53.359 Starting P25Gateway-20180409
M: 2019-10-11 02:44:53.359 Linked at startup to reflector 420
I: 2019-10-11 02:44:53.359 Started the DMR Id lookup reload thread

Re: Bridging a P25Reflector and a YSFReflector?

Steve N4IRS
 

Well,
I see the results of lsof. But this is what you posted as p25reflector.txt

[General]
Daemon=0

[Id Lookup]
Name=/var/lib/mmdvm/DMRIds.dat
Time=24

[Log]
# Logging levels, 0=No logging, 1=Debug, 2=Message, 3=Info, 4=Warning, 5=Error, 6=Fatal
DisplayLevel=1
FileLevel=2
FilePath=/var/log/mmdvm
FileRoot=P25Reflector

[Network]
Port=42020
Debug=0

On 10/11/19 12:31 PM, Jake Litwin wrote:
Changing the P25Hosts file to 42020 would not connect to the reflector. Keeping it on 41000 gateway connects to the reflector but that's where I get

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*
 

I did a port check and Reflector is listening on 41000

root@SuperFreq:/var/log/mmdvm# sudo lsof -i:41000
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Reflec 20357 root    4u  IPv4 1373306      0t0  UDP *:41000
root@SuperFreq:/var/log/mmdvm# sudo lsof -i:42020
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Gatewa 21266 root    4u  IPv4 1378574      0t0  UDP *:42020


On Fri, Oct 11, 2019 at 7:31 AM Steve N4IRS <szingman@...> wrote:
So,
The reflector startup looks normal but I expect the gateway will timeout since it is trying to connect to reflector 420 on port UDP 41000 as reflected in p25hosts. The P25Reflector is listening on UDP port 42020. So, the Gateway never connects or logs into the reflector. The error you get:

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*


Is caused by the gateway sending data but not logged into the the reflector. Change p25hosts to reflect the port the reflector is actually listening on. Since you can connect to the reflector from your MMDVMHost:

M: 2019-10-11 01:27:49.733 Adding N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.375 Transmission started from N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.385 Transmission from N9KRG at N9KRG      to TG 420


I would expect the published UDP port of 42020 is correct.

Steve N4IRS

On 10/10/19 10:45 PM, Jake Litwin wrote:
hmmm. This is all I"m seeing on the live output for gateway

root@SuperFreq:/opt/P25Gateway# ./P25Gateway
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.324 Loaded 13 P25 reflectors
I: 2019-10-11 02:44:53.324 Loaded P25 parrot (TG10)
I: 2019-10-11 02:44:53.359 Loaded 145619 Ids to the callsign lookup table
M: 2019-10-11 02:44:53.359 Starting P25Gateway-20180409
M: 2019-10-11 02:44:53.359 Linked at startup to reflector 420
I: 2019-10-11 02:44:53.359 Started the DMR Id lookup reload thread


Re: Bridging a P25Reflector and a YSFReflector?

Jake Litwin
 

Changing the P25Hosts file to 42020 would not connect to the reflector. Keeping it on 41000 gateway connects to the reflector but that's where I get

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*
 

I did a port check and Reflector is listening on 41000

root@SuperFreq:/var/log/mmdvm# sudo lsof -i:41000
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Reflec 20357 root    4u  IPv4 1373306      0t0  UDP *:41000
root@SuperFreq:/var/log/mmdvm# sudo lsof -i:42020
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
P25Gatewa 21266 root    4u  IPv4 1378574      0t0  UDP *:42020


On Fri, Oct 11, 2019 at 7:31 AM Steve N4IRS <szingman@...> wrote:
So,
The reflector startup looks normal but I expect the gateway will timeout since it is trying to connect to reflector 420 on port UDP 41000 as reflected in p25hosts. The P25Reflector is listening on UDP port 42020. So, the Gateway never connects or logs into the reflector. The error you get:

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*


Is caused by the gateway sending data but not logged into the the reflector. Change p25hosts to reflect the port the reflector is actually listening on. Since you can connect to the reflector from your MMDVMHost:

M: 2019-10-11 01:27:49.733 Adding N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.375 Transmission started from N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.385 Transmission from N9KRG at N9KRG      to TG 420


I would expect the published UDP port of 42020 is correct.

Steve N4IRS

On 10/10/19 10:45 PM, Jake Litwin wrote:
hmmm. This is all I"m seeing on the live output for gateway

root@SuperFreq:/opt/P25Gateway# ./P25Gateway
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.324 Loaded 13 P25 reflectors
I: 2019-10-11 02:44:53.324 Loaded P25 parrot (TG10)
I: 2019-10-11 02:44:53.359 Loaded 145619 Ids to the callsign lookup table
M: 2019-10-11 02:44:53.359 Starting P25Gateway-20180409
M: 2019-10-11 02:44:53.359 Linked at startup to reflector 420
I: 2019-10-11 02:44:53.359 Started the DMR Id lookup reload thread

Re: Bridging a P25Reflector and a YSFReflector?

Steve N4IRS
 

So,
The reflector startup looks normal but I expect the gateway will timeout since it is trying to connect to reflector 420 on port UDP 41000 as reflected in p25hosts. The P25Reflector is listening on UDP port 42020. So, the Gateway never connects or logs into the reflector. The error you get:

Data received from an unknown source - 127.0.0.1:42020
M: 2019-10-11 01:28:23.400 Data
M: 2019-10-11 01:28:23.400 0000:  62 02 02 0C 0B 12 64 00 00 80 18 72 8A 2A 19 40    *b.....d....r.*.@*
M: 2019-10-11 01:28:23.400 0010:  00 D4 0C 80 62 00                                  *....b.*


Is caused by the gateway sending data but not logged into the the reflector. Change p25hosts to reflect the port the reflector is actually listening on. Since you can connect to the reflector from your MMDVMHost:

M: 2019-10-11 01:27:49.733 Adding N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.375 Transmission started from N9KRG      (141.126.148.63:24186)
M: 2019-10-11 01:28:23.385 Transmission from N9KRG at N9KRG      to TG 420


I would expect the published UDP port of 42020 is correct.

Steve N4IRS

On 10/10/19 10:45 PM, Jake Litwin wrote:
hmmm. This is all I"m seeing on the live output for gateway

root@SuperFreq:/opt/P25Gateway# ./P25Gateway
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.322 Opening P25 network connection
I: 2019-10-11 02:44:53.324 Loaded 13 P25 reflectors
I: 2019-10-11 02:44:53.324 Loaded P25 parrot (TG10)
I: 2019-10-11 02:44:53.359 Loaded 145619 Ids to the callsign lookup table
M: 2019-10-11 02:44:53.359 Starting P25Gateway-20180409
M: 2019-10-11 02:44:53.359 Linked at startup to reflector 420
I: 2019-10-11 02:44:53.359 Started the DMR Id lookup reload thread