Capitolo 24. Comunicazioni Seriali

Nel parlare della velocità di comunicazione, questa sezione non usa il termine "baud". Il baud si riferisce al numero di transizioni degli stati elettrici che possono essere effettuati in un periodo di tempo, mentre i "bps" (bit per secondo) sono il termine corretto da usare (o almeno non sembra irritare troppo i perfezionisti).

Per collegare un modem o un terminale alla tua macchina FreeBSD, avrai bisogno di una porta seriale sul tuo computer e del cavo appropriato per il tuo dispositivo seriale. Se sei già pratico con l’hardware ed i cavi necessari, puoi saltare tranquillamente questa sezione.

FreeBSD supporta quattro porte seriali di default. Nel mondo MS-DOS®, queste sono note come COM1, COM2, COM3, e COM4. FreeBSD attualmente supporta schede d’interfaccia seriale multiporta "stupide", come le BocaBoard 1008 e 2016, così come le schede multiporta intelligenti come quelle fatte dalla Digiboard e dalla Stallion Technologies. Ad ogni modo, il kernel di default usa solo le porte COM standard.

Per vedere se il tuo kernel riconosce una delle tue porte seriali, guarda i messaggi mentre il kernel viene avviato, o usa il comando /sbin/dmesg per far scorrere di nuovo i messaggi di avvio del kernel. In particolare, cerca dei messaggi che inizino con i caratteri sio.

Ad esempio, su un sistema con quattro porte seriali, questi sono i messaggi dati dall’avvio del kernel specifici delle porte seriali:

Se il tuo kernel non riconosce tutte le tue porte seriali, probabilmente devi configurare il kernel sistemando il file /boot/device.hints. Inoltre puoi commentare o rimuovere completamente le righe dei dispositivi che non hai.

Su FreeBSD 4.X devi editare il tuo file di configurazione del kernel. Per informazioni dettagliate sulla configurazione del kernel, guarda Configurazione del Kernel di FreeBSD. Le righe dei dispositivi interessati dovrebbero essere simili a queste:

Guarda la pagina man di sio(4) per informazioni aggiuntive sulla configurazione delle porte seriali e delle schede multiporta. Stai attento se stai usando un file di configurazione già usato per una versione differente di FreeBSD, poiché i flag dei dispositivi e la sintassi sono cambiati tra una versione e l’altra.

Alla maggior parte dei dispositivi nel kernel si accede attraverso "file speciali di dispositivo", che si trovano nella directory /dev. Ai dispositivi sio si accede attraverso i /dev/ttydN (ingresso) e /dev/cuadN (uscita). FreeBSD fornisce anche dei dispositivi di inizializzazione (/dev/ttydN.init e /dev/cuadN.init su FreeBSD 6.X, /dev/ttyidN e /dev/cuaidN su FreeBSD 5.X e precedenti) e dispositivi di blocco (/dev/ttydN.lock e /dev/cuadN.lock su FreeBSD 6.X, /dev/ttyldN e /dev/cualdN su FreeBSD 5.X e precedenti). I dispositivi di inizializzazione vengono usati per inizializzare i parametri delle porte di comunicazione ogni volta che una porta viene aperta, come crtscts per i modem che usano le segnalazioni RTS/CTS per il controllo di flusso. I dispositivi di blocco vengono usati per fissare i flag sulle porte ed evitare che altri utenti o programmi cambino certi parametri; guarda le pagine man di termios(4), sio(4), e stty(1) per maggiori informazioni sulle impostazioni dei terminali, sui dispositivi di blocco ed inizializzazione, e sull’impostazione delle opzioni del terminale, rispettivamente.

Il dispositivo ttydN (o cuadN) è il normale dispositivo che si apre per le proprie applicazioni. Quando un processo apre il dispositivo, avrà un insieme di impostazioni di I/O predefinite per il terminale. Puoi visualizzare queste impostazioni con il comando:

Quando cambi le impostazioni per questo dispositivo, queste rimangono efficaci finché il dispositivo non viene chiuso. Quando viene riaperto, ritorna all’insieme di default. Per effettuare dei cambiamenti all’insieme predefinito, modifica le impostazioni per il dispositivo di "stato iniziale". Ad esempio, per attivare di default modalità CLOCAL, comunicazione a 8 bit, e controllo di flusso XON/XOFF per ttyd5, scrivi:

Le inizializzazioni di sistema per i dispositivi seriali sono controllate in /etc/rc.d/serial. Questo file influisce sui valori predefiniti dei dispositivi seriali.

Per evitare cambiamenti da parte di qualche applicazione, modifica il dispositivo di "blocco dello stato". Ad esempio, per bloccare la velocità di ttyd5 a 57600 bps, scrivi:

Ora, un applicazione che apra ttyd5 e cerchi di cambiare la velocità della porta resterà bloccata a 57600 bps.

Naturalmente, dovresti rendere i dispositivi di stato iniziale e stato di blocco scrivibili solo da root.

I sistemi UNIX® originali non avevano console. Invece, la gente effettuava il login ed avviava programmi attraverso terminali connessi alle porte seriali del computer. Ciò era abbastanza simile all’uso di modem e programmi terminale per collegarsi telefonicamente ad un sistema remoto e lavorare da riga di comando.

I PC di oggi hanno console capaci di grafica di alta qualità, ma l’abilità di stabilire una sessione di login su una porta seriale esiste ancora in quasi ogni sistema operativo in stile UNIX® di oggi; FreeBSD non fa eccezione. Usando un terminale attaccato ad una porta seriale inutilizzata, puoi effettuare il login ed eseguire qualsiasi programma testuale che potresti lanciare normalmente dalla console o da una finestra xterm in X Window.

Un utente aziendale può connettere molti terminali ad un sistema FreeBSD e porli sulle scrivanie dei propri impiegati. Un utente casalingo può usare qualcosa come un vecchio PC IBM o un Macintosh® come terminale connesso a un computer più potente che faccia girare FreeBSD. Puoi anche trasformare quello che sarebbe un computer singolo utente in un potente sistema per utenti multipli.

Per FreeBSD, esistono tre tipi di terminali:

Le sottosezioni rimanenti descrivono ognuno di questi tipi.

Questa sezione descrive quello che hai bisogno di configurare sul tuo sistema FreeBSD per abilitare una sessione di login via terminale. Si assume che tu abbia già configurato il kernel con il supporto per la porta seriale alla quale è connesso il terminale - e che questo sia già connesso.

Dovresti ricordare dal La Procedura di Avvio che il processo init è responsabile del controllo di tutti i processi e dell’inizializzazione del sistema all’avvio. Uno dei compiti svolti da init è la lettura del file /etc/ttys e l’avvio di un processo getty sui terminali disponibili. Il processo getty è responsabile della lettura di un nome di login e dell’avvio del programma login.

Dunque, per configurare i terminali per il tuo sistema FreeBSD devono essere effettuati come root i seguenti passi:

Come passo opzionale, potresti desiderare di creare un tipo di getty personale da usare nel secondo passo aggiungendo una linea in /etc/gettytab. Questo capitolo non spiega come fare ciò; sei incoraggiato a leggere le pagine man di gettytab(5) e getty(8) per maggiori informazioni.

Anche con la più meticolosa attenzione ai dettagli, qualcosa potrebbe comunque andare storto nell’impostazione di un terminale. Questa è una lista dei sintomi e di alcuni suggerimenti per risolverli.

I modem esterni sembrerebbero migliori per chiamare, poiché i modem esterni spesso possono essere configurati in maniera semipermanente tramite dei parametri immagazzinati in RAM non volatile e generalmente forniscono degli indicatori luminosi che mostrano lo stato degli importanti segnali RS-232. Le lucine lampeggianti impressionano gli ospiti, ma sono anche molto utili per vedere se un modem sta funzionando in maniera appropriata.

I modem interni in genere mancano della RAM non-volatile, quindi la loro configurazione può essere limitata solo impostando i DIP switch. Se il tuo modem interno ha delle luci indicatrici di segnale, probabilmente è difficile vederle quando il case del sistema è al suo posto.

FreeBSD supporta interfacce di comunicazione EIA RS-232C (CCITT V.24) basate su NS8250, NS16450, NS16550, e NS16550A. I dispositivi 8250 e 16450 hanno buffer di un singolo carattere. Il dispositivo 16550 fornisce un buffer di 16 caratteri, che permette prestazioni del sistema migliori. (Dei bug nel normale 16550 impediscono l’uso del buffer di 16 caratteri, quindi usate 16550A se possibile). A causa del buffer a singolo carattere questi dispositivi richiedono un lavoro maggiore da parte del sistema operativo rispetto ai dispositivi a 16 caratteri di buffer, le schede d’interfaccia seriale basate su 16550A sono preferibili. Se il sistema ha molte porte seriali attive o dovrà sopportare un grosso carico, le schede basate su 16550A sono migliori per comunicazioni a basso tasso d’errore.

Come con i terminali, init lancia un processo getty per ogni porta seriale configurata per connessioni in ingresso. Ad esempio, se un modem è connesso a /dev/ttyd0, il comando ps ax mostrerà questo:

Quando un utente chiama la linea del modem e questo si collega, il modem riporterà la linea CD (Carrier Detect). Il kernel nota che la portante è stata rilevata e completa l’apertura della porta con getty. getty invia un prompt login: alla velocità iniziale di linea specificata. getty aspetta per verificare che vengano ricevuti caratteri legittimi, e, in una tipica configurazione, se trova dei caratteri strani (probabilmente perché la velocità del modem è differente da quella di getty), getty cerca di calibrare la velocità di linea fino a ricevere dei caratteri ragionevoli.

Dopo che l’utente ha inserito il suo nome di login, getty esegue /usr/bin/login, che completa il login richiedendo la password per l’utente ed avviandone la shell.

Ci sono tre file di configurazione di sistema nella directory /etc che avrai probabilmente bisogno di modificare per permettere chiamate in ingresso sul tuo sistema FreeBSD. Il primo, /etc/gettytab, contiene le informazioni di configurazione per il demone /usr/libexec/getty. Il secondo, /etc/ttys contiene le informazioni che dicono a /sbin/init quali dispositivi tty devono avere processi getty in esecuzione. Infine, si possono mettere comandi di inizializzazione nello script /etc/rc.d/serial.

Ci sono due scuole di pensiero riguardo i modem su UNIX®. Un gruppo preferisce configurare i propri modem in maniera che qualunque sia la velocità con la quale un utente remoto si collega, l’interfaccia locale RS-232 computer-modem funzioni ad una velocità fissa. Il beneficio di questa configurazione è che l’utente remoto vede sempre un prompt di login immediato. Il lato negativo è che il sistema non sa quale sia la vera velocità di trasmissione dati di un utente, quindi programmi a tutto schermo come Emacs non modificheranno i loro metodi di rappresentazione dello schermo per ottimizzare la risposta su connessioni lente.

L’altra scuola di pensiero configura le proprie interfacce RS-232 verso il modem per variare la propria velocità rispetto a quella di connessione dell’utente remoto. Ad esempio, le connessioni V.32bis (14.4 Kbps) faranno sì che il modem faccia funzionare la propria interfaccia RS-232 a 19.2 Kbps, mentre le connessioni a 2400 bps faranno sì che funzioni a 2400 bps. Poiché getty non comprende nessun valore restituito dal modem riguardo la velocità di connessione, getty darà un messaggio login: ad una velocità iniziale fissata e aspetterà i caratteri in risposta. Se l’utente vede caratteri strani, si assume che sappia che dovrà premere Invio finché non vedrà un prompt riconoscibile. Se le frequenze di trasmissione non concordano, getty vedrà tutto ciò che l’utente preme come "spazzatura", cercherà di passare alla velocità seguente e invierà il prompt login: di nuovo. Questa procedura potrebbe continuare ad nauseam, ma normalmente ci vogliono solo una o due pressioni sui tasti prima che l’utente veda un buon prompt. Ovviamente, questa sequenza di login non è pulita come la precedente a "velocità fissata", ma un utente su una connessione a bassa velocità dovrebbe ricevere una risposta interattiva migliore da programmi a tutto schermo.

Questa sezione cercherà di fornire informazioni di configurazione bilanciate, ma è indirizzata verso l’approccio di avere la frequenza di trasmissione del modem che segue la velocità della connessione.

Se hai uno di quei modem i cui parametri possono essere impostati in maniera permanente in RAM non volatile, avrai bisogno di usare un programma terminale (come Telix su MS-DOS® o tip sotto FreeBSD) per impostare i parametri. Collegati al modem usando le stesse velocità iniziali e di comunicazione che userebbe getty e configura la RAM non volatile secondo queste necessità:

Leggi la documentazione del tuo modem per capire quali comandi e/o impostazioni per i DIP switch sia necessario fornirgli.

Ad esempio, per impostare i parametri precedenti su un U.S. Robotics® Sportster® 14.400 esterno, si potrebbero dare questi comandi al modem:

Potresti anche sfruttare questa opportunità per raffinare le impostazioni del modem, ad esempio per decidere se dovrà usare V.42bis e/o la compressione MNP5.

Il modem esterno U.S. Robotics® Sportster® 14.400 ha anche dei DIP switch che devono essere impostati; per altri modem, forse potrai usare queste impostazioni come esempio:

I codici di risposta dovrebbero essere disabilitati/soppressi per i modem chiamanti per evitare i problemi che possono capitare se getty dà incidentalmente un prompt login: ad un modem che si trova in modalità di comando ed il modem restituisce l’eco del comando o un codice di risposta. Questa sequenza può portare ad una lunga, stupida conversazione tra getty ed il modem.

Questi sono un po' di passi che è possibile seguire per verificare il funzionamento del modem sul tuo sistema.

Effettivamente, la pagina man di tip è un po' datata. C’è un compositore Hayes generico già integrato. Usa semplicemente at=hayes nel tuo /etc/remote file.

Il driver Hayes non è abbastanza intelligente da riconoscere alcune delle caratteristiche avanzate dei nuovi modem-messaggi come BUSY, NO DIALTONE, o CONNECT 115200 lo confonderanno e basta. Dovrai disattivare questi messaggi quando usate tip (usando ATX0&W).

Inoltre, il timeout di composizione per tip è di 60 secondi. Il tuo modem dovrebbe usare qualcosa di meno, altrimenti tip penserà che ci sia un problema di comunicazione. Prova ATS7=45&W.

Inserisci quella che viene definita una voce "diretta" nel file /etc/remote. Ad esempio, se il tuo modem è collegato alla prima porta seriale, /dev/cuad0, allora inserisci la riga seguente:

Usa la frequenza di bps più alta supportata dal tuo modem per il valore di br. Poi, digita tip cuad0 e verrai connesso al tuo modem.

O usa cu come root con il seguente comando:

linea è la porta seriale (es. /dev/cuad0) e velocità è la velocità (es. 57600). Quando hai finito di inserire i comandi AT premi ~. per uscire.

Il simbolo @ come valore del numero telefonico dice a tip di andare a cercare un numero telefonico in /etc/phones. Ma il segno @ è anche un carattere speciale nei file come /etc/remote. Devi farne l’escape con un backslash:

Metti una cosiddetta voce "generica" in /etc/remote. Ad Esempio:

Poi puoi fare una cosa simile:

Se preferisci cu a tip, usa una voce generica per cu:

e digita:

Metti una voce per tip1200 o cu1200, ma vai avanti e inserisci una qualunque frequenza di bps appropriata per il valore di br. tip pensa che un buon valore predefinito sia 1200 bps, motivo per cui cerca una voce per tip1200. Non sei obbligato a usare 1200 bps, comunque.

Invece di aspettare fino ad essere connesso e poi digitare CONNECT <host> ogni volta, usa la funzionalità cm di tip. Ad esempio, queste voci in /etc/remote:

ti permetteranno di digitare tip pain o tip muffin per collegarti agli host pain o muffin, e tip deep13 per il server di terminali.

Questo è spesso un problema quando una università ha molte linee di modem e molte migliaia di studenti cercano di usarle.

Inserisci una voce per la tua università in /etc/remote e usa @ per il campo pn:

Poi, elenca i numeri di telefono dell’università in /etc/phones:

tip proverà ognuno di questi secondo l’ordine, poi smetterà. Se vuoi continuare a riprovare, esegui tip in un ciclo while.

Ctrl+P è il carattere predefinito per "forzare", usato per dire a tip che il prossimo carattere è un dato letterale. Puoi impostare il carattere per forzare a qualsiasi altro carattere con il comando di escape ~s, che significa "imposta una variabile".

Digita ~sforce=singolo-carattere seguito da un ritorno a capo. singolo-carattere è un qualsiasi carattere singolo. Se non date nessun singolo-carattere, allora il carattere per forzare sarà il carattere nullo, che è possibile ottenere premendo Ctrl+2 o Ctrl+Spazio. Un valore abbastanza buono per il singolo-carattere è Shift+Ctrl+6, che è usato solo da alcuni server di terminali.

Potete far sì che il carattere per forzare sia un qualsiasi carattere vogliate specificando la riga seguente nel file $HOME/.tiprc:

Devi aver premuto Ctrl+A, il "raise character", di tip progettato specificamente per le persone con il tasto caps-lock rotto. Usa ~s come mostrato prima per impostare la variabile raisechar a qualcosa di ragionevole. In pratica, puoi impostarla allo stesso valore del carattere per forzare, se pensi di non usare mai queste due caratteristiche.

Qui c’è un file .tiprc di esempio per gli utenti Emacs che hanno bisogno di premere Ctrl+2 e Ctrl+A molto spesso:

Il carattere ^^ è Shift+Ctrl+6.

Se stai parlando ad altri sistemi UNIX®, puoi mandare e ricevere file con ~p (put) e ~t (take). Questi comandi eseguono cat ed echo sul sistema remoto per accettare e inviare file. La sintassi è:

~p file-locale [ file-remoto ]

~t file-remoto [ file-locale ]

non c’è controllo d’errore, quindi probabilmente dovresti usare un altro protocollo, come zmodem.

Per ricevere file, avvia il programma di invio sul lato remoto. Poi, digita ~C rz per iniziare a ricevere in locale.

Per inviare file, avvia il programma di ricezione sul lato remoto. Poi, digita ~C sz files per inviarli sul sistema remoto.

FreeBSD ha la capacità di avviare un sistema con soltanto un terminale stupido su porta seriale come console. Una configurazione simile dovrebbe essere utile per due tipi di persone: amministratori di sistema che desiderano installare FreeBSD su macchine che non hanno tastiera o monitor connesso, e sviluppatori che vogliono effettuare il debug del kernel o dei driver.

Come descritto nel La Procedura di Avvio, FreeBSD implementa un avviamento composto da tre stadi. I primi due stadi sono nel blocco di avvio che viene immagazzinato all’inizio della slice di FreeBSD sul disco d’avvio. Il blocco di avvio poi carica ed avvia il loader (/boot/loader) come terzo stadio.

Per poter impostare la console seriale devi configurare il codice del blocco di avvio, il codice del loader ed il kernel.

Questa sezione presuppone che stai usando una configurazione di default e vuoi solamente una veloce panoramica su come abilitare una console seriale.

Se si necessita di una diversa configurazione, esiste una spiegazione maggiormente dettagliata nella sezione Configurazione della Console Seriale.

Dopo che il loader è stato caricato e ti trovi nel terzo stadio del processo di avvio puoi ancora passare dalla console interna alla console seriale impostando le variabili d’ambiente appropriate nel loader. Guarda la Cambiamento della Console dal Loader.

Qui c’è il sommario delle varie impostazioni discusse in questa sezione e la console eventualmente selezionata.

Le sezioni precedenti hanno descritto come impostare la console seriale lavorando sul blocco di avvio. Questa sezione mostra come specificare a console inserendo alcuni comandi ed alcune variabili di ambiente nel loader. Quando il loader verrà invocato al terzo stadio del processo di avvio, dopo il blocco di avvio, le impostazioni nel loader prenderanno il posto di quelle nel blocco di avvio.

L’idea di tutto questo è di permettere alla gente di mettere su server dedicati che non abbiano bisogno di hardware grafico o di tastiere. Sfortunatamente, mentre la maggior parte dei sistemi ti permetteranno di avviare senza tastiera, ce ne sono alcuni che non ti permetteranno di partire senza un adattatore grafico. Le macchine con BIOS AMI possono essere configurate per partire senza adattatori grafici cambiando semplicemente il valore di "graphics adapter" nella configurazione CMOS a "Not installed".

Ad ogni modo, molte macchine non supportano questa opzione e si rifiuteranno di avviarsi se non si ha hardware grafico nel sistema. Con queste macchine, avrai bisogno di lasciare un qualche tipo di scheda grafica attaccata, (anche una scheda monocromatica di recupero) sebbene non avrai necessità di collegare un monitor. Potresti anche tentare di installare un BIOS AMI.