Allo stato attuale il software radioamatoriale XLX che gestisce un reflector DSTAR multiprotocollo presenta alcune limitazioni e problematiche soprattutto se impiegato in sistemi con gestione DMR e C4FM, in particolare:
- La gestione della transcodifica su più moduli con HW di transcodifica in remoto (tipico caso di server XLX su VPS in Cloud e schede di transcodifica su raspberry in ufficio). Abbiamo notato numerosi malfunzionamenti con queste configurazioni in special modo su ponti MMDVM, nel caso di flussi su moduli attivi contemporaneamente.
- La politica con cui sono gestiti i peers che conduce alla necessità di avere tutti gli XLX in peer tra di loro e tutti connessi, ad esempio in un sistema multi-protocollo, a BrandMeister e quindi la necessità di dotare ogni modulo del proprio sistema di transcodifica. Il caso tipico è la gestione di un modulo regionale e/o cluster e il modulo “nazionale”.
- L’impossibilità di definire protocolli specifici per moduli definiti (es. DSTAR solo su A, C4FM su M, etc.).
Questo panorama “obbliga” quindi ad artifici direttamente nel codice sorgente di XLX, e soprattutto l’acquisto di ulteriore hardware da dedicare alla transcodifica, motore del multiprotocollo. Inoltre non tutte le configurazioni sono possibili se non presenti le stesse caratteristiche hardware e software sui sistemi che intendono fondersi tra loro (XLX in peer).
Dextra_bridge è un software scritto interamente in linguaggio Python 3, opensource, con utilizzo di librerie standard, che nasce per fornire un ausilio nella gestione delle problematiche sopra evidenziate. Dextra_bridge permette infatti di collegare due reflector XLX tramite il protocollo DExtra/DStar. Questa connessione viene vista dai partner come un comune ponte ripetitore/hotspot DStar e l’utilizzo tipico è quello di unire un reflector XLX multiprotocollo dotato di transcodifica ad un XLX “solo DStar”, anche tra moduli differenti (es. modulo B del reflector 1 con il modulo D del reflector 2). Inoltre è possibile continuare ad usare il software XLX originale, senza modifiche nel codice o fork (versioni portate avanti non dall’autore originale). E’ facile capire che sono quindi possibili nuove “riorganizzazioni” tra i sistemi attivi per favorire la diffusione dei flussi.
Un altro caso di connessione tra sistemi “non equiparabili” può essere adesso preso in esame, ovvero passaggio di flussi tra un XLX dotato di hardware di transcodifica per la gestione di due moduli (es. Nazionale e Regionale) con un XLX che ha invece la gestione hardware di un solo modulo (Cluster), e non vuole rinunciare alla gestione del flusso nazionale multiprotocollo. In questa situazione (al momento) sono richieste delle piccole modifiche nel codice di XLX che gestisce in hardware un solo modulo (vedi nostro articolo) e poi può essere impiegato il software Dextra_bridge per l’unione dei due server.
Premessa: l’installazione di Dextra_bridge prevede una buona conoscenza del sistema linux (sistema operativo, comandi shell e funzionalità network e servizi di sistema) e soprattutto la gestione delle librerie e del linguaggio di programmazione Python versione 3. Chiaramente occorre conoscere a fondo il funzionamento del reflector XLX e delle procedure di compilazione e installazione. L’uso errato di Dextra_bridge può comportare malfunzionamenti ai network sui quali viene collegato quindi va usato con intelligenza e in piena collaborazione con i sysop/manutentori dei sistemi partner. L’autore di Dextra_bridge, il collega radioamatore Antonio Matraia IU5JAE del Gruppo Radio Firenze non si assume responsabilità sull’uso non appropriato di tale software e viene fornito a titolo esclusivamente sperimentale radioamatoriale, senza supporto e garanzia alcuna.
Il software Dextra_bridge può essere eseguito da riga di comando o come servizio (systemctl) ed ha come unico argomento (obbligatorio) il nome del file di configurazione. E’ molto personalizzabile nella configurazione: possono essere specificati nominativi diversi per ogni lato della connessione oltre a porte e moduli diversi. Analizziamo in dettaglio questo file che è composto da tre sezioni, la prima riguarda i parametri generali mentre le altre due (identiche) riguardano gli end-point (XLX di origine e XLX di destinazione):
[general]
# percorso del file di log
log_file = /root/dextra_bridge/dextra_bridge.log
# lunghezza max (il programma gestisce la rotazione automatica del log)
log_maxBytes = 1000000
# numero di copie da conservare
log_backupCount = 5
# periodo, in secondi, con cui vengono inviati i pacchetti di keepalive ai due XLX
ack_period = 3.0
# timeout, in secondi, trascorsi i quali viene chiusa la connessione per timeout
ack_tout = 30.0
# file contenente la whitelist
whitelist_file = /root/dextra_bridge/dextra_bridge.whitelist
# file contenente la blacklist
blacklist_file = /root/dextra_bridge/dextra_bridge.blacklist
# parametri relativi alla connessione verso l’XLX “A”
[A]
# nome
XRF = XRFxxx
# indirizzo (si può indicare l’IP on il nome)
address = indirizzo XRFxxx
# porta di connessione DEXTRA
port = 30001
# call utilizzato per la connessione
call = CALLx
# modulo utilizzato per la connessione (A=23cm – B=70cm – C=2m)
module = A
# modulo a cui collegarsi
XRF_module = C
# filtraggio: 0 = disattivato – 1 = attivato
# si filtra in ricezione, quindi attivandolo si filtra in direzione A → B
filtering = 0
# stessi parametri per la connessione verso l’XLX “B”
[B]
XRF = XRFyyy
address = indirizzo XRFyyy
port = 30001
call = CALLy
module = A
XRF_module = A
# filtraggio: 0 = disattivato – 1 = attivato
# si filtra in ricezione, quindi attivandolo si filtra in direzione B → A
filtering = 0
Rimane adesso da vedere la sintassi dei file whitelist e blacklist che sono identiche tra loro:
### whitelist ####
# call
# esempio di filtro che fa passare tutto
call: ^.*:AB
# si bloccano tutti i via
# in modo da gestire solo
# i call
via: ^[.*]:AB
### blacklist ####
# nessun call in blacklist
call: ^[.*]: AB
# nessun via in blacklist
via: ^[.*]: AB
Ogni riga è composta da tre campi separati da “:” il primo campo può assumere due valori “call” o “via” ed indica a cosa applicare il filtro; il secondo è il filtro scritto come espressione regolare (regular expression, per la sintassi si può vedere https://docs.python.org/3/library/re.html) ed il terzo indica dove applicarlo (A, B, AB). Le condizioni per far transitare il flusso in caso di filtraggio sono che il call o il via sia ammesso dalla whitelist e che non sia bloccato dalla blacklist. Le liste di filtraggio, se lo stesso è abilitato nella configurazione, vengono aggiornate automaticamente ogni minuto senza dover riavviare il bridge.
Alcuni esempi di espressioni regolari:
^.* → tutto (^ = la stringa inizia con – . = qualsiasi carattere – * = ripetizione del carattere precedente 0 o più volte)
^[.*] → niente (^ = negazione – . = qualsiasi carattere – * = ripetizione del carattere precedente 0 o più volte)
^IU5 → nominativo che inizia (^) con IU5
ad esempio se compilo la whitelist con queste righe:
### whitelist ####
# call
call: ^IU5:AB
call: ^I5:AB
call: ^IK5:AB
call: ^IW5:AB
call: ^IZ5:AB
call: ^IA5:AB
# si bloccano tutti i via
# in modo da gestire solo
# i call
via: ^[.*]:AB
passano in entrambi i sensi solo i nominativi della zona 5, ovviamente supponendo che la blacklist non blocchi niente (quella vista sopra). Questo utilizzo delle liste di accesso permette una grossa personalizzazione nella definizione dei flussi e relativa strutturazione del sistema. Immaginiamo quindi che possiamo inviare al reflector B “solo” il flusso proveniente da uno specifico ripetitore o, semplicemente, da una identificabile connessione (es. PEANUT).
Il software Dextra_bridge è scaricabile da Github da questo link.
Buone prove e sperimentazioni.