|
Currently, I have the address in the DMR Network stanza pointed
to the XLX reflector <IP_ADDRESS:62030). I assume this is the
network address you're referring to?
If so, then the reflector isn't doing much with that, and this is
probably not a DVSwitch issue.
toggle quoted messageShow quoted text
On 11/30/2019 5:22 PM, Steve N4IRS
wrote:
The network address should point at the xlx reflector
Sent by smoke signal (AT&T)
That was actually the first configuration I tried. Same
result either with the Interface IP address, or local loopback.
I’ll mess with it some more later. The MMDVM_Bridge part looks
easy enough once I can get it talking to XLXD.
Use the ip address of the machine not 127.0.0.1
I downloaded the latest MMDVM_Bridge earlier today. My
current issue is getting MMDVM-Bridge connected to XLXD
on the same machine. I'm sure I've directly connected a
hotspot to the reflector before, but that was a while
ago.
The relevant part of MMDVM_Bridge.ini looks like this:
[DMR Network]
Enable=1
Address=127.0.0.1
Port=62030
Jitter=360
Local=62031
Password=passw0rd
Options=XLX:4002
Slot1=0
Slot2=1
Debug=0
Small part of the MMDVM_Bridge log:
E: 2019-11-30 21:34:28.884 DMR, Connection to the
master has timed out, retrying connection
tcpdump shows active connections on UDP 62030, so XLXD
should be accepting the connection from MMDVM_Bridge on
that port.
On 11/30/2019 4:20 PM,
Ernie Gm7kbk wrote:
latest version of MMDVM_bridge
works with no problems. Use the options XLX:4005 this
being the module you want to connect to. 4001 for A 4002
for B etc. latest version is here https://github.com/DVSwitch/MMDVM_Bridge
|
|
|
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!
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 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 - 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 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? 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>
|
|
|
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 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 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
- 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 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? 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
|
|
|
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
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 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
- 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 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? 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
|
|
|
Corey Dean N3FE <n3fe@...>
They can coexist just fine. Just do got clone in a different directory and away you go!
Corey n3fe
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 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
- 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 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? 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>
|
|
|
Python2 (End of Life) Question
David Aitcheson KB3EFS <kb3efs.dave@...>
Steve/Mike,
What is the plan going forward given the end of life status for
Python2 ?
I ask as it is being very actively and aggressively being
eliminated from Debian Sid/Bullseye (with a similar movement in
the Debian derivatives) in favor of Python3.
73
Dave
KB3EFS
|
|
|
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
- 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 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? 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>
|
|
|
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, <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 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?
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>
|
|
|
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
toggle quoted messageShow quoted text
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,
<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
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?
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>
|
|
|
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
toggle quoted messageShow quoted text
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,
<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
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?
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>
|
|
|
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 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?
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>
|
|
|
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
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 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?
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
toggle quoted messageShow quoted text
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
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?
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, 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?
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, - 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?
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>
|
|
|
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?
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,
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
|
|
|
Steve N4IRS
You are going to do your cross connect in DVSwitch.ini
Sent by smoke signal (AT&T)
toggle quoted messageShow quoted text
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Saturday, November 30, 2019 5:21:54 PM
To: main@dvswitch.groups.io <main@dvswitch.groups.io>
Subject: Re: [DVSwitch] Brandmeister to XLX
Oh yes, I forgot to mention that the MMDVM_Bridge is in its own directory with different rx and tx ports in DVSwitch.ini to avoid conflict with the existing bridge.
On Nov 30, 2019, at 16:49, Steve N4IRS <szingman@...> wrote:
See Ernie's reply AND since you are running 2 copies of MB, change the local post on one of them
Sent by smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Saturday, November 30, 2019 4:37:24 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Brandmeister to XLX
I downloaded the latest MMDVM_Bridge earlier today. My current issue is getting MMDVM-Bridge connected to XLXD on the same machine. I'm sure I've directly connected a hotspot to the reflector before, but that was a while ago.
The relevant part of MMDVM_Bridge.ini looks like this:
[DMR Network]
Enable=1
Address=127.0.0.1
Port=62030
Jitter=360
Local=62031
Password=passw0rd
Options=XLX:4002
Slot1=0
Slot2=1
Debug=0
Small part of the MMDVM_Bridge log:
E: 2019-11-30 21:34:28.884 DMR, Connection to the master has timed out, retrying connection
tcpdump shows active connections on UDP 62030, so XLXD should be accepting the connection from MMDVM_Bridge on that port.
On 11/30/2019 4:20 PM, Ernie Gm7kbk wrote:
latest version of MMDVM_bridge works with no problems. Use the options XLX:4005 this being the module you want to connect to. 4001 for A 4002 for B etc. latest version is here https://github.com/DVSwitch/MMDVM_Bridge
|
|
|
Steve N4IRS
The network address should point at the xlx reflector
Sent by smoke signal (AT&T)
toggle quoted messageShow quoted text
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Saturday, November 30, 2019 5:18:50 PM
To: main@dvswitch.groups.io <main@dvswitch.groups.io>
Subject: Re: [DVSwitch] Brandmeister to XLX
That was actually the first configuration I tried. Same result either with the Interface IP address, or local loopback. I’ll mess with it some more later. The MMDVM_Bridge part looks easy enough once I can get it talking to XLXD.
On Nov 30, 2019, at 16:39, Ernie Gm7kbk <erniepratt@...> wrote:
Use the ip address of the machine not 127.0.0.1
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Saturday, November 30, 2019 9:37:24 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Brandmeister to XLX
I downloaded the latest MMDVM_Bridge earlier today. My current issue is getting MMDVM-Bridge connected to XLXD on the same machine. I'm sure I've directly connected a hotspot to the reflector before, but that was a while ago.
The relevant part of MMDVM_Bridge.ini looks like this:
[DMR Network]
Enable=1
Address=127.0.0.1
Port=62030
Jitter=360
Local=62031
Password=passw0rd
Options=XLX:4002
Slot1=0
Slot2=1
Debug=0
Small part of the MMDVM_Bridge log:
E: 2019-11-30 21:34:28.884 DMR, Connection to the master has timed out, retrying connection
tcpdump shows active connections on UDP 62030, so XLXD should be accepting the connection from MMDVM_Bridge on that port.
On 11/30/2019 4:20 PM, Ernie Gm7kbk wrote:
latest version of MMDVM_bridge works with no problems. Use the options XLX:4005 this being the module you want to connect to. 4001 for A 4002 for B etc. latest version is here https://github.com/DVSwitch/MMDVM_Bridge
|
|
|
Oh yes, I forgot to mention that the MMDVM_Bridge is in its own directory with different rx and tx ports in DVSwitch.ini to avoid conflict with the existing bridge.
On Nov 30, 2019, at 16:49, Steve N4IRS <szingman@...> wrote:
See Ernie's reply AND since you are running 2 copies of MB, change the local post on one of them
Sent by smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Saturday, November 30, 2019 4:37:24 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Brandmeister to XLX
I downloaded the latest MMDVM_Bridge earlier today. My current issue is getting MMDVM-Bridge connected to XLXD on the same machine. I'm sure I've directly connected a hotspot to the reflector before, but that was a while ago.
The relevant part of MMDVM_Bridge.ini looks like this:
[DMR Network]
Enable=1
Address=127.0.0.1
Port=62030
Jitter=360
Local=62031
Password=passw0rd
Options=XLX:4002
Slot1=0
Slot2=1
Debug=0
Small part of the MMDVM_Bridge log:
E: 2019-11-30 21:34:28.884 DMR, Connection to the master has timed out, retrying connection
tcpdump shows active connections on UDP 62030, so XLXD should be accepting the connection from MMDVM_Bridge on that port.
On 11/30/2019 4:20 PM, Ernie Gm7kbk wrote:
latest version of MMDVM_bridge works with no problems. Use the options XLX:4005 this being the module you want to connect to. 4001 for A 4002 for B etc. latest version is here https://github.com/DVSwitch/MMDVM_Bridge
|
|
|
