Date   

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!


Re: Allstarling.org Contact

 

On 7/11/2018 8:03 AM, Chris WB4ULK via Groups.Io wrote:
You probably won’t like the reply IF you get one. I have had this issue as well and the reply I got was. “Get a mentor. “ lol
Don't expect the folks at ASL to hold your hand.  After all, this is a hobby, one that its creator recently passed away leaving a HUGE void to fill.  Some hams expect premium support for their free software, and then cop the attitude we see here when they don't get that.  Please understand that the folks at ASL have doing the best 'they' can - considering.  Let me explain...

When Jim Dixon died, the project of AllStarLink fell onto Jim's partner Steve RoDgers.  Steve hadn't been real active with ASL at the time Jim died because of his work.  At this time, the administration of ASL was the responsibility of Tim Sawyer.  There were several people that were immediately notified of Jim's death, and I was one of them.  I was asked by Steve RoDgers my opinion, and to help assemble people that would continue with the project.  I contacted Steve Zingman, and he agreed to take AllStarLink, and make it into a project of several people so (the organization) could survive the worst.  Steve did exactly that, and so AllStarLink Inc. was formed.  AllStarLink Inc. is a NON for profit entity whose goals are to insure the continuance of the project, with the vision and usefulness that Jim Dixon intended.  AllStarLink Inc. is currently four Board members and additionally two teams of folks, one for Admin, and one for developing and patching software (DEV). AllStarLink Inc., is responsible for many things, including but not limited to vetting licensed amateur radio operators and approving new ASL memberships, issuing ASL node numbers, paying hosting bills for dedicated servers which make the system accessible by its members/users, keeping said servers running, developing software, fixing bugs, adding new features, etc.

Whether you use XIPAR, HamVoip, or the official software of AllStarLink, every public user consumes resources of AllStarLink Inc.  Please understand it's not free to run AllStarlink, and donations of money and time from its users is greatly appreciated!

Are there things that could be done better - oh heck yea....   One of the things the Board members discussed this weekend is to revamp the website at allstarlink.org making it more user friendly.  Jim Dixon was a brilliant man, but there were things that were done that seemed to only make sense to him.  One of them is the fact that once you became a member, and logged into the ASL site, the links to the software downloads would magically disappear!  We have a laundry list of things that needs done, and we simply ask your patience as we recruit more helpers and work through the list.  So far it's been a full time job just keeping AllStarLink stable and reachable, let alone making improvements to its user interfaces and providing free support.

Kevin Custer W3KKC
Board Member
AllStarLink, Inc.


Re: DMRLink - bridge streams over writing.

Cort N0MJS <n0mjs@...>
 

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: Allstarling.org Contact

Chris WB4ULK
 

You probably won’t like the reply IF you get one. I have had this issue as well and the reply I got was. “Get a mentor. “ lol


DMRLink - bridge streams over writing.

Peter M0NWI
 

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



Re: Allstarling.org Contact

Mike KB8JNM
 

On 7/10/2018 11:55 AM, David KG5RDF wrote:
That did not work, sorry senior moment.

-------- Original message --------
From: David KG5RDF <David@...>
Date: 7/10/18 10:44 AM (GMT-06:00)
Subject: Re: [DVSwitch] Allstarling.org Contact

Mike, 

(Off List)

Thanks, I will look for the list to join. We have several nodes. The issue we are having, is the Allstarlink.org servers forget about registered nodes in operation. This issue is happening across the allstar community. It just hit or miss, if your nodes gets effected. Yesterday, I had to abandon a node 47613, that has been in operation for registration/connection issues and use a different node number to get the repetear linked site back up. Having a successful ping of allstarlink.org does not indicate that you will be able to connect again. Most of our effected nodes, will come around after a few hours after a reboot.

I just want to make sure the right people are aware of this issue.

Thank you for the reply!

David KG5RDF
nctc.info

-------- Original message --------
From: Mike KB8JNM <groupio@...>
Date: 7/10/18 8:04 AM (GMT-06:00)
Subject: Re: [DVSwitch] Allstarling.org Contact

Well David,
Probably should join the app_rpt mail list but,

If I understand your issue
Your issue is a matter of registration from your system.

Look in your iax.conf and see that you have a line with correct password data like this....

register = 48396:9b3e98a6aacd1@...    ; This must be changed to your node number, password
                                                    ; remove the leading ";"

You may need to verify your password for type error by checking it against that stored at the node data at allstarlink.org

Once that is rx and logged, your IP connection data will go into the list spread to all nodes within about 20 minutes and show in the list of connectable nodes
at allstarlink.org

So, if you have verified that is correct,and still having a issue, let me know. And state the node number in question.


Re: Allstarling.org Contact

David KG5RDF
 

That did not work, sorry senior moment.

-------- Original message --------
From: David KG5RDF <David@...>
Date: 7/10/18 10:44 AM (GMT-06:00)
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Allstarling.org Contact

Mike, 

(Off List)

Thanks, I will look for the list to join. We have several nodes. The issue we are having, is the Allstarlink.org servers forget about registered nodes in operation. This issue is happening across the allstar community. It just hit or miss, if your nodes gets effected. Yesterday, I had to abandon a node 47613, that has been in operation for registration/connection issues and use a different node number to get the repetear linked site back up. Having a successful ping of allstarlink.org does not indicate that you will be able to connect again. Most of our effected nodes, will come around after a few hours after a reboot.

I just want to make sure the right people are aware of this issue.

Thank you for the reply!

David KG5RDF
nctc.info
http://stats.allstarlink.org/getstatus.cgi?47115

-------- Original message --------
From: Mike KB8JNM <groupio@...>
Date: 7/10/18 8:04 AM (GMT-06:00)
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Allstarling.org Contact

Well David,
Probably should join the app_rpt mail list but,

If I understand your issue
Your issue is a matter of registration from your system.

Look in your iax.conf and see that you have a line with correct password data like this....

register = 48396:9b3e98a6aacd1@...    ; This must be changed to your node number, password
                                                    ; remove the leading ";"

You may need to verify your password for type error by checking it against that stored at the node data at allstarlink.org

Once that is rx and logged, your IP connection data will go into the list spread to all nodes within about 20 minutes and show in the list of connectable nodes
at allstarlink.org

So, if you have verified that is correct,and still having a issue, let me know. And state the node number in question.


Re: Allstarling.org Contact

David KG5RDF
 

Mike, 

(Off List)

Thanks, I will look for the list to join. We have several nodes. The issue we are having, is the Allstarlink.org servers forget about registered nodes in operation. This issue is happening across the allstar community. It just hit or miss, if your nodes gets effected. Yesterday, I had to abandon a node 47613, that has been in operation for registration/connection issues and use a different node number to get the repetear linked site back up. Having a successful ping of allstarlink.org does not indicate that you will be able to connect again. Most of our effected nodes, will come around after a few hours after a reboot.

I just want to make sure the right people are aware of this issue.

Thank you for the reply!

David KG5RDF
nctc.info
http://stats.allstarlink.org/getstatus.cgi?47115

-------- Original message --------
From: Mike KB8JNM <groupio@...>
Date: 7/10/18 8:04 AM (GMT-06:00)
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Allstarling.org Contact

Well David,
Probably should join the app_rpt mail list but,

If I understand your issue
Your issue is a matter of registration from your system.

Look in your iax.conf and see that you have a line with correct password data like this....

register = 48396:9b3e98a6aacd1@...    ; This must be changed to your node number, password
                                                    ; remove the leading ";"

You may need to verify your password for type error by checking it against that stored at the node data at allstarlink.org

Once that is rx and logged, your IP connection data will go into the list spread to all nodes within about 20 minutes and show in the list of connectable nodes
at allstarlink.org

So, if you have verified that is correct,and still having a issue, let me know. And state the node number in question.

8021 - 8040 of 9819