Il protocollo AX.25 offre la possibilità di lavorare o meno in modo connesso, ed è usato sia da solo in collegamenti punto-punto, che come trasporto per altri protocolli come il TCP/IP e NET/ROM
La sua struttura è simile all'AX.25 livello 2, con alcune estensioni che lo rendono più adatto all'ambito radioamatoriale.
Il protocollo NET/ROM rappresenta un tentativo di realizzare un protocollo di rete completo e usa AX.25 al livello più basso come protocollo dati. Presenta uno strato di rete che è una forma adattata di AX.25 e offre il routing dinamico e l'alias dei nodi.
Il protocollo Rose fu concepito ed implementato da Tom Moulton W2VY come un'implementazione del livello di pacchetto X.25 ed è stato progettato per operare col protocollo AX.25 come protocollo a livello dati. Esso fornisce anche un layer di rete. L'indirizzamento in Rose è costituito da un numero a 10 cifre. Le prime quattro rappresentano il Codice Identificativo dei Dati di rete (Data Network Identification Code) (DNIC) come indicato dalla Raccomandazione CCIT X.121 Appendice B. Maggiori informazioni sul protocollo Rose si possono trovare sul Web server RATS.
Alan Cox è stato lo sviluppatore del primo supporto AX.25 nel kernel di Linux, successivamente preso in carico da Jonathon Naylor che ha aggiunto anche il supporto per NET/ROM e Rose. Il supporto per il protocollo DAMA è stato sviluppato da Joerg, DL1BKE, mentre il supporto per il Baycom e il SoundModem è stato aggiunto da Thomas Sailer. Il software specifico per AX.25 è ora sviluppato e mantenuto da un piccolo gruppo di sviluppatori su SourceForge.
Il codice sviluppato per Linux supporta i TNC (Terminal Node Controllers) in modo KISS o basati su 6PACK, l'Ottawa PI card, la Gracilis PacketTwin card e le altre schede SCC basate su Z8530 attraverso il driver generico SCC, diversi modem Baycom seriali e paralleli e i modem YAM con interfaccia seriale. Il driver soundmodem di Thomas Sailer permette l'utilizzo delle SoundBlaster e delle schede sonore basate sul chipset Crystal; inoltre il suo più recente soundmodem, che funziona in user-mode, utilizza i driver standard del kernel, per cui dovrebbe funzionare con ogni scheda audio supportata da Linux.
I programmi utente sono costituiti da un semplice PMS (Personal Message System), un beacon, un programma a linea di comando per effettuare connessioni, listen (un esempio su come catturare tutti i frame AX.25 a livello di interfaccia) e programmi per configurare il protocollo NET/ROM. È incluso anche un programma tipo server AX.25 per gestire ed instradare connessioni AX.25 e un demone NET/ROM che svolge la maggior parte del lavoro di supporto per questo protocollo.
Ci sono anche programmi di utilità che supportano l'APRS, fornendo funzionalità quali il digipeating e il gateway verso Internet.
Quella in Linux è un'implementazione dell AX.25 del tutto nuova. Sebbene assomigli in molti modi a quella di NOS, BPQ o altre implementazioni AX.25, non è uguale a nessuna di queste. L'AX.25 di Linux è in grado di essere configurato in modo tale da poter comportarsi praticamente come le altre implementazioni, ma il processo di configurazione è del tutto diverso.
Per aiutarvi a capire a cosa occorra pensare mentre si effettua la configurazione, questa sezione descrive alcune delle caratteristiche strutturali dell'implementazione AX.25 e come questa si inserisce nel contesto dell'intera struttura di Linux.
Diagramma semplificato dei livelli dei protocolli di rete
_____________________________________________ | | | | | | AF_AX25 |AF_NET/ROM | AF_INET | AF_ROSE | |=========|===========|=============|=========| | | | | | | | | TCP/IP | | | | |________ | | | | NET/ROM | | ROSE | | |____________________|____|_________| | AX.25 | |_____________________________________________| |
Questo schema illustra con chiarezza come NET/ROM, Rose e TCP/IP lavorino sopra l'AX.25, ma anche che, ognuno di questi, sia considerato come un diverso protocollo a livello applicazione. I nomi che iniziano con '_' sono quelli dati alla 'Address Family' di ognuno dei seguenti protocolli nei programmi che ne fanno uso. La cosa importante che va messa in luce in questo caso, è l'implicita dipendenza dalla configurazione dei dispositivi AX.25, che si riflette in quella dei dispositivi NET/ROM, ROSE o TCP/IP.
Diagramma dei moduli software dell'implementazione di rete in Linux
___________________________________________________________________________ | | | || | | | User | Programmi | call node || Daemons | ax25d mheardd | | | | pms mheard || | inetd NET/ROMd | |_________|___________|_______________________||__________|_________________| | | Sockets |open(), close(), listen(), read(), write(), connect()| | | |_____________________________________________________| | | | AF_AX25 | AF_NET/ROM | AF_ROSE | AF_INET | | |___________|_____________|_____________|_____________|___________| |Kernel | Protocolli| AX.25 | NET/ROM | ROSE | IP/TCP/UDP| | |___________|_____________|_____________|_____________|___________| | | Devices | ax0,ax1 | nr0,nr1 | rose0,rose1 | eth0,ppp0 | | |___________|_____________|_____________|_____________|___________| | | Drivers | Kiss PI2 PacketTwin SCC BPQ | slip ppp | | | | Soundmodem Baycom | ethernet | |_________|___________|_________________________________________|___________| |Hardware | PI2 Card, PacketTwin Card, SCC card, Serial port, Ethernet Card | |_________|_________________________________________________________________| |
Questo diagramma è un po' più generale di quello precedente e vuole mostrare la relazione che intercorre tra le applicazioni utente, il kernel e l'hardware. In particolare si nota il rapporto esistente tra le interfacce di programmazione delle applicazioni (API) a livello di Socket, i moduli effettivamente relativi ai vari protocolli, i dispositivi di rete del kernel e i driver. Ogni cosa in questo diagramma dipende da ciò che è presente sotto di lui, quindi in generale le configurazioni devono essere fatte dal basso verso l'alto. Se, per esempio, si vuole far funzionare il programma call, occorre anche configurare l'hardware, poi assicurarsi che il kernel abbia l'opportuno driver, che sia stato creato l'opportuno dispositivo di rete, che il kernel includa il protocollo desiderato e che a sua volta, esponga un interfaccia di programmazione che possa essere utilizzata dal programma call. La stesura di questo documento ricalca a grandi linee quest'ordine.