Date   

Re: Allstarling.org Contact

 

Chris,

My explanation is not in defense of your comment, and I'm not offended.  While I don't remember seeing your post or the response to it, that isn't the answer you should have received.  As I indicated, there are plenty of things we need to address and make better, and everyone should expect that we'll do just that - over time.  Certainly there were instances in the past that our servers had some issues, but a while ago we purchased some new ones, and they've been running for some time - a few months now.  I have over 50 nodes publicly registered at ASL, so I know immediately when there are registration issues.  Since the upgrade, I've helped troubleshoot and resolve registration problems on several nodes, and none of them were because the ASL server networks were unstable or unreachable.  I haven't personally had any registration issues since the upgrade.

In closing, currently it's my recommendation that folks post their problems to the app_rpt email list.  It's the best place to get answers and resolve to issues pertaining to ASL.

Thanks,
Kevin W3KKC

On 7/11/2018 6:11 PM, Chris WB4ULK via Groups.Io wrote:
Kevin,

I'm sorry if I offended you with that light hearted comment. I can only imagine what work goes into keeping this thing up.

I was not looking for someone to hold my hand when I wrote an email asking what was going on with the registration server several months ago. I was writing asking about it because the registration server is completely out of my control. The answer I got back did not answer to my question, instead I was told to get a mentor.

I took this with a grain of salt and waited the issue out with nothing else said. What else could I do? The comment above was nothing more than a making light of the situation, as I figure with such a tremendous load on whomever is maintaining the system, you are not going to get great explanations sometimes.

Again, I am sorry that that offended you.

Chris
WB4ULK


Re: MMDVM User Authentication

Cort N0MJS <n0mjs@...>
 

Alright boys… give that a shot.

On Jul 11, 2018, at 8:42 AM, Rod - KC7AAD <kc7aad@...> wrote:

I think white listing would be better. Deny all unless they match in a list.

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






Re: Allstarling.org Contact

Chris WB4ULK
 

Kevin,

I'm sorry if I offended you with that light hearted comment. I can only imagine what work goes into keeping this thing up.

I was not looking for someone to hold my hand when I wrote an email asking what was going on with the registration server several months ago. I was writing asking about it because the registration server is completely out of my control. The answer I got back did not answer to my question, instead I was told to get a mentor.

I took this with a grain of salt and waited the issue out with nothing else said. What else could I do? The comment above was nothing more than a making light of the situation, as I figure with such a tremendous load on whomever is maintaining the system, you are not going to get great explanations sometimes.

Again, I am sorry that that offended you.

Chris
WB4ULK


Re: DMRLink - bridge streams over writing.

Peter M0NWI
 


Ah OK, I didn't get that from the config text I was hoping to link pairs or Masters as trunk group, will have to look again.

Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:51:17
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Any system you designate as “TRUNK” will become one. There was never a limitation to one. All “TRUNK” does is remove the contention handler completely. I don’t use it a lot, but N3FE who hangs out on here is kinda the TRUNK guru. If I screw up something with the TRUNK code, Corey is the one who usually finds it first :)


On Jul 11, 2018, at 2:46 PM, Peter M0NWI <peter-martin@...> wrote:


Hehe, yes got that after looking at it for a bit, all rebuilt now just under 1000 lines in my config!   Swapped over into operation, and seems OK from my limited testing.

Best not to tell the users or they'll point out every error, and see if anyone shouts about the crashing TG being fixed?

What would have been nice, would have been to have more than one TRUNKS section, is that possible?

Thanks Cort.

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:25:54
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You just have to switch thinking that the configuration is centered on a group of arbitrarily named “conference bridges”. Each conference bridge is just like a telephone conference bridge – anyone may “dial into” it. Just think about, for each system (master peer or peer), which TS/TGID combination do you want to be part of a bridge?

I always thought bridge.py was ok, too – but an overwhelming majority had asked for an easier to configure version, and two was a bit too much to keep maintaining :)

On Jul 11, 2018, at 11:05 AM, Peter M0NWI <peter-martin@...> wrote:

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!

Just my tuppence :)

Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run!  

But, like the British Rail adverts from the '70s, "we're getting there!" 

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



--
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






Re: DMRLink - bridge streams over writing.

Cort N0MJS <n0mjs@...>
 

Any system you designate as “TRUNK” will become one. There was never a limitation to one. All “TRUNK” does is remove the contention handler completely. I don’t use it a lot, but N3FE who hangs out on here is kinda the TRUNK guru. If I screw up something with the TRUNK code, Corey is the one who usually finds it first :)


On Jul 11, 2018, at 2:46 PM, Peter M0NWI <peter-martin@...> wrote:


Hehe, yes got that after looking at it for a bit, all rebuilt now just under 1000 lines in my config!   Swapped over into operation, and seems OK from my limited testing.

Best not to tell the users or they'll point out every error, and see if anyone shouts about the crashing TG being fixed?

What would have been nice, would have been to have more than one TRUNKS section, is that possible?

Thanks Cort.

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:25:54
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You just have to switch thinking that the configuration is centered on a group of arbitrarily named “conference bridges”. Each conference bridge is just like a telephone conference bridge – anyone may “dial into” it. Just think about, for each system (master peer or peer), which TS/TGID combination do you want to be part of a bridge?

I always thought bridge.py was ok, too – but an overwhelming majority had asked for an easier to configure version, and two was a bit too much to keep maintaining :)

On Jul 11, 2018, at 11:05 AM, Peter M0NWI <peter-martin@...> wrote:

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!

Just my tuppence :)

Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run!  

But, like the British Rail adverts from the '70s, "we're getting there!" 

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



--
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






Re: DMRLink - bridge streams over writing.

Peter M0NWI
 


Hehe, yes got that after looking at it for a bit, all rebuilt now just under 1000 lines in my config!   Swapped over into operation, and seems OK from my limited testing.

Best not to tell the users or they'll point out every error, and see if anyone shouts about the crashing TG being fixed?

What would have been nice, would have been to have more than one TRUNKS section, is that possible?

Thanks Cort.


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 20:25:54
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You just have to switch thinking that the configuration is centered on a group of arbitrarily named “conference bridges”. Each conference bridge is just like a telephone conference bridge – anyone may “dial into” it. Just think about, for each system (master peer or peer), which TS/TGID combination do you want to be part of a bridge?

I always thought bridge.py was ok, too – but an overwhelming majority had asked for an easier to configure version, and two was a bit too much to keep maintaining :)

On Jul 11, 2018, at 11:05 AM, Peter M0NWI <peter-martin@...> wrote:

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!

Just my tuppence :)

Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run!  

But, like the British Rail adverts from the '70s, "we're getting there!" 

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



--
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






Re: Shameless Request

Steve N4IRS
 

DO NOT junk the HSOs I'll take them.

Steve

On 7/11/2018 3:27 PM, Cort N0MJS via Groups.Io wrote:
I’ll take the PAs and you can junk the rest :)

On Jul 11, 2018, at 11:38 AM, Jon K1IMD <lists@...> wrote:

Cort,
I don't have any GE/Johnson/Moto PA's BUT I do have a couple complete 100w MSF5000 UHF repeaters tuned up on the ham band... the price is right but the shipping would be insane!  You or Gavin coming east soon?  I'll hook you up...
73
Jon
K1iMD

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







Re: Shameless Request

Cort N0MJS <n0mjs@...>
 

I’ll take the PAs and you can junk the rest :)

On Jul 11, 2018, at 11:38 AM, Jon K1IMD <lists@...> wrote:

Cort,
I don't have any GE/Johnson/Moto PA's BUT I do have a couple complete 100w MSF5000 UHF repeaters tuned up on the ham band... the price is right but the shipping would be insane!  You or Gavin coming east soon?  I'll hook you up...
73
Jon
K1iMD

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






Re: Shameless Request

Cort N0MJS <n0mjs@...>
 

Oh hell – yes, it would be less expensive to just buy one than to ship one of those monsters – Peter, you’re off the hook for now, but someday I’ll need some trinket you have that weighs less!

On Jul 11, 2018, at 11:01 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Don't have any of the kit sorry, and it might be difficult to get it across the pond!

BUT!  If you've got a PayPal, I'm happy to chip in a few bucks if that's of use, for all the help you've given me personally, my repeater group, and the hobby over the years!!

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:52
To: DVSwitch@groups.io
Subject: [DVSwitch] Shameless Request
 
Guys,

Here’s the deal. In addition to writing this software, I also try to run a fistful of repeaters in Northeast and Northcentral Kansas. That stuff competes with hblink/dmrlink development – and usually wins. It’s production repeaters people rely on. Seems to always get in front of adding features, etc.

Some of you may have RF hardware resources that I don’t have, and I’m thinking, maybe there’s a way to free up more time. I’m looking for (good working order) UHF PAs from EF Johnson CR series repeaters, or similar. Stuff that takes a few watts in (5-10, typically) and makes 75-100w out. If anyone would like to donate or sell cheap as a “thank you”, I’d be both grateful and have more time to work on code. Likewise if there’s anyone who has experience re-building these amps and the tools/documentation, etc. to do it, you might also volunteer to rebuild an amp. I don’t really have the tools (enough heat, stockpile of the chip capacitors, etc.) to do this right, and it takes me forever to get anywhere.

Ok, yes, I just pretty much begged for UHF PAs.. but I though, what the hell? Maybe someone’s sitting on a lifetime supply out there :)

0x49 DE N0MJS

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









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






Re: DMRLink - bridge streams over writing.

Cort N0MJS <n0mjs@...>
 

You just have to switch thinking that the configuration is centered on a group of arbitrarily named “conference bridges”. Each conference bridge is just like a telephone conference bridge – anyone may “dial into” it. Just think about, for each system (master peer or peer), which TS/TGID combination do you want to be part of a bridge?

I always thought bridge.py was ok, too – but an overwhelming majority had asked for an easier to configure version, and two was a bit too much to keep maintaining :)

On Jul 11, 2018, at 11:05 AM, Peter M0NWI <peter-martin@...> wrote:

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!

Just my tuppence :)

Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run!  

But, like the British Rail adverts from the '70s, "we're getting there!" 

73,
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



--
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






Re: Shameless Request

Jon K1IMD
 

Cort,
I don't have any GE/Johnson/Moto PA's BUT I do have a couple complete 100w MSF5000 UHF repeaters tuned up on the ham band... the price is right but the shipping would be insane!  You or Gavin coming east soon?  I'll hook you up...
73
Jon
K1iMD


Re: DMRLink - bridge streams over writing.

Peter M0NWI
 

Bridge.py is GREAT!  Not hard to do at all, in fact very logical and really flexible!


Just my tuppence :)


Having a go with confBridge, but its quite difficult to get it to do what because of the multiple masters I run! 


But, like the British Rail adverts from the '70s, "we're getting there!"


73,

Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:29
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



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






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






Re: Shameless Request

Peter M0NWI
 

Hi Cort,


Don't have any of the kit sorry, and it might be difficult to get it across the pond!


BUT!  If you've got a PayPal, I'm happy to chip in a few bucks if that's of use, for all the help you've given me personally, my repeater group, and the hobby over the years!!


73,

Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 16:52
To: DVSwitch@groups.io
Subject: [DVSwitch] Shameless Request
 
Guys,

Here’s the deal. In addition to writing this software, I also try to run a fistful of repeaters in Northeast and Northcentral Kansas. That stuff competes with hblink/dmrlink development – and usually wins. It’s production repeaters people rely on. Seems to always get in front of adding features, etc.

Some of you may have RF hardware resources that I don’t have, and I’m thinking, maybe there’s a way to free up more time. I’m looking for (good working order) UHF PAs from EF Johnson CR series repeaters, or similar. Stuff that takes a few watts in (5-10, typically) and makes 75-100w out. If anyone would like to donate or sell cheap as a “thank you”, I’d be both grateful and have more time to work on code. Likewise if there’s anyone who has experience re-building these amps and the tools/documentation, etc. to do it, you might also volunteer to rebuild an amp. I don’t really have the tools (enough heat, stockpile of the chip capacitors, etc.) to do this right, and it takes me forever to get anywhere.

Ok, yes, I just pretty much begged for UHF PAs.. but I though, what the hell? Maybe someone’s sitting on a lifetime supply out there :)

0x49 DE N0MJS

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









Shameless Request

Cort N0MJS <n0mjs@...>
 

Guys,

Here’s the deal. In addition to writing this software, I also try to run a fistful of repeaters in Northeast and Northcentral Kansas. That stuff competes with hblink/dmrlink development – and usually wins. It’s production repeaters people rely on. Seems to always get in front of adding features, etc.

Some of you may have RF hardware resources that I don’t have, and I’m thinking, maybe there’s a way to free up more time. I’m looking for (good working order) UHF PAs from EF Johnson CR series repeaters, or similar. Stuff that takes a few watts in (5-10, typically) and makes 75-100w out. If anyone would like to donate or sell cheap as a “thank you”, I’d be both grateful and have more time to work on code. Likewise if there’s anyone who has experience re-building these amps and the tools/documentation, etc. to do it, you might also volunteer to rebuild an amp. I don’t really have the tools (enough heat, stockpile of the chip capacitors, etc.) to do this right, and it takes me forever to get anywhere.

Ok, yes, I just pretty much begged for UHF PAs.. but I though, what the hell? Maybe someone’s sitting on a lifetime supply out there :)

0x49 DE N0MJS

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


Re: MMDVM User Authentication

Cort N0MJS <n0mjs@...>
 

I have 2.5 days of vacation left and one project ahead of this. I *should* be able to get to this before the end of vacation.

My goal is to, assuming it works, is to list the relatively simpler ACL code from confbridge/hb_confbridge and put that into hblink.py as an option, and it will be regarding radio IDs and registration to hblink.py as a master.

0x49 DE N0MJS



On Jul 11, 2018, at 8:42 AM, Rod - KC7AAD <kc7aad@...> wrote:

I think white listing would be better. Deny all unless they match in a list.

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






Re: DMRLink - bridge streams over writing.

Cort N0MJS <n0mjs@...>
 

You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.

On Jul 11, 2018, at 9:20 AM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Thanks for you're answer, even if it's not what I wanted 😊

Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,
Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.  

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



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






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






Re: DMRLink - bridge streams over writing.

Peter M0NWI
 

Hi Cort,


Thanks for you're answer, even if it's not what I wanted 😊


Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!

73,

Peter




From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
 
Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired. 

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



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






Re: MMDVM User Authentication

Rod - KC7AAD
 

I think white listing would be better. Deny all unless they match in a list.


Re: MMDVM User Authentication

Rod - KC7AAD
 

That out of the way...

Cort, I agree that by DMR ID would be the better way. It's easy enough to blacklist (or remove from whitelist) if a user shares his ID with others. 
I do agree that administratively the user issue is tough to control. We have a few folks in our group that seem to flaunt that they push the line. Even after outright banning a user, they still continue to try and push. This is no different.
We will change the passwords at intervals, and that takes care of them for a while, until someone leaks it out.
We have around 70 users connecting to 8 servers up here in the PNW. 1 of which we allow "public" access and do share those credentials. The others have specific talkgroups allowed through them.

The VPN solution might work, though to make it seamless, it would require some work on the pi-star device and / or the openspot device. Neither of those options are easy to implement, if even possible.
I have thought about standing up instances for each user, then they could 'auth' to their own. We are using Docker to run multiple instances on one VM, varying them by UDP ports and passwords. The problem becomes how much administration would there be of this, and could the user dynamically change his own TG group? Or do we just give him one set? I'd be interested to see how Brandmeister does their setup for each hotspot being able to set up its own TG deck lineup, and having hundreds (thousands?) or users!


Regardless, Cort.. thanks for your work. I think that making a black / white list approach makes sense, barring any better way to do this without changes here as well as to the hotspots, too. That coordinated effort might not be easy.

Rod / KC7AAD


Re: MMDVM User Authentication

Rod - KC7AAD
 

YES!

8081 - 8100 of 9886