HBLink Testing


Steve N4IRS
 

I have setup a small Conference Bridge on reflector.dvswitch.org using HBlink for testing and demonstration of various features of HBlink, DMRlink and DVSwitch. I will expand the features as time (and programs) progress.
To start, I have HBlink listening for MMDVM connections on port 62031 with a password of passw0rd with the following bridges and applications.
TS2/TG3167 Bridged to BrandMeister TS2/TG3167
TS2/TG9990 is a parrot. What it hears, is what you get.
TS1/TG9999 Is a demo of the ability to send canned voice messages to a DMR user. "The time is..." (I have more work to do on this)

I will be adding connections to IPSC networks and allow connections from IPSC clients.  


David KE6UPI
 

Do you need testers? I can connect my DVMega if you like.

David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Tue, May 30, 2017 at 7:33 AM, Steve N4IRS <szingman@...> wrote:
I have setup a small Conference Bridge on reflector.dvswitch.org using HBlink for testing and demonstration of various features of HBlink, DMRlink and DVSwitch. I will expand the features as time (and programs) progress.
To start, I have HBlink listening for MMDVM connections on port 62031 with a password of passw0rd with the following bridges and applications.
TS2/TG3167 Bridged to BrandMeister TS2/TG3167
TS2/TG9990 is a parrot. What it hears, is what you get.
TS1/TG9999 Is a demo of the ability to send canned voice messages to a DMR user. "The time is..." (I have more work to do on this)

I will be adding connections to IPSC networks and allow connections from IPSC clients.  



Steve N4IRS
 

Sure, that is what it is there for. Point at reflector.dvswitch.org and test away.

On 5/30/2017 10:37 AM, David Shaw wrote:
Do you need testers? I can connect my DVMega if you like.

David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Tue, May 30, 2017 at 7:33 AM, Steve N4IRS <szingman@...> wrote:
I have setup a small Conference Bridge on reflector.dvswitch.org using HBlink for testing and demonstration of various features of HBlink, DMRlink and DVSwitch. I will expand the features as time (and programs) progress.
To start, I have HBlink listening for MMDVM connections on port 62031 with a password of passw0rd with the following bridges and applications.
TS2/TG3167 Bridged to BrandMeister TS2/TG3167
TS2/TG9990 is a parrot. What it hears, is what you get.
TS1/TG9999 Is a demo of the ability to send canned voice messages to a DMR user. "The time is..." (I have more work to do on this)

I will be adding connections to IPSC networks and allow connections from IPSC clients.  



Matthew 2E0SIP
 

I'm happy to give it a try, it will be approximately 20:30 UTC.


Nicola IT9FXF <onetechct@...>
 

Hi, I wanted to ask you if you can use confbridge connected to 2 hblink masters on the same computer. I made a small local network of testing and I would like to enable a TG for all connected repeaters and one in local to not commit all. Can you give me some advice? If there were any whitelist on the hblink master it would be very convenient to filter only the ones you need. At the moment I have 4 X MMDVM repeaters but we would like to connect others.Unfortunately from mmdvm we can do a whitelist only on the RF side and not on the network. I thank you in advance


Cort N0MJS <n0mjs@...>
 

Some answers inline

On Jan 24, 2018, at 9:44 PM, Nicola IT9FXF via Groups.Io <onetechct@...> wrote:

Hi, I wanted to ask you if you can use confbridge connected to 2 hblink masters on the same computer.

Yes. In the hblink.cfg file, you may specify any number of masters and clients. There is no limit to the number you can create – there is only a practical limit with the resources of the computer you’re running it on. This would be a good time to note that multi-core doesn’t really help here. Python will only execute on a single core. So, all other things being roughly equal, a dual-core at 3GHz is going to be a better bet than 8 cores at 2GHz… Not that hblink really uses much processor anyway, but I don’t recall discussion of that on here, so thought I’d mention it.

I made a small local network of testing and I would like to enable a TG for all connected repeaters and one in local to not commit all. Can you give me some advice?

All repeaters connected to the same master will share all traffic (if repeat is set to true). In confbridge_rules.py, create a “bridge” entry for each TS/TGID combination you wish to share. You make an entry in each bridge for each master you want to share traffic between. Example:

Here’s an example for hblink.cfg with two masters. Each may have one or more repeaters connected:

[MASTER-1]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 54000
PASSPHRASE: s3cr37w0rd
GROUP_HANGTIME: 5

[MASTER-2]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 54001
PASSPHRASE: s3cr37w0rd
GROUP_HANGTIME: 5

Now let’s say, for example, you want to share TS1/TGID100 between them. You’d need a bridge configuration like this (note the name of the bridge is arbitrary):

BRIDGES = {
    ’TALKGROUP 100': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
            {'SYSTEM': ‘MASTER-2',    'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
        ],
}

Note, TIMEOUT is meaningless, since you’re we’re not talking about more advanced features. TO_TYPE is ‘NONE’ and ON and OFF are empty lists. ACTIVE is true to enable both of the systems (MASTER-1 and MASTER-2). 

If there were any whitelist on the hblink master it would be very convenient to filter only the ones you need. At the moment I have 4 X MMDVM repeaters but we would like to connect others.Unfortunately from mmdvm we can do a whitelist only on the RF side and not on the network. I thank you in advance

What you’re talking about doing is what confbridge is for. A whitelist is used for access control – what you’re really talking about is call routing between masters, and that’s what confbridge.py is for. Why? because pretty soon, you’ll probably decide that you want it to be TGID100 on one repeater and TGID200 on another that are connected. Whitelists can’t do that. They also cannot translate Timeslots either.

Then as you grow a bit more, you may decide you want to only selectively turn on a connection between repeaters when a user wants it.

hblink.py is intended to pretty much be a protocol stack for Homebrew repeater protocol. It’s not intended to handle call-routing functions – and what you’re talking about here is call-routing between MMDVM repeaters.

To do all of this, you need to do nothing more than run confbridge.py instead of hblink.py and define the “bridges” you want to use.

I’ll throw a bit more in here – let’s say you have three MMDVM repeaters, you want nothing shared between them. They’re connected to three masters, and you want TS1/TGID100 on repeater1 connected to TS1/TGID100 on repeater2 and TS2/TGID33 on repeater3… the bridge would look like this:

BRIDGES = {
    ’MyRule1': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
            {'SYSTEM': ‘MASTER-2',    'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
            {'SYSTEM': ‘MASTER-3',    'TS': 2, 'TGID': 33,   'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
        ],
}

Let’s say you want to do that again, only TS1/TGID3000 connecting all… that would look like:

BRIDGES = {
    ’BRIDGE1': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
            {'SYSTEM': ‘MASTER-2',    'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
            {'SYSTEM': ‘MASTER-3',    'TS': 2, 'TGID': 33,   'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
        ],
    ’BRIDGE2': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 3000, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
            {'SYSTEM': ‘MASTER-2',    'TS': 1, 'TGID': 3000, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
            {'SYSTEM': ‘MASTER-3',    'TS': 1, 'TGID': 3000, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE',  'ON': [], 'OFF': []},
        ],
}

I hope this helps. A whitelist is an access control list that specifies something is accepted on ingress…. but it does not define what systems that traffic would egress on. In a sense, it’s only 1/2 of what you need to do the whole job. Yes, you could set up a fairly elaborate set of ingress access control lists (ACLs) to effectively achieve what you want, but it’s not really the right way because it doesn’t scale or allow more complex configurations.

0x49 DE N0MJS


Cort Buffington
785-865-7206