[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
In un altro capitolo (51) è stato presentato il funzionamento e l'uso dei programmi Getty per la gestione dell'accesso dalla console e da terminali connessi alle porte seriali. In questo capitolo si vuole trattare il problema particolare della connessione via modem.
Nei sistemi GNU/Linux, i dispositivi delle porte seriali sono quelli che corrispondono al modello /dev/ttyS*. In passato sono stati utilizzati anche dispositivi del tipo /dev/cua*, che attualmente sono obsoleti e non devono essere più utilizzati.
Le porte seriali possono essere usate in vario modo, come si è potuto vedere nei capitoli precedenti, dove la connessione alla linea telefonica tramite un modem è solo uno dei tanti utilizzi possibili.
Quando si utilizzano le porte seriali per una connessione diretta attraverso un cavo Null-modem, oppure attraverso una linea dedicata (attraverso l'uso di modem), queste porte seriali hanno un ruolo preciso che non può cambiare. Al contrario, quando si utilizza la rete telefonica commutata, si può distinguere tra l'attendere una chiamata e l'esecuzione di una chiamata. In pratica, si potrebbe utilizzare un modem sia per attendere delle chiamate esterne, a cui un programma Getty dovrebbe rispondere, sia per chiamare, quando la linea telefonica e il modem sono liberi.
Convenzionalmente, i programmi che utilizzano i file di dispositivo seriali creano (o dovrebbero creare) un file di lock corrispondente. È in base alla presenza di questi file di lock che i programmi Getty sono in grado di determinare se il modem viene utilizzato per chiamare.
I nomi di questi file di lock dovrebbero essere organizzati secondo il modello seguente, che risponde al cosiddetto stile UUCP.
/var/lock/LCK..dispositivo
Per esempio, il file di lock del file di dispositivo /dev/ttyS0 dovrebbe essere /var/lock/LCK..ttyS0.
I file di lock devono contenere il numero e il nome del processo per i quali sono stati generati. In tal modo, si può verificare se il processo che ha generato il file è ancora attivo. Infatti, spesso capita che il processo termini e con questo anche l'utilizzo del file di dispositivo, mentre il file di lock non viene rimosso.
Esistendo l'esigenza di creare e controllare i file di lock di questi file di dispositivo, la presenza di un collegamento /dev/modem può diventare un elemento di confusione, in quanto si potrebbe ottenere un file /var/lock/LCK..modem.
Il pacchetto Getty_ps (1) offre il programma uugetty per la connessione attraverso modem. Questo programma può utilizzare una serie di file:
/etc/gettydefs
file di configurazione delle impostazioni delle linee;
/etc/issue
file del messaggio introduttivo prima della procedura di accesso;
/var/log/getty.log
/etc/conf.uugetty, /etc/default/uugetty
file di configurazione di linea generico;
/etc/conf.uugettylinea, /etc/default/uugettylinea
file di configurazione di una linea particolare.
Questi file sono già stati descritti, in parte, nel capitolo 51.
In una sezione apposita (51.2.2) è stata descritta la sintassi e anche alcune direttive dei file /etc/conf.*getty* o /etc/default/conf.*getty*, per ciò che riguardava la connessione di una console o di un terminale seriale normale. Qui si intende approfondire l'uso delle direttive rivolte specificatamente a uugetty per la gestione delle linee seriali attraverso l'uso del modem. Inoltre, viene ripresa la descrizione di direttive già presentate in precedenza, che però sono utili per comprendere gli esempi proposti in questo capitolo.
L'utilizzo di uugetty è piuttosto delicato, per cui è opportuno predisporre il file di configurazione di linea per tutto ciò che con questo è possibile definire:
uugetty [opzioni] linea [velocità [tipo] ]
Eventualmente può essere utile l'opzione -d, proprio per indicare esplicitamente quale sia tale file di configurazione.
L'esempio seguente mostra una riga del file /etc/inittab:
s1:2345:respawn:/sbin/uugetty -d /etc/default/uugetty.ttyS1 ttyS1 F115200 vt100 |
In questo modo, si avvia uugetty per controllare l'accesso attraverso un modem collegato alla seconda linea seriale, /dev/ttyS1. All'interno del file /etc/gettydefs viene selezionata la voce F115200, che indica una velocità fissa di 115 200 bit/s. Il tipo di terminale utilizzato è stato vt100 corrispondente al più semplice e comune. Il file di configurazione di linea è stato indicato espressamente: /etc/default/uugetty.ttyS1.
GNU/Linux gestiva inizialmente due tipi di file di dispositivo per le porte seriali: uno per le chiamate in entrata e l'altro per le chiamate in uscita. In quella situazione, se uugetty stava in attesa di una chiamata, doveva utilizzare il dispositivo /dev/ttyS* relativo, ma volendo permettere l'utilizzo di un modem anche per le chiamate in uscita da parte di altri programmi (quando la linea era libera), uugetty doveva verificare anche i file di lock eventualmente esistenti su quei dispositivi (/dev/cua*).
Quando si configurava uugetty in questo modo, era anche necessario dirigere sul file di dispositivo /dev/cua* corrispondente il sistema di inizializzazione del modem.
In pratica, diventava necessario utilizzare le direttive ALTLOCK, ALTLINE e INITLINE del file di configurazione di linea, assegnando a tutte la stessa linea cuan.
uugetty permette di inizializzare il modem prima di utilizzare la linea. Ciò attraverso la direttiva INIT del file di configurazione di linea.
Le stringhe di attesa e invio possono contenere delle sequenze di escape, ma in particolare, il carattere <CR> deve essere indicato espressamente e si rappresenta con la sequenza \r. La tabella 132.3 ne riporta l'elenco.
Tabella 132.3. Sequenze di escape per le stringhe di attesa e invio di uugetty.
| Simbolo | Significato |
| \r | <CR> (carriage return). |
| \s | <SP> (carattere spazio). |
| \p | Ritardo di un secondo. |
| \d | Ritardo di due secondi. |
| \K | Break di 0,25 s. |
| \Tn | Modifica del tempo di timeout. |
Dopo l'inizializzazione del modem, se esiste una di queste due direttive nel file di configurazione della linea, uugetty resta in attesa di un carattere, nel caso di WAITCHAR, oppure di una stringa specifica, nel caso di WAITFOR.
In mancanza di una di queste due direttive (che comunque non possono essere usate simultaneamente), uugetty procede alla fase successiva: l'analisi della direttiva CONNECT.
Se non è stata usata alcuna delle direttive WAITCHAR e WAITFOR, oppure se è stata usata la direttiva WAITFOR, si può usare anche la direttiva CONNECT. Questa permetterà di definire una sequenza di attesa e invio ulteriore, utile in particolare per fissare la velocità della linea seriale in funzione della velocità di connessione definita dal modem.
Quando si utilizzano modem funzionanti a velocità inferiori a 9 600 bit/s, è necessario che la velocità utilizzata per la comunicazione con la porta seriale sia esattamente uguale alla massima velocità gestibile dal modem. Pertanto, in questi casi, è conveniente configurare automaticamente tale velocità in base al responso ottenuto dal modem attraverso il messaggio CONNECT.
In pratica, si usano le direttive WAITFOR e CONNECT in modo simile all'esempio seguente:
WAITFOR=RING CONNECT="" ATA\r CONNECT\s\A |
In questo modo, quando il modem genera la stringa RING a seguito di una chiamata in corso, ovvero a causa dello squillo del telefono, uugetty, senza attendere, invia il comando ATA con cui si apre la comunicazione, attendendo la stringa CONNECT seguita da uno spazio e da un numero. Qui, la sequenza di escape \A rappresenta il numero che si vuole estrarre per determinare la velocità a cui deve essere messa la linea seriale.
Per la precisione, uugetty tenta di trovare una voce nel file /etc/gettydefs corrispondente esattamente al numero ottenuto; altrimenti, se non lo trova, tenta semplicemente di modificare la velocità.
|
Disponendo di modem recenti, non è conveniente l'utilizzo della direttiva CONNECT, essendo preferibile l'utilizzo di una velocità elevata e fissa. |
Nelle sezioni seguenti vengono mostrati alcuni esempi, parte dei quali sono estratti dal gruppo di quelli che accompagnano il pacchetto Getty_ps. Questi sono stati modificati in modo da commentare le direttive riferite alla gestione dei dispositivi obsoleti /dev/cua*, in modo da escluderle.
Il file /etc/gettydefs a cui si fa riferimento per questi esempi, è quello che fa parte della distribuzione standard di Getty_ps e, in ogni caso, deve contenere almeno le direttive seguenti, specifiche per l'uso del modem (molte righe sono spezzate in due per motivi tipografici).
F230400# B230400 CS8 CRTSCTS # B230400 SANE -ISTRIP HUPCL CRTSCTS #@S login: (segue) |
F115200# B115200 CS8 CRTSCTS # B115200 SANE -ISTRIP HUPCL CRTSCTS #@S login: (segue) |
F57600# B57600 CS8 CRTSCTS # B57600 SANE -ISTRIP HUPCL CRTSCTS #@S login: (segue) |
F38400# B38400 CS8 CRTSCTS # B38400 SANE -ISTRIP HUPCL CRTSCTS #@S login: (segue) |
F19200# B19200 CS8 CRTSCTS # B19200 SANE -ISTRIP HUPCL CRTSCTS #@S login: (segue) |
F9600# B9600 CS8 CRTSCTS # B9600 SANE -ISTRIP HUPCL CRTSCTS #@S login: #F9600 |
F2400# B2400 CS8 CRTSCTS # B2400 SANE -ISTRIP HUPCL CRTSCTS #@S login: #F2400 |
230400# B230400 CS8 CRTSCTS # B230400 SANE -ISTRIP HUPCL CRTSCTS #@S login: (segue) |
115200# B115200 CS8 CRTSCTS # B115200 SANE -ISTRIP HUPCL CRTSCTS #@S login: (segue) |
57600# B57600 CS8 CRTSCTS # B57600 SANE -ISTRIP HUPCL CRTSCTS #@S login: #38400 |
38400# B38400 CS8 CRTSCTS # B38400 SANE -ISTRIP HUPCL CRTSCTS #@S login: #19200 |
19200# B19200 CS8 CRTSCTS # B19200 SANE -ISTRIP HUPCL CRTSCTS #@S login: #9600 |
9600# B9600 CS8 CRTSCTS # B9600 SANE -ISTRIP HUPCL CRTSCTS #@S login: #2400 |
2400# B2400 CS8 CRTSCTS # B2400 SANE -ISTRIP HUPCL CRTSCTS #@S login: #230400 |
L'esempio seguente è tratto dai file che accompagnano la documentazione di uugetty. Si riferisce alla connessione attraverso la terza porta seriale, ovvero a un modem corrispondente al dispositivo /dev/ttyS2 (e una volta anche a /dev/cua2).
# [ put this file in /etc/default/uugetty.<line> ] # # sample uugetty configuration file for a Hayes compatible modem to allow # incoming modem connections # # this config file sets up uugetty to answer with a WAITFOR string. When # using waitfor, it is necessary to specify INITLINE=cua? ## line to use to do initialization. All INIT, OFF, and WAITFOR functions ## are handled on this line. If this line is not specified, any other ## program that wants to share the line (like kermit, uucp, seyon) will ## fail. This line will also be checked for lockfiles. ## ## format: <line> (without the /dev/) #INITLINE=cua2 # timeout to disconnect if idle... TIMEOUT=60 # modem initialization string... Sets the modem to disable auto-answer # # format: <expect> <send> ... (chat sequence) INIT="" \d+++\dAT\r OK\r\n ATH0\r OK\r\n AT\sM0\sE1\sQ0\sV1\sX4\sS0=0\r OK\r\n # waitfor string... if this sequence of characters is received over the line, # a call is detected. WAITFOR=RING # this line is the connect chat sequence. This chat sequence is performed # after the WAITFOR string is found. The \A character automatically sets # the baudrate to the characters that are found, so if you get the message # CONNECT 2400, the baud rate is set to 2400 baud. # # format: <expect> <send> ... (chat sequence) CONNECT="" ATA\r CONNECT\s\A # this line sets the time to delay before sending the login banner DELAY=1 |
La stringa di inizializzazione è abbastanza completa e dovrebbe adattarsi alla maggior parte dei modem. In particolare si osservi il fatto che il registro S0 viene posto a zero, in modo da inibire la risposta automatica da parte del modem.
Dal momento che il modem non può rispondere da solo, si deve attendere la stringa RING; quindi, attraverso la direttiva CONNECT si invia il comando per aprire la linea, e subito dopo si estrae il valore della velocità di connessione.
Una volta terminata questa procedura, c'è ancora un secondo di pausa e quindi viene inviato il messaggio introduttivo e la richiesta di iniziare la procedura di accesso.
Il file /etc/inittab potrebbe contenere il record seguente, per attivare uugetty in modo da utilizzare questa configurazione.
s2:2345:respawn:/sbin/uugetty -d /etc/default/uugetty.ttyS2 ttyS2 115200 vt100 |
L'esempio seguente è tratto dai file che accompagnano la documentazione di uugetty. Si riferisce alla connessione attraverso la terza porta seriale, ovvero a un modem corrispondente al dispositivo /dev/ttyS2 (ed eventualmente anche /dev/cua2).
La differenza fondamentale rispetto all'esempio precedente sta nel fatto che è il modem a rispondere, avendo attivato la risposta al primo squillo con il comando AT...S0=1, pertanto non si attende la solita stringa RING.
# [ put this file in /etc/default/uugetty.<line> ] # # sample uugetty configuration file for a Hayes compatible modem to allow # incoming modem connections # # this config file sets the modem to autoanswer. ## alternate lockfile to check... if this lockfile exists, then uugetty is ## restarted so that the modem is re-initialized #ALTLOCK=cua2 # timeout to disconnect if idle... TIMEOUT=60 # modem initialization string... Sets the modem to auto-answer # # format: <expect> <send> ... (chat sequence) INIT="" \d+++\dAT\r OK\r\n ATH0\r OK\r\n AT\sM0\sE1\sQ0\sV1\sX4\sS0=1\r OK\r\n # this line sets the time to delay before sending the login banner DELAY=1 |
In alternativa, si può aggiungere l'inizializzazione del modem ai valori di fabbrica (AT&F) e la successiva definizione di altri elementi importanti (AT&D2&C1) con una stringa come quella seguente, che viene divisa su più righe per motivi tipografici (nell'esempio viene attivato anche l'altoparlante).
INIT="" \d+++\dAT\r OK\r\n ATH0\r OK\r\n (segue) |
Sempre proseguendo il paragone con l'esempio precedente, si può osservare che è stata omessa anche la direttiva CONNECT. In questo caso, quindi, è il modem che si attiva da solo e subito dopo, uugetty provvede ad avviare la procedura di accesso.
Il file /etc/inittab potrebbe contenere lo stesso record già visto nell'esempio precedente.
La connessione di un terminale utilizzando una linea dedicata, che implica l'utilizzo di due modem (uno a ogni capo del filo), è una situazione un po' insolita, ma utile a titolo didattico. L'esempio seguente, come sempre, si riferisce a una connessione attraverso la terza porta seriale, ovvero a un modem corrispondente al dispositivo /dev/ttyS2.
#====================================================================== # /etc/default/uugetty.ttyS2 #====================================================================== #---------------------------------------------------------------------- # Si fissa il tempo massimo per il login in 60 secondi. #---------------------------------------------------------------------- TIMEOUT=60 #---------------------------------------------------------------------- # Si inizializza il modem in modo semplificato: # +++ AT porta il modem nella modalità di comando; # ATH0 chiude la linea; # ATZ carica il profilo di configurazione prememorizzato; # AT&L1A configura il modem per la linea dedicata (&L1) e # attiva la ricezione (A). # Infine, si attende il messaggio «CONNECT» che indica l'avvenuta # connessione. #---------------------------------------------------------------------- INIT="" \d+++\dAT\r OK\r\n ATH0\r OK\r\n ATZ\r OK\r\n AT&L1A\r CONNECT #---------------------------------------------------------------------- # Dal momento che il modem è abbastanza veloce, non è necessario # l'autobauding. # Pertanto, la stringa «CONNECT» viene già attesa dalla sequenza di # inizializzazione della direttiva INIT. #---------------------------------------------------------------------- ###CONNECT=CONNECT\s\A #---------------------------------------------------------------------- # Dopo due secondi, trasmette il messaggio introduttivo e la richiesta # di login. #---------------------------------------------------------------------- DELAY=2 #====================================================================== |
Per eseguire questa prova è stato inserito il record seguente nel file /etc/inittab.
s2:2345:respawn:/sbin/uugetty -d /etc/default/uugetty.ttyS2 ttyS2 115200 vt100 |
Dall'altra parte, dal terminale dal quale si effettua il collegamento, si è dovuto utilizzare il comando ATX1&L1D, in modo da attivare il modem in chiamata sulla linea dedicata.
Lo stesso identico risultato dell'esempio precedente si può ottenere modificando il file /etc/default/uugetty.ttyS2 in modo da lasciare alla direttiva CONNECT il compito di attendere la stringa omonima. Segue il pezzo di file con le varianti.
# ... ... #---------------------------------------------------------------------- # Si inizializza il modem in modo semplificato: # +++ AT porta il modem nella modalità di comando; # ATH0 chiude la linea; # ATZ carica il profilo di configurazione prememorizzato; # AT&L1A configura il modem per la linea dedicata (&L1) e # attiva la ricezione (A). #---------------------------------------------------------------------- INIT="" \d+++\dAT\r OK\r\n ATH0\r OK\r\n ATZ\r OK\r\n AT&L1A\r #---------------------------------------------------------------------- # Si attende la stringa «CONNECT». #---------------------------------------------------------------------- CONNECT=CONNECT # ... ... |
Come ultima possibilità, nel caso si utilizzino modem vecchi che richiedono velocità particolarmente basse, si può sfruttare l'autobauding, estraendo la velocità attraverso la direttiva CONNECT.
# ... ... #---------------------------------------------------------------------- # Si attende la stringa «CONNECT» e si modifica automaticamente # la velocità della linea. #---------------------------------------------------------------------- CONNECT=CONNECT\s\A # ... ... |
Per attivare una connessione PPP attraverso uugetty, così come fa un fornitore di accesso a Internet, basta attribuire all'utente che deve accedere in questo modo, al posto della solita shell, uno script che attivi il PPP.
Lo script seguente è molto semplice e si limita a definire un indirizzo IP per l'elaboratore che offre il servizio e uno per l'elaboratore che accede. Se si volessero gestire diversi accessi, con indirizzi IP dinamici, occorrerebbe modificare tale script opportunamente, per fare in modo di trovare il primo indirizzo IP libero.
#! /bin/sh
#======================================================================
# server-ppp
# Attiva la connessione PPP come servente.
#======================================================================
IP_REMOTO="192.168.200.2" # IP da assegnare all'elaboratore remoto
IP_SERVER="192.168.200.1" # IP locale
VELOCITA="38400"
/usr/sbin/pppd \
mru 1500 \
mtu 1500 \
passive \
modem \
crtscts \
$IP_SERVER:$IP_REMOTO \
$VELOCITA \
noauth \
refuse-chap \
refuse-pap
|
|
Si osservi il fatto che non è stato indicato il dispositivo da utilizzare per la connessione. |
Dall'altra parte, per la connessione, si possono utilizzare due script differenti, a seconda che si faccia una connessione a un servizio accessibile attraverso la linea telefonica commutata o attraverso una linea dedicata. L'idea di una connessione attraverso una linea dedicata in questo modo, è piuttosto strana, dal momento che si potrebbe evitare di utilizzare una procedura di accesso. Lo scopo di questo esempio è quindi solo didattico, per permettere di sperimentare quanto affermato anche senza utilizzare le connessioni telefoniche normali.
Negli esempi seguenti, si suppone che il cliente utilizzi la seconda porta seriale per accedere al modem.
#! /bin/sh
#======================================================================
# ppp-on
# Attiva la connessione al proprio ISP attraverso pppd e chat.
#======================================================================
IP_ISP="0.0.0.0"
IP_LOCALE="0.0.0.0"
DISPOSITIVO="/dev/ttyS1"
VELOCITA="38400"
TELEFONO="1234567890" # Il numero di telefono dell'ISP.
PPP_ACCOUNT="caio" # Il nome utilizzato per accedere.
PPP_PASSWORD="coccole" # La password per accedere.
/usr/sbin/pppd \
connect "/usr/sbin/chat -v \
TIMEOUT 3 \
ABORT BUSY \
ABORT 'NO CARRIER' \
'' ATZ \
OK AT \
OK 'AT DT $TELEFONO' \
TIMEOUT 30 \
CONNECT '' \
ogin:--ogin: $PPP_ACCOUNT \
word: $PPP_PASSWORD" \
crtscts modem \
defaultroute \
$IP_LOCALE:$IP_ISP \
$DISPOSITIVO \
$VELOCITA
|
#! /bin/sh
#======================================================================
# ppp-on-leased
# Test per accedere a una connessione PPP con una linea dedicata.
#======================================================================
IP_ISP="0.0.0.0"
IP_LOCALE="0.0.0.0"
DISPOSITIVO="/dev/ttyS1"
VELOCITA="38400"
PPP_ACCOUNT="caio" # Il nome utilizzato per accedere.
PPP_PASSWORD="coccole" # La password per accedere.
/usr/sbin/pppd \
connect "/usr/sbin/chat -v \
TIMEOUT 3 \
ABORT BUSY \
ABORT 'NO CARRIER' \
'' ATZ \
OK AT \
OK 'ATX1 &L1D' \
TIMEOUT 30 \
CONNECT '' \
ogin:--ogin: $PPP_ACCOUNT \
word: $PPP_PASSWORD " \
crtscts modem \
defaultroute \
$IP_LOCALE:$IP_ISP \
$DISPOSITIVO \
$VELOCITA
|
La differenza fondamentale tra i due script sta nel comando di composizione che nell'ultimo viene trasformato in ATX1 &L1D.
Mgetty+Sendfax (2) è già descritto in parte in un altro capitolo (51). Questo programma può utilizzare una serie di file:
/var/log/log_mg.ttyS*
/etc/nologin.ttyS*
file per impedire l'accesso attraverso una linea particolare;
/etc/mgetty+sendfax/mgetty.config
/etc/mgetty+sendfax/login.config
configurazione delle modalità di accesso.
L'eseguibile mgetty è l'essenza di Mgetty+Sendfax. La sua configurazione avviene fondamentalmente attraverso il file /etc/mgetty+sendfax/mgetty.config, ma alcune caratteristiche possono essere ridefinite anche attraverso le opzioni della riga di comando.
mgetty [opzioni] linea_tty
Di seguito vengono riportate le opzioni più interessanti per la gestione con il modem. Per il momento, la gestione del fax viene ignorata.
Gli esempi seguenti si riferiscono a record del file /etc/inittab, in cui la riga di comando di mgetty definisce il suo funzionamento, supponendo che il file di configurazione /etc/mgetty+sendfax/mgetty.config non sia stato predisposto.
s1:2345:respawn:/sbin/mgetty -s 38400 -m '"" ATH0 OK AT&F OK ATS0=0 OK' ttyS1 |
Attiva mgetty per una connessione con modem, attraverso la seconda porta seriale, impostando la velocità della porta a 38 400 bit/s e definendo la sequenza di inizializzazione del modem.
s1:2345:respawn:/sbin/mgetty -x 9 -s 38400 -m '"" ATH0 OK AT&F OK ATS0=0 OK' ttyS1 |
Come nell'esempio precedente, con la differenza che viene attivato il controllo diagnostico nel file /var/log/log_mg.ttyS1.
La gestione dei dispositivi seriali da parte di Mgetty+Sendfax è diversa rispetto a quanto descritto riguardo a Getty_ps. Per prima cosa, in relazione ai sistemi GNU/Linux, Mgetty+Sendfax riconosce un solo tipo di dispositivo: /dev/ttyS*. Quindi, non è in grado di verificare se i dispositivi obsoleti /dev/cua* corrispondenti sono utilizzati o meno.
Quando l'eseguibile mgetty viene avviato, verifica la presenza o meno del file di lock riferito al dispositivo seriale da utilizzare. Se esiste, mgetty verifica che corrisponda a un processo attivo e, in caso contrario, non lo considera e lo rimuove. Se il file di lock si dimostra valido, mgetty resta in attesa fino a quando continua a esistere tale file. Se mgetty trova la linea seriale libera, crea il suo file di lock, inizializza il modem e rimuove il file appena creato.
Successivamente, mgetty verifica la presenza o meno di «caratteri» dal modem, senza leggerli effettivamente. Quando ottiene l'indicazione della loro presenza, potrebbe trattarsi di un messaggio RING, che genera il modem quando sopraggiunge una chiamata, oppure potrebbe trattarsi di un programma che sta usando il modem per una chiamata in uscita. mgetty, prima di leggere dal modem, verifica che nel frattempo non sia stato creato un file di lock, a indicare proprio che si tratta di un altro programma che lo sta usando. In tal caso, evidentemente, mgetty si rimette in attesa che il file venga cancellato.
Se mgetty determina che si trattava di una chiamata entrante, crea il proprio file di lock, apre la comunicazione e invia il messaggio necessario a iniziare la procedura di accesso. Quando la sessione di lavoro termina, allora rimuove il suo file di lock.
Ogni volta che mgetty si accorge dell'utilizzo del dispositivo da parte di un altro programma, quando il file di lock relativo viene rimosso, allora provvede a reinizializzare il modem, per riportarlo nello stato necessario a ricevere una chiamata.
|
Questo procedimento vale solo nel caso si utilizzi il modem, altrimenti, se si dispone di una connessione diretta, mgetty resta in attesa di leggere un carattere qualunque, bloccando la linea. |
Mgetty+Sendfax consente facilmente la ricezione di chiamate diverse da quelle del solito terminale per il quale si deve richiedere l'identificazione tramite una procedura di accesso. Ciò avviene in base al riconoscimento dei dati che vengono ricevuti all'inizio della connessione. Tra le tante cose, attraverso questa capacità di Mgetty+Sendfax è possibile l'attivazione di una connessione PPP in modo automatico, senza una procedura di autenticazione tradizionale come invece occorre fare con Getty_ps, lasciando comunque agli utenti la possibilità di continuare a utilizzarla.
In un capitolo apposito (51) è stato già descritto il file /etc/mgetty+sendfax/mgetty.config che rappresenta la forma di configurazione principale di Mgetty+Sendfax. In questa sezione si vogliono descrivere le direttive più importanti per l'utilizzo di Mgetty+Sendfax con i modem.
È comunque il caso di ricordare che il contenuto del file è divisibile in sezioni contenenti ognuna la configurazione riferita a ogni porta utilizzata. In pratica, quando si incontra la direttiva port, tutto quello che segue fino alla prossima direttiva port, riguarda solo quella porta particolare. Inoltre, tutto ciò che precede la prima direttiva port, viene inteso come riferito a tutte le porte nel loro insieme.
Segue la descrizione di alcuni esempi.
port ttyS1 |
Definisce l'inizio di una sezione specifica per la seconda porta seriale (/dev/ttyS1).
speed 38400 |
Definisce la velocità della porta a 38 400 bit/s.
direct no |
Specifica che si tratta di una connessione attraverso modem (è comunque il valore predefinito).
init-chat "" ATH0 OK AT&F OK ATS0=0 OK |
Specifica la sequenza di colloquio necessaria a inizializzare il modem. Si osservi che qui non occorre delimitare tutta la sequenza con gli apici singoli, come invece avviene quando si utilizza l'opzione -m.
debug 4 |
Fissa un livello diagnostico intermedio.
term vt100 |
Indica il tipo del terminale come vt100.
L'esempio seguente mostra il file mgetty.config e il record di /etc/inittab necessari ad attivare la prima porta seriale per una connessione diretta senza modem.
# /etc/mgetty+sendfax/mgetty.config
# Configura la seconda porta seriale
port ttyS0
direct no
init-chat "" ATH0 OK AT&F OK ATS0=0 OK
debug 9
speed 57600
term vt100
|
# /etc/inittab #... 7:2345:respawn:/sbin/mgetty ttyS0 |
Tra gli esempi che riguardano Getty_ps, viene mostrato un modo per effettuare una connessione PPP sostituendo la shell dell'utente con uno script adatto. Questo metodo può essere utilizzato anche con Mgetty+Sendfax.
Mgetty+Sendfax offre però un altro metodo aggiuntivo attraverso il file /etc/mgetty+sendfax/login.config. La documentazione di questo appare esclusivamente nei commenti del file stesso.
# # Automatic PPP startup on receipt of LCP configure request (AutoPPP). # mgetty has to be compiled with "-DAUTO_PPP" for this to work. # Warning: Case is significant, AUTOPPP or autoppp won't work! # Consult the "pppd" man page to find pppd options that work for you. /AutoPPP/ - a_ppp /usr/sbin/pppd auth refuse-chap require-pap login debug |
Con questa direttiva, se mgetty riconosce che si tratta di una connessione PPP, invece di presentare la richiesta di identificazione tramite una procedura di accesso tradizionale, si affretta ad avviare pppd annotando l'utente a_ppp nel file /var/run/utmp. In tale situazione, è normale che pppd richieda un'autenticazione PAP (dal momento che l'autenticazione di chi chiama diventa compito suo), utilizzando le informazioni sugli utenti registrati nel sistema (si osservino le opzioni auth, require-pap e login).
daniele @ swlibero.org1) Getty_ps software non libero: non è consentita la commercializzazione a scopo di lucro e in generale non è consentito alcun profitto economico derivante dall'uso o dalla riproduzione dello stesso
2) Mgetty+Sendfax software libero con licenza speciale che scade: dopo due anni dalla data di un'edizione particolare, si ricade nella licenza GNU GPL
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome getty_e_il_modem.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]