Date   

Re: Removing Validation from hblink.py master

Mike KB8JNM
 

Yes, after I wrote that, I realized there may be some confusion using a colon and would recommend using a comma or something else like a tilde
" ~ " and slot number so not to confuse it with a 'port' .

...mike/kb8jnm

On 7/31/2018 9:37 PM, Cort N0MJS via Groups.Io wrote:
I believe I just said that I’ll use the IP address and the port… or are you recommend it be a string concatenation of the dotted quad IP address, a colon, and the string representation of the port number?
I’ll be looking for the fastest way to do the match for each packet. I don’t mind spending processor time when a machine registers building the identifier then – a few cycles doesn’t bother me during registration, but here we’re also talking about a match that has to take place on every packet traversing the system * number of clients in the system.
Are you thinking that a string comprehension with an integer to string conversion is the fastest way to do that?

On Jul 31, 2018, at 7:52 PM, Mike KB8JNM <groupio@midnighteng.com> wrote:

Could it be - "IP:slot"
12.345.123.123:01

????????

Just a thought !

...mike/kb8jnm

On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.
On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@marrold.co.uk> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers

Cort Buffington
785-865-7206

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


Re: Removing Validation from hblink.py master

Cort N0MJS <n0mjs@...>
 

I believe I just said that I’ll use the IP address and the port… or are you recommend it be a string concatenation of the dotted quad IP address, a colon, and the string representation of the port number?

I’ll be looking for the fastest way to do the match for each packet. I don’t mind spending processor time when a machine registers building the identifier then – a few cycles doesn’t bother me during registration, but here we’re also talking about a match that has to take place on every packet traversing the system * number of clients in the system.

Are you thinking that a string comprehension with an integer to string conversion is the fastest way to do that?

On Jul 31, 2018, at 7:52 PM, Mike KB8JNM <groupio@midnighteng.com> wrote:

Could it be - "IP:slot"
12.345.123.123:01

????????

Just a thought !

...mike/kb8jnm

On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.
On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@marrold.co.uk> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers

Cort Buffington
785-865-7206

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


Re: Removing Validation from hblink.py master

Mike KB8JNM
 

Could it be - "IP:slot"
12.345.123.123:01

????????

Just a thought !

...mike/kb8jnm

On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.

On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@marrold.co.uk> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers

Cort Buffington
785-865-7206


Re: IPSC protocol to HB protocol on ASL to DMR bridge

Tom
 

Thanks for the info on the new install to setup HB protocol on my ASL-DMR bridge (instead of IPSC).  Before I rebuild my working configuration, is there a way to also use it to continue to access cbridge DMR-MARC connections. I am currently switching between cbridge and BM with shell scripts (ALS DTMF controllable).

Tom

 

From: main@DVSwitch.groups.io [mailto:main@DVSwitch.groups.io] On Behalf Of Tom
Sent: Monday, July 30, 2018 7:26 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] IPSC protocol to HB protocol on ASL to DMR bridge

 

Since my current configuration of ASL to DMR bridge also is used to communicate with cbridge DMR-MARC connections (I have shell scripts to change configuration files), will the new build allow this?


Re: HELP needed for building a bridge from TeamSpeak to either YSF, ASL or wires-X ??.

Steven Blackford
 

Joe,
  What you're wanting to do involves a couple of different bridges.  First you'd need to setup up a bridge from AllStar to your YSF Reflector.  It'd look like this ASL<->Analog_Bridge<->YSFGateway<->YSFReflector.  If you're wanting to bridge a YSFReflector to a Wires-X Node, you'll need to setup an RF Bridge there.  On the Carolina Link, I use an RF Bridge between our YSF Reflector, my Wires-X Node, & a connection over to FCS003/33.  This actually works really well & has been stable.  I use an OpenSpot connected to the YSF Reflector & a DV-Mega going over to the FCS003/33 on the same simplex frequency as my Wires-X node.

Finally to link over to TeamSpeak, you basically use 3 pieces of software.  You use the TeamSpeak 3 software, Zoiper to dial into your AllStar Node, & finally Virtual Audio Cables to tie the TS3 Client/Zoiper together.  This works well, but you will find you need to keep an eye on Zoiper.  It's best to restart the software every day or two.  Not a big deal, but it'll save you from having audio issues, etc.  Hope that explains things better.  73 de K4SQI!

Steve, K4SQI

On Tue, Jul 31, 2018 at 1:55 PM, Joe Condron <condronj@...> wrote:
Good afternoon all,

I need HELP to build a bridge from TeamSpeak to either YSF, ASL or wires-X.
Which one is the easiest option, and how do I do it?. Any help is Appreciated.

Thank you for reading.

Warmest regards
Joe G7kdz.




--
-----
Steve, kb7sqi@...


HELP needed for building a bridge from TeamSpeak to either YSF, ASL or wires-X ??.

Joe Condron
 

Good afternoon all,

I need HELP to build a bridge from TeamSpeak to either YSF, ASL or wires-X.
Which one is the easiest option, and how do I do it?. Any help is Appreciated.

Thank you for reading.

Warmest regards
Joe G7kdz.


Re: HBlink ACL error

Bill N2WNS
 

Fixed!

Thank you.

Bill


Re: HBlink ACL error

Cort N0MJS <n0mjs@...>
 

I fixed that just last night. Try pulling again


On Jul 30, 2018, at 6:50 AM, Bill Hausmann <n2wns.radio@...> wrote:

Good Day all, I'm just getting started with HBlink/DMRlink and I'm receiving an error when starting HBlink:

DEBUG 2018-07-30 07:48:12,103 Logging system started, anything from here on gets logged
INFO 2018-07-30 07:48:12,103 Registration ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
INFO 2018-07-30 07:48:12,103 Registration ACL file not found or invalid - all IDs are valid
Traceback (most recent call last):
  File "hblink.py", line 650, in <module>
    ACL = build_acl('reg_acl')
  File "hblink.py", line 144, in build_acl
    return ACL
UnboundLocalError: local variable 'ACL' referenced before assignment

DMRlink is running fine.

Thank You,

Bill


Re: IPSC protocol to HB protocol on ASL to DMR bridge

Tom
 

Since my current configuration of ASL to DMR bridge also is used to communicate with cbridge DMR-MARC connections (I have shell scripts to change configuration files), will the new build allow this?


HBlink ACL error

Bill N2WNS
 

Good Day all, I'm just getting started with HBlink/DMRlink and I'm receiving an error when starting HBlink:

DEBUG 2018-07-30 07:48:12,103 Logging system started, anything from here on gets logged
INFO 2018-07-30 07:48:12,103 Registration ACL file found, importing entries. This will take about 1.5 seconds per 1 million IDs
INFO 2018-07-30 07:48:12,103 Registration ACL file not found or invalid - all IDs are valid
Traceback (most recent call last):
  File "hblink.py", line 650, in <module>
    ACL = build_acl('reg_acl')
  File "hblink.py", line 144, in build_acl
    return ACL
UnboundLocalError: local variable 'ACL' referenced before assignment

DMRlink is running fine.

Thank You,

Bill


Re: Removing Validation from hblink.py master

Cort N0MJS <n0mjs@...>
 

Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.

I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.


On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@...> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers


Cort Buffington
785-865-7206


Re: IPSC protocol to HB protocol on ASL to DMR bridge

Steve N4IRS
 

Tom,
Here is the howto to build a ASL <-> DMR bridge ASL <-> DMR Bridge howto.
There is also a subgroup dedicated to bridging digital modes to ASL https://dvswitch.groups.io/g/allstarlink

73, Steve N4IRS


IPSC protocol to HB protocol on ASL to DMR bridge

Tom
 

I have an ASL to DMR bridge using a DV3000 with a RPi-3B. How do I change from IPSC protocol to HB protocol for Brandmeister connections?
Thanks,
Tom / K5TRA


Re: Removing Validation from hblink.py master

Matthew 2E0SIP
 

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers


Re: Removing Validation from hblink.py master

Cort N0MJS <n0mjs@...>
 

Brandmeister always hands me my own radio id in the “repeater id” field, bytes 11-14 (inclusive) in the DMRD…. If anyone has seen different, let me know soon. I’m about ready to normalize it all so that a master always sends the client’s ID to it in that field, and a client always uses it’s ID in transmissions to the master. This will fix a few discrepancies, and will be done in hblink.py so all applications will be normalized in the process.

Speak now please….

0x49 DE N0MJS

On Jul 28, 2018, at 8:58 PM, Cort N0MJS via Groups.Io <n0mjs@...> wrote:

Ok, I’m going to admit to having not looked at any of this for a long time. I've found a few discrepancies in what I’ve done over time

I have a question that needs answered by the stewards of HB Protocol:

Should the “repeater_id” field (bytes 11-14 of the DMRD), when a master is sending to a client, be the radio ID of the client, or the radio ID of the originating repeater? I’ve sorta treated it both ways and don’t apparently know the real answer.

What is that field really about? And is it the same in either direction? (client -> master and master -> client).


With that answered I can clean up this entire mess once and for all. I asked G4KLX a question about HBP once and the answer I got was read the (completely un-commended C++) source code of MMDVM and figure it out… Not helpful. Brandmeister does not approve of or want HBlink talking to their system… so not a good move either. Maybe the DMR+ guys are more help, but I don’t know them. Maybe one of you who is friendlier with BM or Jonathan can get us an answer?


On Jul 28, 2018, at 4:15 PM, Matthew 2E0SIP <groups.io@...> wrote:

Hi Cort,

Understood on the muddling of OSI layers - I get where you're coming from.

I think the easiest work around in that case is an option to rewrite the RADIO_ID for frames being sent to a Master to hblink's own Client RADIO_ID, as you suggested. 

Cheers


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






Cort Buffington
785-865-7206


Re: Allstarlink dvswitch raspberry pi 3 b+

Steve N4IRS
 

ASL does not have a conference.

On 07/29/2018 06:41 PM, Dennis Ramos wrote:
In fact, nodes can be link together by sending them in a conference.

Just a thought

Best regards

Dennis/ m0tfg

On 29 July 2018 23:22:41 BST, Steve N4IRS <szingman@...> wrote:


On 07/29/2018 06:20 PM, Dennis Ramos wrote:
Thanks for the reply Steve. I remember before computing power of an asterisk is based on a concurrent calls.

Anyway I just wonder if it is possible to have more than one dmr talkgroup or other digital mode by having additional node that link to those additional tg.
Yes, it can be done that way.

Furthermore, by disabling the macro *31999, manually connect(dtmf) the main node to node1, node2, node3 and so on.
Sure.

73

Dennis

On 29 July 2018 22:31:57 BST, Steve N4IRS <szingman@...> wrote:
Dennis,
I can't directly answer your question, I think it would be worth a try. I can point you to this interesting article. https://medium.com/@ghalfacree/benchmarking-the-raspberry-pi-3-b-plus-44122cf3d806
Notice the changes in the networking.

73, Steve N4IRS

On 07/28/2018 03:20 PM, m0tfg@... wrote:
Does raspberry pi 3 B+ have enough computing power to be a hub/bridge that can handle 20 to 50 connected nodes?

Thanks very much guys for your support

73

Dennis




Re: Allstarlink dvswitch raspberry pi 3 b+

Dennis Ramos
 

In fact, nodes can be link together by sending them in a conference.

Just a thought

Best regards

Dennis/ m0tfg


On 29 July 2018 23:22:41 BST, Steve N4IRS <szingman@...> wrote:


On 07/29/2018 06:20 PM, Dennis Ramos wrote:
Thanks for the reply Steve. I remember before computing power of an asterisk is based on a concurrent calls.

Anyway I just wonder if it is possible to have more than one dmr talkgroup or other digital mode by having additional node that link to those additional tg.
Yes, it can be done that way.

Furthermore, by disabling the macro *31999, manually connect(dtmf) the main node to node1, node2, node3 and so on.
Sure.

73

Dennis

On 29 July 2018 22:31:57 BST, Steve N4IRS <szingman@...> wrote:
Dennis,
I can't directly answer your question, I think it would be worth a try. I can point you to this interesting article. https://medium.com/@ghalfacree/benchmarking-the-raspberry-pi-3-b-plus-44122cf3d806
Notice the changes in the networking.

73, Steve N4IRS

On 07/28/2018 03:20 PM, m0tfg@... wrote:
Does raspberry pi 3 B+ have enough computing power to be a hub/bridge that can handle 20 to 50 connected nodes?

Thanks very much guys for your support

73

Dennis



Re: Allstarlink dvswitch raspberry pi 3 b+

Steve N4IRS
 



On 07/29/2018 06:20 PM, Dennis Ramos wrote:
Thanks for the reply Steve. I remember before computing power of an asterisk is based on a concurrent calls.

Anyway I just wonder if it is possible to have more than one dmr talkgroup or other digital mode by having additional node that link to those additional tg.
Yes, it can be done that way.

Furthermore, by disabling the macro *31999, manually connect(dtmf) the main node to node1, node2, node3 and so on.
Sure.

73

Dennis

On 29 July 2018 22:31:57 BST, Steve N4IRS <szingman@...> wrote:
Dennis,
I can't directly answer your question, I think it would be worth a try. I can point you to this interesting article. https://medium.com/@ghalfacree/benchmarking-the-raspberry-pi-3-b-plus-44122cf3d806
Notice the changes in the networking.

73, Steve N4IRS

On 07/28/2018 03:20 PM, m0tfg@... wrote:
Does raspberry pi 3 B+ have enough computing power to be a hub/bridge that can handle 20 to 50 connected nodes?

Thanks very much guys for your support

73

Dennis



Re: Allstarlink dvswitch raspberry pi 3 b+

Dennis Ramos
 

Thanks for the reply Steve. I remember before computing power of an asterisk is based on a concurrent calls.

Anyway I just wonder if it is possible to have more than one dmr talkgroup or other digital mode by having additional node that link to those additional tg.

Furthermore, by disabling the macro *31999, manually connect(dtmf) the main node to node1, node2, node3 and so on.

73

Dennis


On 29 July 2018 22:31:57 BST, Steve N4IRS <szingman@...> wrote:
Dennis,
I can't directly answer your question, I think it would be worth a try. I can point you to this interesting article. https://medium.com/@ghalfacree/benchmarking-the-raspberry-pi-3-b-plus-44122cf3d806
Notice the changes in the networking.

73, Steve N4IRS

On 07/28/2018 03:20 PM, m0tfg@... wrote:
Does raspberry pi 3 B+ have enough computing power to be a hub/bridge that can handle 20 to 50 connected nodes?

Thanks very much guys for your support

73

Dennis


Re: Allstarlink dvswitch raspberry pi 3 b+

Steve N4IRS
 

Dennis,
I can't directly answer your question, I think it would be worth a try. I can point you to this interesting article. https://medium.com/@ghalfacree/benchmarking-the-raspberry-pi-3-b-plus-44122cf3d806
Notice the changes in the networking.

73, Steve N4IRS

On 07/28/2018 03:20 PM, m0tfg@... wrote:
Does raspberry pi 3 B+ have enough computing power to be a hub/bridge that can handle 20 to 50 connected nodes?

Thanks very much guys for your support

73

Dennis

7521 - 7540 of 9518