Portare il packet radio amatoriale su Linux significa far entrare lo stack AX.25 e NET/ROM dentro un kernel di cui si può leggere e modificare il codice, invece di affidarsi al firmware chiuso di un TNC o a un eseguibile DOS che gira da solo. Alla sezione ARI di Pisa dell’Associazione Radioamatori Italiani ho spostato tutto il sistema di packet radio della stazione (nominativo IZ5AWZ) su Linux, scrivendo per farlo varie patch a kernel, librerie e tool. Il risultato è un nodo in cui ogni livello — collegamento radio, instradamento amatoriale, trasporto IP — è codice ispezionabile e correggibile sulla stessa macchina.

Cos’è il packet radio amatoriale

Il packet radio è trasmissione dati a pacchetto sulle bande dei radioamatori. Il protocollo di livello collegamento è l’AX.25, derivato dall’HDLC e specificato nella versione 2.0 nell’ottobre 1984 da TAPR e ARRL: definisce framing, indirizzamento per nominativo con SSID, frame numerati per il modo connesso e frame UI per quello connectionless, più i digipeater per estendere la portata via ripetizione. Sopra ad AX.25 si appoggia NET/ROM, un livello di rete che fa instradamento tra nodi, così che una stazione raggiunga una destinazione lontana attraverso una catena di nodi intermedi senza conoscere a mano l’intero percorso radio.

Per anni la stazione tipo è stata un TNC (Terminal Node Controller) con il proprio firmware AX.25 a bordo, pilotato da un terminale. La semplificazione introdotta da KISS nel 1986 — specifica di Mike Chepponis K3MC e Phil Karn KA9Q — sposta l’intelligenza dal TNC al computer: in modo KISS il TNC si comporta da modem e consegna all’host i frame HDLC grezzi, lasciando che sia il computer a gestire AX.25 e tutto ciò che ci sta sopra. È la premessa che rende sensato implementare lo stack nel sistema operativo invece che nel firmware.

Perché Linux

Con KISS la domanda diventa dove far vivere lo stack AX.25. Mettendolo nel kernel di un sistema operativo libero, diventa codice che si legge, si compila e si corregge. È il lavoro che Alan Cox aveva avviato nel kernel Linux e che Jonathan Naylor G4KLX ha portato avanti, aggiungendo NET/ROM e ROSE e diventando il manutentore della parte AX.25 del kernel. Lo stack espone le proprie famiglie di indirizzi — AF_AX25, AF_NETROM, AF_ROSE accanto ad AF_INET — così che un programma possa aprire un socket su radio con la stessa interfaccia di un socket TCP/IP. Il kernel 2.0, uscito il 9 giugno 1996, è la base su cui ho lavorato.

La differenza pratica rispetto al firmware di un TNC è la possibilità di intervenire. Quando una stazione remota usa un dialetto di una temporizzazione o un comportamento al limite della specifica fa cadere una connessione, sul firmware chiuso non resta che aggirare il problema dall’esterno; con lo stack nel kernel si legge il punto in cui il frame viene scartato e si corregge lì. Le patch che ho scritto stanno in tre punti: nel kernel, sullo stack AX.25/NET/ROM e sull’incollaggio con l’interfaccia di rete; nelle librerie di spazio utente (libax25), che traducono nominativi e parametri di porta per i programmi applicativi; e nei tool (ax25-utils), gli strumenti che agganciano una linea KISS a un’interfaccia di rete e configurano le porte. Il file /etc/ax25/axports descrive ciascuna porta radio; kissattach crea il dispositivo di rete ax0 sopra la linea seriale verso il TNC.

Il bridge IP su radio e la rete 44/8

Il punto in cui il packet radio incontra le reti di dati è il trasporto dell’IP sull’AX.25. Ai radioamatori è assegnato dal 1981 un intero blocco di indirizzi IP, la classe A 44.0.0.0/8 — la rete nota come AMPRNet — amministrata dalla comunità per il traffico sperimentale a pacchetto. Con lo stack di Linux la stazione diventa un host IP a tutti gli effetti: ha un indirizzo nella 44/8, fa girare i normali demoni TCP/IP e instrada i pacchetti incapsulandoli in frame AX.25 — un’interfaccia di rete il cui livello collegamento è la radio invece dell’Ethernet. Il modello dell’IP amatoriale su AX.25 viene dal lavoro di Phil Karn KA9Q sul software NOS; portarlo nel kernel di Linux significa farlo coincidere con lo stack di rete del sistema, non con un programma a sé.

Da qui la stazione fa due cose. Verso le altre stazioni radio resta un nodo del packet locale, parla AX.25 e NET/ROM con i nodi di zona e con i packet cluster — i nodi DX cluster nati dal PacketCluster di Dick Newell AK1A a fine anni ‘80, che distribuiscono in tempo reale le segnalazioni di stazioni in collegamento. Verso il resto della rete IP, l’indirizzo nella 44/8 e lo stack del kernel la rendono raggiungibile e instradabile come qualsiasi altro host.

Il tunnel IP-IP verso Tampa

Una rete radio è un’isola: due segmenti della 44/8 distanti fra loro non hanno un percorso radio diretto. Il modo standard di unirli è incapsulare l’IP amatoriale in IP ordinario e farlo viaggiare sull’Internet pubblica fino all’altro estremo, dove viene scartato e rimesso in onda. La tecnica è descritta in RFC 1853, IP in IP Tunneling, dell’ottobre 1995: un header IP esterno antepone i propri indirizzi sorgente e destinazione — gli estremi del tunnel — al datagramma originale, che mantiene i propri. Tra la stazione di Pisa e un nodo a Tampa, in Florida, ho stabilito un tunnel di questo tipo: il traffico 44/8 tra le due isole radio viaggia incapsulato sull’Internet ordinaria, e a ciascun capo torna pacchetto AX.25 sulla radio locale. Per i nodi radio dei due lati il collegamento è trasparente: vedono un’unica rete amatoriale, senza sapere che un tratto del percorso passa per l’IP pubblico.

Lo stesso indirizzamento IP che rende possibile il tunnel apre i collegamenti con le reti di ricerca della città. Pisa è il punto in cui Internet è arrivata in Italia: il 30 aprile 1986 il sistema del CNUCE-CNR si collegò ad ARPANET attraverso il Centro Spaziale del Fucino e la stazione di Roaring Creek in Pennsylvania, primo nodo italiano. Da quella radice è cresciuta la rete della ricerca italiana, il GARR, che alla fine del 1991 collegava un centinaio di sedi di CNR, ENEA, INFN e università. Con la stazione ARI diventata host IP, gli agganci verso il CNUCE e l’INFN sono interconnessioni tra reti che parlano lo stesso protocollo: un’isola radio amatoriale che si affaccia, tramite IP, sulle reti accademiche e di ricerca della stessa città.

Il punto critico

La difficoltà non sta in un singolo protocollo ma nel tenerne in piedi tre uno sopra l’altro su un mezzo poco affidabile. La radio non è un cavo: c’è perdita di pacchetti, c’è il canale condiviso a contesa, ci sono temporizzazioni che dipendono dalla propagazione. AX.25 gestisce ritrasmissione e finestra, NET/ROM ci instrada sopra, l’IP ci viaggia ancora sopra; un parametro sbagliato a un livello degrada quello superiore in modi che dal di fuori sembrano guasti casuali. Avere lo stack nel kernel cambia il modo di diagnosticare: si osserva direttamente dove un frame viene scartato o una connessione cade, e si corregge il codice invece di tarare alla cieca i registri di un TNC. È la ragione tecnica per cui il lavoro è consistito in patch, non solo in configurazione: alcuni comportamenti si potevano sistemare solo nel sorgente.

Implicazioni

Lo stack libero unifica due mondi che con il firmware chiuso restavano separati. Per il radioamatore, il nodo è un host IP completo: gli strumenti di rete ordinari — instradamento, diagnostica, servizi — valgono tanto sull’Ethernet quanto sulla radio, perché sotto c’è lo stesso stack del sistema operativo. Per la rete dati, l’isola radio diventa un segmento raggiungibile e instradabile, collegabile ad altre isole con un tunnel e alle reti di ricerca con il normale instradamento IP. E le correzioni non restano locali: lo stack AX.25/NET/ROM/ROSE del kernel è codice condiviso, e una patch che risolve un problema visto a Pisa serve a chiunque usi quel codice altrove.

Limiti

Il mezzo resta quello che è. Le bande amatoriali in packet lavorano a velocità basse — dell’ordine di 1200 e 9600 bit al secondo — e nessun lavoro software cambia la banda disponibile o la latenza della propagazione. Il tunnel IP-IP fa dipendere il collegamento tra le isole dalla disponibilità dell’Internet pubblica tra i due estremi: quando il percorso ordinario cade, cade anche il ponte, e resta solo ciò che è raggiungibile via radio. RFC 1853 segnala inoltre un limite proprio dell’incapsulamento: un errore generato da un router all’interno del tunnel torna come messaggio ICMP all’incapsulatore, che spesso non ha abbastanza dati per inoltrarlo all’host originario, e la diagnostica dei guasti sul tratto interno ne risulta più cieca. Sono vincoli del progetto, non difetti da correggere: il valore dello stack libero sta nel renderli leggibili e governabili dallo stesso punto in cui si gestisce il resto del nodo.

Immagine di copertina: la sede della sezione ARI di Pisa (Associazione Radioamatori Italiani) durante un’attività radio — foto d’archivio personale.