Topics

Linking dmrlink and HBlink3 #dmrlink #hblink

ai6bx
 

I have DMRlink configured and running with a bridge to a Motorola master as well as two peer moto DMR machines linked to a master instance I have built within DMRlink. I also have HBlink3 installed with a master for my hotspot. This seems to be running as well with no errors. As I have no interest at this point in linking to Brandmeister, I have not built an OpenBridge or built out the Repeater-1 profile so both are set to false. I can see my hotspot keying and can also see activity in the logfiles for DMRlink. What I am not seeing is traffic passing between the two. It feels like I am missing a stanza in the .cfg files or a bridge activating somewhere. 

Any pointers would be appreciated.

Cort N0MJS
 

PLEASE TAKE NOTICE:

We have asked this many time. If you intend to ask for help, the following are absolutely mandatory. The people who write the software will not supply help if you do not:

* Include the explicit names of the programs you’re running and how they’re connected. This isn’t “HBlink3” it’s probably bridge.py, probably not DMRlink, but IPSC_Bridge.py
* Include copied of configuration files, rule files, etc. The files, or the text NO SCREENSHOTS
* Include any pertinent, tracebacks (errors) and/or log files
* NO SCREENSHOTS

From this moment on, I will not offer or even respond to requests for help if these things are not included. Period.

On Nov 30, 2019, at 3:06 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

I have DMRlink configured and running with a bridge to a Motorola master as well as two peer moto DMR machines linked to a master instance I have built within DMRlink. I also have HBlink3 installed with a master for my hotspot. This seems to be running as well with no errors. As I have no interest at this point in linking to Brandmeister, I have not built an OpenBridge or built out the Repeater-1 profile so both are set to false. I can see my hotspot keying and can also see activity in the logfiles for DMRlink. What I am not seeing is traffic passing between the two. It feels like I am missing a stanza in the .cfg files or a bridge activating somewhere. 

Any pointers would be appreciated.

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





ai6bx
 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith

Cort N0MJS
 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?

On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

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





ai6bx
 

Cort,

 

  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.

 

I hope this helps.

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?



On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 

ai6bx
 

Cort,

 

Note I do not see the IPSC_bridge.py in any of my current installed directories. Is this something installed independent of DMRlink?

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?



On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 

Steve N4IRS
 

On 11/30/19 6:59 PM, ai6bx via Groups.Io wrote:

Cort,

 

Note I do not see the IPSC_bridge.py in any of my current installed directories. Is this something installed independent of DMRlink?

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?



On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 


Cort N0MJS
 

Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.

My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.

IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.

If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.

I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.

If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.

0x49 DE N0MJS

On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

Cort,
 
  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.
 
I hope this helps.
 
Keith
 
From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink
 
I need to understand what you’re attempting to do. Please fill in the gaps for me?
 
You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?
 
Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?


On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:
 
Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>
 
--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
 


 

 


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





ai6bx
 

Steve,

 

Thank you for these links. Perhaps this is a stupid question however since I already have DMRlink installed via mk- should I just copy the IPSC files over or clone this entire directory and run mk- again? Also, should I remove HBlink3 and utilize this version or install this package in addition to HBlink3?

 

Thank you,

 

From: <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Organization: msgstor.com
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:10 PM
To: <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

<https://github.com/n0mjs710/DMRlink/tree/IPSC_Bridge>
<https://github.com/n0mjs710/HBlink/tree/HB_Bridge>

On 11/30/19 6:59 PM, ai6bx via Groups.Io wrote:

Cort,

 

Note I do not see the IPSC_bridge.py in any of my current installed directories. Is this something installed independent of DMRlink?

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?




On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 

Steve N4IRS
 

As Cort said, IPSC_Bridge and HB_Bridge are stand alone Python2 programs. As a pair they allow you to connect a IPSC network to a HB network. I would keep them separate and configure them to   connect your IPSC devices to HB.

Steve


On 11/30/19 7:32 PM, ai6bx via Groups.Io wrote:

Steve,

 

Thank you for these links. Perhaps this is a stupid question however since I already have DMRlink installed via mk- should I just copy the IPSC files over or clone this entire directory and run mk- again? Also, should I remove HBlink3 and utilize this version or install this package in addition to HBlink3?

 

Thank you,

 

From: <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Organization: msgstor.com
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:10 PM
To: <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

<https://github.com/n0mjs710/DMRlink/tree/IPSC_Bridge>
<https://github.com/n0mjs710/HBlink/tree/HB_Bridge>

On 11/30/19 6:59 PM, ai6bx via Groups.Io wrote:

Cort,

 

Note I do not see the IPSC_bridge.py in any of my current installed directories. Is this something installed independent of DMRlink?

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?




On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 


Steve N4IRS
 

IPSC_Bridge and HB_Bridge were built with one basic purpose in mind, to take the data stream down to it's component parts. Those parts are voice data and meta data. once these parts are extracted they are transported to a "Partner" program. The transport is TLV, Tag Length Value. The TLV is sent via UDP to the Partner program. In the beginning the primary Partner was Analog_Bridge. The power to TLV is the ability to connect two Partners together. TLV is the common connection. TLV allows Partners to communicate like data. When a transcoder is needed, for example DMR to D-Star or DMR to P25, two instances of Analog_bridge are connected to convert encoding types.

In the case of IPSC to HB, IPSC_Bridge is cross connected to HB_Bridge. IPSC_Bridge<->HB_Bridge. The cross connect is on the TLV UDP ports.

Hope this helps,
73, Steve N4IRS

On 11/30/19 7:32 PM, ai6bx via Groups.Io wrote:

Steve,

 

Thank you for these links. Perhaps this is a stupid question however since I already have DMRlink installed via mk- should I just copy the IPSC files over or clone this entire directory and run mk- again? Also, should I remove HBlink3 and utilize this version or install this package in addition to HBlink3?

 

Thank you,

 

From: <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Organization: msgstor.com
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:10 PM
To: <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

<https://github.com/n0mjs710/DMRlink/tree/IPSC_Bridge>
<https://github.com/n0mjs710/HBlink/tree/HB_Bridge>

On 11/30/19 6:59 PM, ai6bx via Groups.Io wrote:

Cort,

 

Note I do not see the IPSC_bridge.py in any of my current installed directories. Is this something installed independent of DMRlink?

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?




On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 


ai6bx
 

Copy that.

 

From: <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Organization: msgstor.com
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:37 PM
To: <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

As Cort said, IPSC_Bridge and HB_Bridge are stand alone Python2 programs. As a pair they allow you to connect a IPSC network to a HB network. I would keep them separate and configure them to   connect your IPSC devices to HB.

Steve

On 11/30/19 7:32 PM, ai6bx via Groups.Io wrote:

Steve,

 

Thank you for these links. Perhaps this is a stupid question however since I already have DMRlink installed via mk- should I just copy the IPSC files over or clone this entire directory and run mk- again? Also, should I remove HBlink3 and utilize this version or install this package in addition to HBlink3?

 

Thank you,

 

From: <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Organization: msgstor.com
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:10 PM
To: <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

<https://github.com/n0mjs710/DMRlink/tree/IPSC_Bridge>
<https://github.com/n0mjs710/HBlink/tree/HB_Bridge>


On 11/30/19 6:59 PM, ai6bx via Groups.Io wrote:

Cort,

 

Note I do not see the IPSC_bridge.py in any of my current installed directories. Is this something installed independent of DMRlink?

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?





On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 





 

 

 

 

ai6bx
 

Cort,

 

Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?

 

Thank you,

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.

 

My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.

 

IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.

 

If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.

 

I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.

 

If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.

 

0x49 DE N0MJS



On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.

 

I hope this helps.

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?




On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 

Corey Dean N3FE
 

They can coexist just fine.  Just do got clone in a different directory and away you go!

Corey n3fe

On Sat, Nov 30, 2019 at 8:30 PM ai6bx via Groups.Io <ai6bx.keith=verizon.net@groups.io> wrote:

Cort,

 

Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?

 

Thank you,

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs=me.com@groups.io>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.

 

My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.

 

IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.

 

If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.

 

I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.

 

If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.

 

0x49 DE N0MJS



On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.

 

I hope this helps.

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?




On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 

Cort N0MJS
 

Keith,

You’re really going to have to think about your project goals and make a decision. I have run systems with confbridge.py running on one side and bridge.py on the other… There are a LOT of things that can get you in trouble. You’ll have to remember, you’re essentially running two separate multi-system “networks” that are cross-connected to each other.

If at all possible, I’d recommend handling all of your call routing in bridge.py and translating the Motorolas into home-brew. Why this way and not the other? I’ve sunset development on DMRlink – mostly because I don’t even have a Motorola repeater anymore and I need at least 2 to really do any development work with it. Time is another reason. But I also see home-brew protocol and MMDVM as the future of digital ham radio… for me at least, and since I’m not getting paid for this, I’ll be following the beat of my own drum :)

Because you’re so Motorola heavy, you should consider running the call routing in confbridge.py on the IPSC side and bring your MMDVMs in as the afterthought. Just remember that there will be no new development on DMRlink unless someone else does it. It is what it is.

For the KS-DMR network, when someone shows up with a Motorola repeater, we deploy an IPSC_Bridge.py and HB_bridge.py combo for each one. The idea is simply convert the Motorola to speak home-brew as fast and as close to the source as possible. Often times this is a small single board computer – usually with “Pi” in the name somewhere – right with the repeater itself. Other times, for folks who want to be a part of it it just can’t handle (or just don’t want to) running those services we provide them on our infrastructure.

0x49 DE N0MJS

On Nov 30, 2019, at 7:30 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

Cort,
 
Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?
 
Thank you,
 
Keith
 
From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink
 
Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.
 
My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.
 
IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.
 
If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.
 
I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.
 
If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.
 
0x49 DE N0MJS


On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:
 
Cort,
 
  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.
 
I hope this helps.
 
Keith
 
From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink
 
I need to understand what you’re attempting to do. Please fill in the gaps for me?
 
You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?
 
Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?



On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:
 
Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>
 
--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
 



 

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


 

 


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





Cort N0MJS
 

Corey and Steve were already here, but I’ll reiterate:

Treat the HB_Bridge and IPSC_Bridge branches like completely different programs from DMRlink and HBlink master branches. Just map it that way in your head. You can use the same copy of them for multiple protocol conversions by specifying the configuration files on the command line (I’ve recently posted configuration for that), but they can’t be used for the “other” services.

On Nov 30, 2019, at 8:22 PM, Corey Dean N3FE <n3fe@...> wrote:

They can coexist just fine.  Just do got clone in a different directory and away you go!

Corey n3fe

On Sat, Nov 30, 2019 at 8:30 PM ai6bx via Groups.Io <ai6bx.keith=verizon.net@groups.io> wrote:

Cort,

 

Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?

 

Thank you,

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs=me.com@groups.io>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.

 

My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.

 

IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.

 

If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.

 

I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.

 

If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.

 

0x49 DE N0MJS



On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.

 

I hope this helps.

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?




On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 




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





ai6bx
 

Perfect.

 

Thanks

 

From: <main@DVSwitch.groups.io> on behalf of Corey Dean N3FE <n3fe@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 6:22 PM
To: <main@dvswitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

They can coexist just fine.  Just do got clone in a different directory and away you go!

 

Corey n3fe

 

On Sat, Nov 30, 2019 at 8:30 PM ai6bx via Groups.Io <ai6bx.keith=verizon.net@groups.io> wrote:

Cort,

 

Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?

 

Thank you,

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs=me.com@groups.io>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.

 

My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.

 

IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.

 

If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.

 

I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.

 

If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.

 

0x49 DE N0MJS

 

On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.

 

I hope this helps.

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?



On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 

 

 

 

ai6bx
 

Cort,

 

I am not seeing bridge.py in my installs. I do have hb_bridge.py and hb_bridge_all.py. Are these interchangeable?

 

With IPSC_Bridge.py I am getting the following errors at start up.

 

root@AI6BX-DMR:/opt/DMRlink# python IPSC_Bridge.py

INFO 2019-12-01 08:32:03,184 DMRlink 'IPSC_Bridge.py' (c) 2015 N0MJS & the K0USY Group - SYSTEM STARTING...

INFO 2019-12-01 08:32:03,185 Version 20170620

INFO 2019-12-01 08:32:03,185 ID ALIAS MAPPER: 'peer_ids.json' is current, not downloaded

INFO 2019-12-01 08:32:03,186 ID ALIAS MAPPER: 'subscriber_ids.json' is current, not downloaded

INFO 2019-12-01 08:32:03,308 ID ALIAS MAPPER: peer_ids dictionary is available

INFO 2019-12-01 08:32:05,256 ID ALIAS MAPPER: subscriber_ids dictionary is available

INFO 2019-12-01 08:32:05,259 (RIFF_PEER) IPSC Instance Created: 92374, 0.0.0.0:62031

INFO 2019-12-01 08:32:05,260 section = RIFF_PEER

INFO 2019-12-01 08:32:05,260 Section RIFF_PEER was not found, using DEFAULTS

INFO 2019-12-01 08:32:05,260 gateway = 127.0.0.1

INFO 2019-12-01 08:32:05,261 toGatewayPort = 31003

INFO 2019-12-01 08:32:05,261 fromGatewayPort = 31000

INFO 2019-12-01 08:32:05,261 DMRLink IPSC Bridge

INFO 2019-12-01 08:32:05,264 (RIFF_PEER) Registering with the Master: 47.180.30.199:7000

INFO 2019-12-01 08:32:05,265 (RIFF_MASTER) IPSC Instance Created: 54321, 0.0.0.0:62042

INFO 2019-12-01 08:32:05,265 section = RIFF_MASTER

INFO 2019-12-01 08:32:05,265 Section RIFF_MASTER was not found, using DEFAULTS

INFO 2019-12-01 08:32:05,266 gateway = 127.0.0.1

INFO 2019-12-01 08:32:05,266 toGatewayPort = 31003

INFO 2019-12-01 08:32:05,266 fromGatewayPort = 31000

INFO 2019-12-01 08:32:05,266 DMRLink IPSC Bridge

Traceback (most recent call last):

  File "IPSC_Bridge.py", line 308, in <module>

    systems[system] = ambeIPSC(system, CONFIG, logger, report_server)

  File "IPSC_Bridge.py", line 96, in __init__

    self.ipsc_ambe = AMBE_IPSC(self, _name, _config, _logger, self._ambeRxPort)

  File "/usr/local/lib/python2.7/dist-packages/dmr_utils/ambe_bridge.py", line 525, in __init__

    AMBE_BASE.__init__(self, _parent, _name, _config, _logger, _port)

  File "/usr/local/lib/python2.7/dist-packages/dmr_utils/ambe_bridge.py", line 187, in __init__

    self.udp_port = reactor.listenUDP(self._ambeRxPort, UDP_IMPORT(self.import_datagramReceived))

  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 369, in listenUDP

    p.startListening()

  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 178, in startListening

    self._bindSocket()

  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 198, in _bindSocket

    raise error.CannotListenError(self.interface, self.port, le)

twisted.internet.error.CannotListenError: Couldn't listen on any:31000: [Errno 98] Address already in use.

root@AI6BX-DMR:/opt/DMRlink#

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 6:31 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Keith,

 

You’re really going to have to think about your project goals and make a decision. I have run systems with confbridge.py running on one side and bridge.py on the other… There are a LOT of things that can get you in trouble. You’ll have to remember, you’re essentially running two separate multi-system “networks” that are cross-connected to each other.

 

If at all possible, I’d recommend handling all of your call routing in bridge.py and translating the Motorolas into home-brew. Why this way and not the other? I’ve sunset development on DMRlink – mostly because I don’t even have a Motorola repeater anymore and I need at least 2 to really do any development work with it. Time is another reason. But I also see home-brew protocol and MMDVM as the future of digital ham radio… for me at least, and since I’m not getting paid for this, I’ll be following the beat of my own drum :)

 

Because you’re so Motorola heavy, you should consider running the call routing in confbridge.py on the IPSC side and bring your MMDVMs in as the afterthought. Just remember that there will be no new development on DMRlink unless someone else does it. It is what it is.

 

For the KS-DMR network, when someone shows up with a Motorola repeater, we deploy an IPSC_Bridge.py and HB_bridge.py combo for each one. The idea is simply convert the Motorola to speak home-brew as fast and as close to the source as possible. Often times this is a small single board computer – usually with “Pi” in the name somewhere – right with the repeater itself. Other times, for folks who want to be a part of it it just can’t handle (or just don’t want to) running those services we provide them on our infrastructure.

 

0x49 DE N0MJS



On Nov 30, 2019, at 7:30 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?

 

Thank you,

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.

 

My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.

 

IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.

 

If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.

 

I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.

 

If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.

 

0x49 DE N0MJS




On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.

 

I hope this helps.

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?





On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 





 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 



 

 

Cort N0MJS
 



On Dec 1, 2019, at 2:46 AM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

Cort,
 
I am not seeing bridge.py in my installs. I do have hb_bridge.py and hb_bridge_all.py. Are these interchangeable?

bridge.py is part of hblink3 – the Python 3 version of HBlink.

HB_Bridge.py and hb_bridge_all.py are completely different programs with completely different uses.

With IPSC_Bridge.py I am getting the following errors at start up. 
 
twisted.internet.error.CannotListenError: Couldn't listen on any:31000: [Errno 98] Address already in use.


“Address already in use” Something else on your system is already listening on UDP port 31000.


 
From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 6:31 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink
 
Keith,
 
You’re really going to have to think about your project goals and make a decision. I have run systems with confbridge.py running on one side and bridge.py on the other… There are a LOT of things that can get you in trouble. You’ll have to remember, you’re essentially running two separate multi-system “networks” that are cross-connected to each other.
 
If at all possible, I’d recommend handling all of your call routing in bridge.py and translating the Motorolas into home-brew. Why this way and not the other? I’ve sunset development on DMRlink – mostly because I don’t even have a Motorola repeater anymore and I need at least 2 to really do any development work with it. Time is another reason. But I also see home-brew protocol and MMDVM as the future of digital ham radio… for me at least, and since I’m not getting paid for this, I’ll be following the beat of my own drum :)
 
Because you’re so Motorola heavy, you should consider running the call routing in confbridge.py on the IPSC side and bring your MMDVMs in as the afterthought. Just remember that there will be no new development on DMRlink unless someone else does it. It is what it is.
 
For the KS-DMR network, when someone shows up with a Motorola repeater, we deploy an IPSC_Bridge.py and HB_bridge.py combo for each one. The idea is simply convert the Motorola to speak home-brew as fast and as close to the source as possible. Often times this is a small single board computer – usually with “Pi” in the name somewhere – right with the repeater itself. Other times, for folks who want to be a part of it it just can’t handle (or just don’t want to) running those services we provide them on our infrastructure.
 
0x49 DE N0MJS


On Nov 30, 2019, at 7:30 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:
 
Cort,
 
Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?
 
Thank you,
 
Keith
 
From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink
 
Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.
 
My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.
 
IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.
 
If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.
 
I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.
 
If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.
 
0x49 DE N0MJS



On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:
 
Cort,
 
  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.
 
I hope this helps.
 
Keith
 
From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink
 
I need to understand what you’re attempting to do. Please fill in the gaps for me?
 
You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?
 
Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?




On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:
 
Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>
 
--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206
 




 

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



 

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


 

 


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





ai6bx
 

Doh. Yep, I bridge.py now. I am starting small to get at least one bridge working and will replicate from there once success is achieved. I am building the Moto stanzas in dmrlink.cfg as follows and then launching IPSC_Bridge.py to look for errors. Regardless of the port number I use in IPSC_Bridge.cfg, I get an error indicating it is already in use which is pretty odd, at least to me. Logic would tell me to leave the default IP alone as both systems home on the same machine. Am I missing something?

 

Dmrlink.cfg

[RIFF_PEER]

ENABLED: True

RADIO_ID: 92374

IP:

PORT: 50001

ALIVE_TIMER: 5

MAX_MISSED: 20

PEER_OPER: True

IPSC_MODE: DIGITAL

TS1_LINK: True

TS2_LINK: True

CSBK_CALL: False

RCM: False

CON_APP: False

XNL_CALL: False

XNL_MASTER: False

DATA_CALL: True

VOICE_CALL: True

MASTER_PEER: False

AUTH_ENABLED: True

AUTH_KEY: AD07911

MASTER_IP: 47.180.30.199

MASTER_PORT: 7000

GROUP_HANGTIME: 5

 

[CARLSBAD]

ENABLED: True

RADIO_ID: 734566

IP:

PORT: 62042

ALIVE_TIMER: 5

MAX_MISSED: 20

PEER_OPER: True

IPSC_MODE: DIGITAL

TS1_LINK: True

TS2_LINK: True

CSBK_CALL: False

RCM: False

CON_APP: False

XNL_CALL: False

XNL_MASTER: False

DATA_CALL: True

VOICE_CALL: True

MASTER_PEER: True

AUTH_ENABLED: True

AUTH_KEY: AD07911

# Below not used for a Master

# MASTER_IP: 1.2.3.4

# MASTER_PORT: 50000

GROUP_HANGTIME: 5

 

[IBEX]

ENABLED: True

RADIO_ID: 734379

IP:

PORT: 62055

ALIVE_TIMER: 5

MAX_MISSED: 20

PEER_OPER: True

IPSC_MODE: DIGITAL

TS1_LINK: True

TS2_LINK: True

CSBK_CALL: False

RCM: False

CON_APP: False

XNL_CALL: False

XNL_MASTER: False

DATA_CALL: True

VOICE_CALL: True

MASTER_PEER: True

AUTH_ENABLED: True

AUTH_KEY: AD07911

# Below not used for a Master

# MASTER_IP: 1.2.3.4

# MASTER_PORT: 50000

GROUP_HANGTIME: 5

 

IPSC_Bridge.py output

 

root@AI6BX-DMR:/opt/DMRlink# python IPSC_Bridge.py

INFO 2019-12-01 16:51:32,087 DMRlink 'IPSC_Bridge.py' (c) 2015 N0MJS & the K0USY Group - SYSTEM STARTING...

INFO 2019-12-01 16:51:32,087 Version 20170620

INFO 2019-12-01 16:51:32,088 ID ALIAS MAPPER: 'peer_ids.json' is current, not downloaded

INFO 2019-12-01 16:51:32,088 ID ALIAS MAPPER: 'subscriber_ids.json' is current, not downloaded

INFO 2019-12-01 16:51:32,240 ID ALIAS MAPPER: peer_ids dictionary is available

INFO 2019-12-01 16:51:34,477 ID ALIAS MAPPER: subscriber_ids dictionary is available

INFO 2019-12-01 16:51:34,481 (RIFF_PEER) IPSC Instance Created: 92374, 0.0.0.0:50001

INFO 2019-12-01 16:51:34,482 section = RIFF_PEER

INFO 2019-12-01 16:51:34,482 Section RIFF_PEER was not found, using DEFAULTS

INFO 2019-12-01 16:51:34,482 gateway = 127.0.0.1

INFO 2019-12-01 16:51:34,483 toGatewayPort = 31003

INFO 2019-12-01 16:51:34,483 fromGatewayPort = 62059

INFO 2019-12-01 16:51:34,483 DMRLink IPSC Bridge

INFO 2019-12-01 16:51:34,487 (RIFF_PEER) Registering with the Master: 47.180.30.199:7000

INFO 2019-12-01 16:51:34,488 (IBEX) IPSC Instance Created: 734379, 0.0.0.0:62055

INFO 2019-12-01 16:51:34,488 section = IBEX

INFO 2019-12-01 16:51:34,489 Section IBEX was not found, using DEFAULTS

INFO 2019-12-01 16:51:34,489 gateway = 127.0.0.1

INFO 2019-12-01 16:51:34,489 toGatewayPort = 31003

INFO 2019-12-01 16:51:34,489 fromGatewayPort = 62059

INFO 2019-12-01 16:51:34,489 DMRLink IPSC Bridge

Traceback (most recent call last):

  File "IPSC_Bridge.py", line 308, in <module>

    systems[system] = ambeIPSC(system, CONFIG, logger, report_server)

  File "IPSC_Bridge.py", line 96, in __init__

    self.ipsc_ambe = AMBE_IPSC(self, _name, _config, _logger, self._ambeRxPort)

  File "/usr/local/lib/python2.7/dist-packages/dmr_utils/ambe_bridge.py", line 525, in __init__

    AMBE_BASE.__init__(self, _parent, _name, _config, _logger, _port)

  File "/usr/local/lib/python2.7/dist-packages/dmr_utils/ambe_bridge.py", line 187, in __init__

    self.udp_port = reactor.listenUDP(self._ambeRxPort, UDP_IMPORT(self.import_datagramReceived))

  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 369, in listenUDP

    p.startListening()

  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 178, in startListening

    self._bindSocket()

  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 198, in _bindSocket

    raise error.CannotListenError(self.interface, self.port, le)

twisted.internet.error.CannotListenError: Couldn't listen on any:62059: [Errno 98] Address already in use.

root@AI6BX-DMR:/opt/DMRlink#

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Sunday, December 1, 2019 at 6:54 AM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

 



On Dec 1, 2019, at 2:46 AM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

I am not seeing bridge.py in my installs. I do have hb_bridge.py and hb_bridge_all.py. Are these interchangeable?

 

bridge.py is part of hblink3 – the Python 3 version of HBlink.

 

HB_Bridge.py and hb_bridge_all.py are completely different programs with completely different uses.



With IPSC_Bridge.py I am getting the following errors at start up. 

 

twisted.internet.error.CannotListenError: Couldn't listen on any:31000: [Errno 98] Address already in use.

 

 

“Address already in use” Something else on your system is already listening on UDP port 31000.

 



 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 6:31 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Keith,

 

You’re really going to have to think about your project goals and make a decision. I have run systems with confbridge.py running on one side and bridge.py on the other… There are a LOT of things that can get you in trouble. You’ll have to remember, you’re essentially running two separate multi-system “networks” that are cross-connected to each other.

 

If at all possible, I’d recommend handling all of your call routing in bridge.py and translating the Motorolas into home-brew. Why this way and not the other? I’ve sunset development on DMRlink – mostly because I don’t even have a Motorola repeater anymore and I need at least 2 to really do any development work with it. Time is another reason. But I also see home-brew protocol and MMDVM as the future of digital ham radio… for me at least, and since I’m not getting paid for this, I’ll be following the beat of my own drum :)

 

Because you’re so Motorola heavy, you should consider running the call routing in confbridge.py on the IPSC side and bring your MMDVMs in as the afterthought. Just remember that there will be no new development on DMRlink unless someone else does it. It is what it is.

 

For the KS-DMR network, when someone shows up with a Motorola repeater, we deploy an IPSC_Bridge.py and HB_bridge.py combo for each one. The idea is simply convert the Motorola to speak home-brew as fast and as close to the source as possible. Often times this is a small single board computer – usually with “Pi” in the name somewhere – right with the repeater itself. Other times, for folks who want to be a part of it it just can’t handle (or just don’t want to) running those services we provide them on our infrastructure.

 

0x49 DE N0MJS




On Nov 30, 2019, at 7:30 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

Thank you for your timely and detailed response. With the links Steve sent, I think I am ready to have a go at it again. That said, I note in your response below that use of TGID and some repeater grouping would be desireable which is the other benefit that has drawn me to your work. Would I still use the confbridge.py or bridge.py after setting up IPSC? Would best practice be to remove my current installs of DMRlink and HBlink3 before installing the suggested branch versions?

 

Thank you,

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 4:15 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

Why not just connect the XPR8300s to the IPSC system with the SLR5700s? By the way, the “master” is inconsequential. The only purpose it serves is bootstrapping a new peer in the IPSC mesh – it doesn’t really matter who plays that role. When systems are meshed, they all operate as “peers” for the purpose of passing traffic. Master is only unique for link establishment. As for the hotspots, there’s no need to use bridge.py either.

 

My recommendation is to connect all Motorola repeaters in the same IPSC mesh (system, network – whatever you want to call it), and then use IPSC_Bridge.py and HB_Bridge.py to connect a single Homebrew server (master) over to the Motorolas. BTW: On the home-brew side, “master” does have significant meaning since the repeaters to not form a mesh like IPSC. All traffic has to traverse a central server, which just happens to be (unfortunately, because it really clouds the issue) a “master”.

 

IPSC_Bridge.py and HB_Bridge.py are found in the specific branches of DMRlink and HBlink (the original Python2 version) named for those programs. You’ll have to clone and switch the branch, or just clone the branch you want directly. Please don’t be temped to just use the versions of confbridge.py etc. with the “Bridge” branches. They’re based on quite old versions that are missing a lot of updates to other programs, but they are EXTREMELY stable and do the job they need to for protocol bridging quite well.

 

If you are struggling with how branches and stuff work with GitHub, the Internet us FULL of how-tos and tutorials on the topic.

 

I’m advising this setup because it appears you’re heavily invested in Motorola IPSC networking already, and the solution I’ve offered provides the most continuity for what you’re used to and already doing with the SLR5700s. There’s no need to run confbridge.py or bridge.py unless unless you’re wanting to segregated traffic between parts of your system – that is to say, have a TGID available on a group of repeaters not available on another group, etc.

 

If you reach the point where you have too many machines in a single IPSC mesh and you’re using too much bandwidth (n-1 stream count and all) you could look into proxy.py in DMRlink, which will transparently break up your IPSC mesh into smaller sub-groups.

 

0x49 DE N0MJS





On Nov 30, 2019, at 5:57 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

 

  • Currently I have an SLR5700 functioning as a master hosting six Motorola DMR repeaters. These all live on a public Internet address.
  • I have two Moto XPR8300’s that I want to peer to DMRlink and bridge to the current SLR5700 Master. Ultimately, I wish to transition the six repeaters from the 5700 so they are all on DMR link.
  • I am currently working with one MMDVM hotspot on the HBlink3 side of things with the goal of bridging the two sides together, something I can’t do with the SLR5700. Once working, hotspots will likely grow to about 15 or 20 devices.
  • Down the road the total number of Moto repeaters will grow to about 15.
  • This will be operated on a private network supported by ARDEN mesh networking operating in the 10.x.x.x domain and will have a gateway to the broader Internet via an AMPR.or 44.x.x.x address for hotspot connections when members travel.
  • The system will be migrated to a Debian 9 Blade server once ready for production deployment. I am currently building on a Vultr Debian VM for test and learning purposes.

 

I hope this helps.

 

Keith

 

From: <main@DVSwitch.groups.io> on behalf of "Cort N0MJS via Groups.Io" <n0mjs@...>
Reply-To: <main@DVSwitch.groups.io>
Date: Saturday, November 30, 2019 at 3:39 PM
To: "main@dvswitch.groups.io" <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Linking dmrlink and HBlink3 #dmrlink #hblink

 

I need to understand what you’re attempting to do. Please fill in the gaps for me?

 

You have a number of Motorola repeaters and MMDVM devices. You’re trying to make them all talk together on a private network. You do not have any “upstream” connections to the “big networks” or laterals to other independent networks?

 

Is that right? The use case changes best practice. Also, which “side” has more devices – the Motorola repeaters or the MMDVM devices? Today? Expected in the future?






On Nov 30, 2019, at 5:13 PM, ai6bx via Groups.Io <ai6bx.keith@...> wrote:

 

Cort,

First, my apology as I am still new to the groups here and finding my way through these tools. DVSwitch is clearly a powerful set of programs and bridges that I am certain will do exactly what I am trying to accomplish Once I better understand the relationships between them and some of the pieces that make those links work. I am currently running:
Confbridge.py
Bridge.py and have also tried bridge_all.py

Following are my files:
Rules:
Logs:

Again, I sincerely appreciate any guidance possible and suspect I am missing something that will be blatantly obvious once pointed out.

Sincerely,

Keith <dmrlink.cfg><hblink.cfg><confbridge_rules.py><rules.py><dmrlink.log><hblink.log><dmrlink.log>

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 






 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 





 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206

 




 

 

 

--

Cort Buffington

H: +1-785-813-1501

M: +1-785-865-7206