Re: HBLink Testing


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

Join main@DVSwitch.groups.io to automatically receive all group messages.