HBlink3: Guida completa per creare la tua rete digitale radioamatoriale.

Views: 4

HBlink3 è uno dei software più interessanti per chi desidera realizzare una rete DMR indipendente, collegare ripetitori MMDVM, interconnettere più server o sperimentare con talkgroup, bridge e collegamenti OpenBridge.

Non è però un programma completamente “plug and play”: per utilizzarlo correttamente occorre comprendere almeno i concetti fondamentali del protocollo DMR, dei timeslot, dei talkgroup, delle porte UDP e delle configurazioni MMDVM.

In questa guida vedremo:

• che cos’è HBlink;
• a cosa serve;
• come funziona una rete HBlink;
• come installare HBlink3 su Debian o Ubuntu;
• come configurare un server DMR;
• come collegare ripetitori e hotspot MMDVM;
• come creare una rete composta da più aree;
• come configurare talkgroup e bridge;
• come avviare HBlink automaticamente;
• come diagnosticare i problemi più comuni.

HBlink3 è oggi un’applicazione Python 3 basata su asyncio, capace di operare come server Homebrew, client verso un altro server e router di conferenza tra differenti sistemi DMR.

Che cos’è HBlink?

HBlink è un’implementazione open source del protocollo DMR Homebrew Repeater Protocol, spesso abbreviato in HBP.

Il protocollo Homebrew viene normalmente utilizzato da:

• ripetitori MMDVM;
• hotspot personali;
• DMRGateway;
• server DMR;
• software di interconnessione tra reti digitali.

HBlink può ricevere i flussi DMR provenienti dai ripetitori, analizzarne timeslot, talkgroup e ID, e inoltrarli verso altri ripetitori oppure verso altri sistemi.

In termini semplici, HBlink può essere considerato il “cuore di rete” che collega tra loro differenti nodi DMR.

A cosa serve HBlink?

Con HBlink è possibile:

• creare una rete DMR privata o associativa;
• collegare ripetitori MMDVM geograficamente distanti;
• collegare hotspot personali a un proprio server;
• realizzare talkgroup locali, regionali o nazionali;
• separare la rete in differenti aree operative;
• tradurre un talkgroup in un altro durante il transito;
• collegare due server HBlink;
• realizzare collegamenti OpenBridge;
• gestire chiamate di gruppo e chiamate private;
• applicare ACL per limitare ripetitori, utenti e talkgroup;
• monitorare collegamenti, chiamate e qualità delle connessioni.

HBlink3 è particolarmente adatto al routing tra sistemi e ai bridge di conferenza. Il programma principale per questa funzione è bridge.py, mentre hblink.py può essere utilizzato come server o client Homebrew semplice.

Come funziona una rete HBlink

Una rete elementare può essere rappresentata così:

Radio DMR
    |
    | RF
    v
Ripetitore MMDVM
    |
    | Internet - protocollo Homebrew UDP
    v
Server HBlink3
    |
    +------ Ripetitore MMDVM 2
    |
    +------ Hotspot MMDVM
    |
    +------ Altro server HBlink

Quando un radioamatore trasmette, il ripetitore invia al server HBlink i pacchetti contenenti, tra le altre cose:

• ID del radioamatore;
• ID del ripetitore;
• talkgroup di destinazione;
• timeslot utilizzato;
• tipo di chiamata;
• flusso vocale AMBE già codificato.

HBlink non deve decodificare e ricodificare la voce. Il suo compito principale è decidere verso quali sistemi inoltrare il flusso ricevuto.

I tre modi di funzionamento

SERVER

In modalità SERVER, HBlink ascolta su una porta UDP e accetta le connessioni provenienti da ripetitori, hotspot o altri client Homebrew.

È la modalità da utilizzare per creare il proprio master DMR.

OUTBOUND

In modalità OUTBOUND, HBlink si comporta come un ripetitore o hotspot e si collega a un altro server Homebrew.

Questa modalità può essere utilizzata per collegare due installazioni compatibili, ma non deve essere confusa con OpenBridge.

OPENBRIDGE

OpenBridge è un collegamento diretto server-to-server. Non prevede il normale login utilizzato dai ripetitori ed è autenticato mediante una chiave condivisa.

Il traffico di gruppo OpenBridge utilizza normalmente il timeslot logico 1. L’opzione per utilizzare entrambi gli slot deve essere impiegata esclusivamente tra server HBlink compatibili.

Requisiti del server

Per una piccola rete sono sufficienti:

• una VPS o un server Linux sempre acceso;
• Debian 12, Debian 13 oppure Ubuntu 22.04/24.04;
• almeno una CPU virtuale;
• almeno 512 MB di RAM per il solo core;
• 1 GB o più se si utilizza anche il dashboard;
• un indirizzo IP pubblico o un DNS dinamico;
• una porta UDP raggiungibile da Internet;
• accesso SSH con privilegi amministrativi.

Il progetto richiede Linux e Python 3.8 o successivo. L’installazione ufficiale utilizza un ambiente virtuale Python, soluzione particolarmente importante sulle distribuzioni moderne.

Scelta del server

La soluzione migliore è generalmente una piccola VPS con indirizzo IPv4 pubblico statico.

È possibile installare HBlink anche su:

• Raspberry Pi;
• mini PC;
• server domestico;
• macchina virtuale;
• container.

Se il server si trova dietro un router domestico, sarà necessario inoltrare la porta UDP scelta verso l’indirizzo IP locale del computer HBlink.

Installazione passo passo di HBlink3

1. Aggiornare il sistema

sudo apt update
sudo apt full-upgrade -y
sudo reboot

Dopo il riavvio, ricollegarsi mediante SSH.

2. Installare i pacchetti necessari

sudo apt install -y git python3 python3-venv python3-pip \
build-essential python3-dev ufw

3. Creare un utente dedicato

È preferibile non eseguire HBlink come utente root.

sudo useradd --system \
  --create-home \
  --home-dir /opt/hblink \
  --shell /usr/sbin/nologin \
  hblink

4. Scaricare HBlink3

sudo -u hblink git clone \
https://github.com/n0mjs710/hblink3.git \
/opt/hblink/hblink3

5. Creare l’ambiente virtuale Python

sudo -u hblink python3 -m venv \
/opt/hblink/hblink3/venv

6. Installare le dipendenze

sudo -u hblink \
/opt/hblink/hblink3/venv/bin/pip install --upgrade pip

sudo -u hblink \
/opt/hblink/hblink3/venv/bin/pip install \
-r /opt/hblink/hblink3/requirements.txt

Le dipendenze principali della versione attuale comprendono bitarray, dmr_utils3 e ijson. La parte di rete utilizza invece il modulo asyncio incluso in Python.

7. Creare i file di configurazione

sudo -u hblink cp \
/opt/hblink/hblink3/hblink-SAMPLE.cfg \
/opt/hblink/hblink3/hblink.cfg

sudo -u hblink cp \
/opt/hblink/hblink3/rules_SAMPLE.py \
/opt/hblink/hblink3/rules.py

Prima configurazione: una rete semplice

Iniziamo con la configurazione più semplice:

• un solo server HBlink;
• una porta UDP;
• due o più ripetitori collegati;
• stesso talkgroup e stesso timeslot su tutti i nodi.

Aprire il file:

sudo nano /opt/hblink/hblink3/hblink.cfg

Sostituirne il contenuto con il seguente esempio.

[GLOBAL]
PATH: ./
PING_TIME: 5
MAX_MISSED: 3
PING_LOSS_WINDOW: 5
PING_LOSS_WARN: 5

USE_ACL: True
REG_ACL: PERMIT:222000101,222000102
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL


[REPORTS]
REPORT: False
REPORT_INTERVAL: 10
REPORT_PORT: 4321
REPORT_CLIENTS: 127.0.0.1


[LOGGER]
LOG_FILE: /dev/null
LOG_HANDLERS: console-timed
LOG_LEVEL: INFO
LOG_NAME: HBlink


[ALIASES]
USE_ALIASES: False
TRY_DOWNLOAD: False
PATH: dashboard/
PEER_FILE: peer_ids.json
SUBSCRIBER_FILE: subscriber_ids.json
TGID_FILE: talkgroup_ids.json
PEER_URL: https://www.radioid.net/static/rptrs.json
SUBSCRIBER_URL: https://www.radioid.net/static/users.json
STALE_DAYS: 7


[RETE-LOCALE]
MODE: SERVER
ENABLED: True

REPEAT: True
MAX_REPEATERS: 20

IP: 0.0.0.0
PORT: 54000
PASSPHRASE: CAMBIA-QUESTA-PASSWORD

GROUP_HANGTIME: 5

USE_ACL: True
REG_ACL: PERMIT:222000101,222000102
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL

Significato dei parametri principali

REPEAT

Con:

REPEAT: True

il traffico ricevuto da un client viene ripetuto agli altri client collegati allo stesso sistema.

Se due ripetitori sono collegati alla sezione RETE-LOCALE, una trasmissione sul medesimo timeslot e talkgroup sarà quindi inoltrata tra i due.

PORT

PORT: 54000

È la porta UDP sulla quale HBlink attende i collegamenti dei ripetitori.

PASSPHRASE

PASSPHRASE: CAMBIA-QUESTA-PASSWORD

È la password condivisa che dovrà essere configurata anche nei ripetitori.

Utilizzare una password lunga, casuale e priva di spazi.

REG_ACL

REG_ACL: PERMIT:222000101,222000102

Permette la registrazione esclusivamente agli ID indicati.

Per una prova iniziale si potrebbe utilizzare:

REG_ACL: PERMIT:ALL

ma questa impostazione non è consigliata su un server pubblicamente raggiungibile.

SUB_ACL

Controlla gli ID degli utenti che generano il traffico.

SUB_ACL: DENY:1

Questa regola blocca l’ID 1 e permette gli altri ID.

ACL dei talkgroup

Per consentire inizialmente tutti i talkgroup:

TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL

Successivamente è possibile limitare la rete:

TGID_TS1_ACL: PERMIT:222,22201-22299
TGID_TS2_ACL: PERMIT:9,22201-22299

Le ACL globali e quelle del singolo sistema vengono applicate insieme: il traffico deve superare entrambe.

Aprire la porta nel firewall

Prima di attivare UFW è fondamentale permettere l’accesso SSH.

sudo ufw allow OpenSSH
sudo ufw allow 54000/udp
sudo ufw enable
sudo ufw status

Se si utilizza una VPS, la porta deve essere aperta anche nel firewall o security group del provider.

Primo avvio manuale

Per la rete semplice è sufficiente avviare il core HBlink:

sudo -u hblink \
/opt/hblink/hblink3/venv/bin/python \
/opt/hblink/hblink3/hblink.py \
-c /opt/hblink/hblink3/hblink.cfg \
-l DEBUG

Lasciare il programma in esecuzione e osservare i messaggi visualizzati.

Da un secondo terminale è possibile verificare la porta:

sudo ss -lunp | grep 54000

Se tutto è corretto, il server deve risultare in ascolto sulla porta UDP 54000.

Per interrompere il test utilizzare:

CTRL+C

Avvio automatico con systemd

Creare il servizio:

sudo nano /etc/systemd/system/hblink3.service

Inserire:

[Unit]
Description=HBlink3 DMR Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hblink
Group=hblink

WorkingDirectory=/opt/hblink/hblink3

ExecStart=/opt/hblink/hblink3/venv/bin/python \
/opt/hblink/hblink3/hblink.py \
-c /opt/hblink/hblink3/hblink.cfg

Restart=always
RestartSec=10

NoNewPrivileges=true
PrivateTmp=true

StandardOutput=journal
StandardError=journal
SyslogIdentifier=hblink3

[Install]
WantedBy=multi-user.target

Salvare e attivare:

sudo systemctl daemon-reload
sudo systemctl enable --now hblink3

Controllare lo stato:

sudo systemctl status hblink3 --no-pager

Seguire il log in tempo reale:

sudo journalctl -u hblink3 -f

HBlink3 include anche un file systemd di esempio, che deve essere adattato al nome dell’utente e al percorso di installazione.

Configurare un ripetitore MMDVM

Nelle installazioni moderne MMDVMHost comunica normalmente con DMRGateway, che a sua volta si collega a HBlink.

La sezione di MMDVMHost è generalmente simile alla seguente:

[DMR Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=62032
GatewayAddress=127.0.0.1
GatewayPort=62031
Jitter=360
Slot1=1
Slot2=1
Debug=0

Questa configurazione dice a MMDVMHost di inviare il traffico DMR al DMRGateway locale. La versione corrente del file di esempio MMDVMHost utilizza proprio una connessione locale verso il gateway.

Configurare DMRGateway per HBlink

Aprire il file DMRGateway.ini. Su Pi-Star è normalmente possibile farlo dalla pagina:

Configuration → Expert → DMR GW

In una rete dedicata esclusivamente a HBlink si può utilizzare una sezione simile:

[DMR Network 3]
Enabled=1
Name=HBLink-Privata

Address=dmr.miodominio.it
Port=54000
Local=62033

Id=222000101
Password=CAMBIA-QUESTA-PASSWORD

TGRewrite0=1,1,1,1,999999
TGRewrite1=2,1,2,1,999999

PassAllPC0=1
PassAllPC1=2

Location=0
Debug=0

Sostituire:

• dmr.miodominio.it con il DNS o l’IP del server;
• 222000101 con l’ID del ripetitore;
• la password con quella presente in hblink.cfg.

Perché servono le regole TGRewrite?

DMRGateway non inoltra automaticamente tutto il traffico di una rete definita. È necessaria almeno una regola di riscrittura, anche quando il talkgroup e il timeslot non vengono realmente modificati. ew3

La sintassi è:

TGRewrite=timeslot_RF,talkgroup_RF,timeslot_NET,talkgroup_NET,quantità

La regola:

TGRewrite0=1,1,1,1,999999

inoltra sul timeslot 1 tutti i talkgroup compresi tra 1 e 999999, senza modificarli.

HBlink insieme a BrandMeister o ad altre reti

Se DMRGateway è già collegato a BrandMeister, DMR+ o TGIF, è sconsigliabile utilizzare una regola che catturi indistintamente tutti i talkgroup.

È preferibile inoltrare esclusivamente i talkgroup assegnati alla rete privata:

[DMR Network 3]
Enabled=1
Name=HBLink-Privata

Address=dmr.miodominio.it
Port=54000
Local=62033

Id=222000101
Password=CAMBIA-QUESTA-PASSWORD

TGRewrite0=1,222,1,222,1
TGRewrite1=2,22201,2,22201,99

Location=0
Debug=0

In questo esempio vengono inoltrati:

• TG 222 sul timeslot 1;
• i TG da 22201 a 22299 sul timeslot 2.

È necessario pianificare attentamente le regole affinché i medesimi talkgroup non vengano instradati contemporaneamente verso reti diverse.

Verificare il collegamento del ripetitore

Dopo aver riavviato MMDVMHost e DMRGateway, controllare il server:

sudo journalctl -u hblink3 -f

Nel log dovrebbe comparire la connessione del ripetitore con il relativo ID.

Se la connessione non avviene, verificare:

1. indirizzo IP o DNS del server;
2. porta UDP;
3. password;
4. ID inserito nella REG_ACL;
5. firewall del server;
6. port forwarding del router;
7. configurazione DMRGateway;
8. presenza delle regole TGRewrite.

Creare una rete composta da più aree

Supponiamo di voler realizzare due gruppi logici:

• AREA-NORD sulla porta UDP 54000;
• AREA-SUD sulla porta UDP 54001.

Ogni area potrà contenere uno o più ripetitori. HBlink instraderà poi determinati talkgroup tra le due aree.

Configurazione hblink.cfg

Alle sezioni globali già viste aggiungere:

[AREA-NORD]
MODE: SERVER
ENABLED: True

REPEAT: True
MAX_REPEATERS: 20

IP: 0.0.0.0
PORT: 54000
PASSPHRASE: PASSWORD-NORD

GROUP_HANGTIME: 5

USE_ACL: True
REG_ACL: PERMIT:222000101,222000102
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL


[AREA-SUD]
MODE: SERVER
ENABLED: True

REPEAT: True
MAX_REPEATERS: 20

IP: 0.0.0.0
PORT: 54001
PASSPHRASE: PASSWORD-SUD

GROUP_HANGTIME: 5

USE_ACL: True
REG_ACL: PERMIT:222000201,222000202
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL

Aprire anche la seconda porta:

sudo ufw allow 54001/udp

Configurare rules.py

Il file rules.py definisce il routing tra i differenti sistemi.

Aprirlo:

sudo nano /opt/hblink/hblink3/rules.py

Inserire:

BRIDGES = {

    'NAZIONALE': [

        {
            'SYSTEM': 'AREA-NORD',
            'TS': 1,
            'TGID': 222,
            'ACTIVE': True,
            'TIMEOUT': 2,
            'TO_TYPE': 'NONE',
            'ON': [],
            'OFF': [],
            'RESET': []
        },

        {
            'SYSTEM': 'AREA-SUD',
            'TS': 1,
            'TGID': 222,
            'ACTIVE': True,
            'TIMEOUT': 2,
            'TO_TYPE': 'NONE',
            'ON': [],
            'OFF': [],
            'RESET': []
        }

    ],


    'INTERAREA': [

        {
            'SYSTEM': 'AREA-NORD',
            'TS': 2,
            'TGID': 22201,
            'ACTIVE': True,
            'TIMEOUT': 2,
            'TO_TYPE': 'NONE',
            'ON': [],
            'OFF': [],
            'RESET': []
        },

        {
            'SYSTEM': 'AREA-SUD',
            'TS': 2,
            'TGID': 22202,
            'ACTIVE': True,
            'TIMEOUT': 2,
            'TO_TYPE': 'NONE',
            'ON': [],
            'OFF': [],
            'RESET': []
        }

    ]

}


OBP_BRIDGES = {}


UNIT = []


if __name__ == '__main__':
    from pprint import pprint

    pprint(BRIDGES)
    pprint(OBP_BRIDGES)
    print(UNIT)

Cosa fa questa configurazione?

Il bridge NAZIONALE collega:

• AREA-NORD, TS1, TG222;
• AREA-SUD, TS1, TG222.

Una trasmissione sul TG222 proveniente da una delle due aree viene inoltrata all’altra senza modifiche.

Il bridge INTERAREA esegue invece una traduzione:

• nell’AREA-NORD viene utilizzato TG22201;
• nell’AREA-SUD viene utilizzato TG22202.

Un flusso ricevuto sul TG22201 viene quindi inoltrato nell’altra area come TG22202 e viceversa.

Ogni voce di rules.py identifica un sistema, un timeslot e un talkgroup. Tutti i membri attivi dello stesso bridge scambiano traffico tra loro. Il nome indicato in SYSTEM deve corrispondere esattamente al nome della sezione presente in hblink.cfg. In caso contrario bridge.py non si avvia.

Controllare la sintassi di rules.py

sudo -u hblink \
/opt/hblink/hblink3/venv/bin/python \
-m py_compile \
/opt/hblink/hblink3/rules.py

Se il comando non restituisce errori, la sintassi Python è corretta.

È anche possibile eseguire direttamente il file:

sudo -u hblink \
/opt/hblink/hblink3/venv/bin/python \
/opt/hblink/hblink3/rules.py

Avviare bridge.py

Per utilizzare il routing definito in rules.py, modificare il servizio:

sudo systemctl stop hblink3
sudo nano /etc/systemd/system/hblink3.service

Sostituire la riga ExecStart con:

ExecStart=/opt/hblink/hblink3/venv/bin/python \
/opt/hblink/hblink3/bridge.py \
-c /opt/hblink/hblink3/hblink.cfg \
-r /opt/hblink/hblink3/rules.py

Ricaricare e riavviare:

sudo systemctl daemon-reload
sudo systemctl restart hblink3
sudo systemctl status hblink3 --no-pager

Talkgroup statici e dinamici

Un talkgroup statico ha normalmente:

'ACTIVE': True
'TO_TYPE': 'NONE'

Rimane quindi sempre collegato.

HBlink può anche attivare o disattivare un membro del bridge mediante appositi talkgroup di comando.

I principali parametri sono:

• ACTIVE: stato iniziale;
• ON: TG che attivano il collegamento;
• OFF: TG che lo disattivano;
• RESET: TG che azzerano il timer;
• TIMEOUT: durata in minuti;
• TO_TYPE: comportamento alla scadenza.

Esempio:

{
    'SYSTEM': 'AREA-NORD',
    'TS': 2,
    'TGID': 22291,
    'ACTIVE': False,
    'TIMEOUT': 10,
    'TO_TYPE': 'ON',
    'ON': [22290],
    'OFF': [4000],
    'RESET': [22291]
}

In questo esempio:

• TG22290 attiva il collegamento;
• TG4000 lo disattiva;
• il traffico vocale utilizza TG22291;
• ogni trasmissione su TG22291 rinnova il timer;
• dopo 10 minuti il collegamento viene disattivato.

Gestire le chiamate private

La variabile:

UNIT = []

controlla quali sistemi possono scambiarsi chiamate individuali o private.

Per permettere le chiamate tra le due aree:

UNIT = ['AREA-NORD', 'AREA-SUD']

HBlink mantiene una mappa degli utenti osservati sui differenti sistemi e cerca di inoltrare la chiamata privata verso il sistema nel quale è stato rilevato il destinatario.

Collegare HBlink a un altro server con OUTBOUND

Una sezione OUTBOUND permette al proprio HBlink di collegarsi come client a un altro server Homebrew.

[SERVER-REMOTO]
MODE: OUTBOUND
ENABLED: True

LOOSE: False

IP: 0.0.0.0
PORT: 54100

SERVER_IP: 203.0.113.10
SERVER_PORT: 54000

PASSPHRASE: PASSWORD-REMOTA

CALLSIGN: IZ1XXX
RADIO_ID: 2221234

RX_FREQ: 430000000
TX_FREQ: 430000000
TX_POWER: 1
COLORCODE: 1
SLOTS: 1

LATITUDE: 44.0000
LONGITUDE: 8.0000
HEIGHT: 100

LOCATION: Italia
DESCRIPTION: Collegamento HBlink
URL: www.esempio.it

SOFTWARE_ID: HBlink3
PACKAGE_ID: MMDVM_HBlink

GROUP_HANGTIME: 5
OPTIONS:

USE_ACL: True
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL

La sezione dovrà poi essere inserita nei bridge di rules.py.

La documentazione corrente di HBlink3 indica espressamente che BrandMeister richiede OpenBridge e non accetta la modalità OUTBOUND per questo impiego.

Configurazione OpenBridge

Esempio di sezione OpenBridge:

[BACKBONE-OBP]
MODE: OPENBRIDGE
ENABLED: True

IP: 0.0.0.0
PORT: 62035

NETWORK_ID: 2229999
PASSPHRASE: CHIAVE-CONDIVISA-OPENBRIDGE

TARGET_IP: 203.0.113.20
TARGET_PORT: 62035

BOTH_SLOTS: False
PRESERVE_SOURCE_PEER: False

USE_ACL: True
SUB_ACL: DENY:1
TGID_ACL: PERMIT:222,22201-22299

Nella versione corrente gli OpenBridge non devono essere inseriti direttamente nell’elenco BRIDGES. Devono essere definiti nella tabella separata OBP_BRIDGES.

Esempio:

OBP_BRIDGES = {

    'BACKBONE-OBP': {
        'NAZIONALE': 222,
        'INTERAREA': 22291
    }

}

La riga:

'NAZIONALE': 222

stabilisce che, sul sistema OpenBridge BACKBONE-OBP, il TG222 appartiene al bridge denominato NAZIONALE.

I talkgroup non presenti nella tabella non vengono instradati attraverso quel collegamento.

Installare il dashboard integrato

La versione attuale di HBlink3 include un dashboard moderno che può mostrare:

• ultimi ascolti;
• ripetitori collegati;
• chiamate attive;
• talkgroup;
• timeslot;
• bridge di conferenza;
• sistemi OUTBOUND;
• collegamenti OpenBridge;
• perdita dei ping;
• log delle chiamate.

Installare le dipendenze:

sudo -u hblink \
/opt/hblink/hblink3/venv/bin/pip install \
-r /opt/hblink/hblink3/dashboard/requirements.txt

Creare la configurazione:

sudo -u hblink cp \
/opt/hblink/hblink3/dashboard/config_sample.py \
/opt/hblink/hblink3/dashboard/config.py

Nel file hblink.cfg abilitare i report:

[REPORTS]
REPORT: True
REPORT_INTERVAL: 10
REPORT_PORT: 4321
REPORT_CLIENTS: 127.0.0.1

Avviare temporaneamente il dashboard:

cd /opt/hblink/hblink3

sudo -u hblink \
./venv/bin/python \
./dashboard/server.py

Aprire nel browser:

http://IP-DEL-SERVER:8080

Il dashboard ufficiale si collega al flusso di reporting di HBlink e utilizza normalmente la porta web 8080 e la porta report 4321.

Le configurazioni non vengono ricaricate automaticamente

HBlink legge hblink.cfg e rules.py durante l’avvio. Dopo ogni modifica è quindi necessario riavviare il servizio:

sudo systemctl restart hblink3

Non è previsto il ricaricamento automatico dei file durante l’esecuzione.

Aggiornare HBlink3

sudo systemctl stop hblink3

cd /opt/hblink/hblink3

sudo -u hblink git pull

sudo -u hblink \
./venv/bin/pip install \
-r requirements.txt

sudo systemctl start hblink3

Controllare poi:

sudo systemctl status hblink3 --no-pager
sudo journalctl -u hblink3 -n 100 --no-pager

I file hblink.cfg e rules.py non vengono normalmente sovrascritti da git pull, ma è sempre opportuno conservarne una copia di sicurezza.

Backup della configurazione

sudo mkdir -p /root/backup-hblink

sudo cp /opt/hblink/hblink3/hblink.cfg \
/root/backup-hblink/

sudo cp /opt/hblink/hblink3/rules.py \
/root/backup-hblink/

Per creare un archivio:

sudo tar -czf \
/root/hblink-backup-$(date +%F).tar.gz \
/opt/hblink/hblink3/hblink.cfg \
/opt/hblink/hblink3/rules.py \
/opt/hblink/hblink3/dashboard/config.py

Problemi comuni

Il ripetitore non si collega

Controllare:

sudo journalctl -u hblink3 -f
sudo ss -lunp | grep 54000
sudo ufw status

Le cause più frequenti sono:

• porta configurata come TCP anziché UDP;
• password differente;
• ID non presente nella REG_ACL;
• DNS errato;
• port forwarding mancante;
• firewall del provider non configurato;
• DMRGateway non riavviato.

Il ripetitore è collegato ma non passa audio

Verificare:

• regole TGRewrite di DMRGateway;
• talkgroup utilizzato;
• timeslot;
• ACL dei talkgroup;
• presenza del sistema nel bridge corretto;
• corrispondenza esatta del nome del sistema;
• valore di ACTIVE;
• eventuali timer o comandi OFF.

bridge.py non si avvia

Eseguire manualmente:

sudo -u hblink \
/opt/hblink/hblink3/venv/bin/python \
/opt/hblink/hblink3/bridge.py \
-c /opt/hblink/hblink3/hblink.cfg \
-r /opt/hblink/hblink3/rules.py \
-l DEBUG

Verificare soprattutto che:

• ogni parentesi e virgola di rules.py sia corretta;
• ogni nome indicato in SYSTEM esista in hblink.cfg;
• il sistema sia impostato su ENABLED: True;
• non siano ancora presenti i vecchi modi MASTER o PEER;
• gli OpenBridge siano collocati in OBP_BRIDGES.

Address already in use

L’errore indica che la porta è già utilizzata.

sudo ss -lunp | grep 54000
sudo lsof -i UDP:54000

Cambiare porta oppure terminare il processo che la occupa.

Il servizio continua a riavviarsi

sudo systemctl status hblink3 --no-pager
sudo journalctl -u hblink3 -n 200 --no-pager

Le cause più comuni sono:

• errore di sintassi;
• percorso errato nel servizio systemd;
• permessi insufficienti;
• dipendenze Python mancanti;
• porta già occupata.

Buone pratiche per una rete affidabile

• Utilizzare una VPS con IP statico.
• Creare un record DNS dedicato, per esempio dmr.example.org.
• Usare password diverse per differenti aree.
• Limitare la registrazione mediante REG_ACL.
• Non permettere tutti i talkgroup se non necessario.
• Documentare il piano dei talkgroup.
• Separare talkgroup statici e dinamici.
• Non sovrapporre le regole di più reti in DMRGateway.
• Controllare regolarmente i log.
• Installare gli aggiornamenti di sicurezza del sistema operativo.
• Proteggere il dashboard.
• Conservare un backup prima di ogni aggiornamento.
• Utilizzare NTP affinché l’orologio del server sia corretto.

Esempio di piano talkgroup

Conclusioni

HBlink3 permette di realizzare una rete DMR estremamente flessibile senza dipendere obbligatoriamente dai grandi network pubblici.

La configurazione minima richiede solamente:

1. un server Linux;
2. una sezione SERVER in hblink.cfg;
3. una porta UDP aperta;
4. una password condivisa;
5. gli ID autorizzati nella REG_ACL;
6. una configurazione DMRGateway corretta sui ripetitori.

Quando la rete cresce, bridge.py e rules.py consentono di suddividerla in aree, creare talkgroup statici o dinamici, tradurre numerazioni e collegare sistemi esterni.

Il consiglio è iniziare con due soli nodi collegati allo stesso sistema, verificare accuratamente audio e instradamento e soltanto dopo introdurre bridge, timer, OpenBridge e collegamenti con altre reti.