[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


115. Getty e il modem

Nel capitolo 36, è 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.

115.1 Dispositivi e file di lock

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, e 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 dispositivo `/dev/ttyS0' dovrebbe essere `/var/lock/LCK..ttyS0'.

Questi file devono contenere il numero e il nome del processo per i quali sono stati generati. In questo modo, si può verificare se il processo che ha generato il file di lock è ancora attivo. Infatti, spesso capita che il processo termini, e con questo anche l'utilizzo del dispositivo, mentre il file di lock non viene rimosso.

Esistendo l'esigenza di creare e controllare i file di lock di questi dispositivi, la presenza di un collegamento `/dev/modem' può diventare un elemento di confusione, in quanto si potrebbe ottenere un file `/var/lock/LCK..modem'.

115.2 Getty_ps

Il pacchetto Getty_ps offre il programma `uugetty' per la connessione attraverso modem. Questo programma può utilizzare una serie di file:

Questi file sono già stati descritti, in parte, nel capitolo 36.

115.2.1 Configurazione di linea

Nella sezione 36.2.2, è già 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.

Alcune direttive

LOGIN=<nome>

Con questa direttiva si può definire un nome e un percorso differente per il programma che si vuole utilizzare per la procedura di accesso. In modo predefinito dovrebbe trattarsi di `/bin/login'.

WAITCHAR=YES

WAITCHAR=NO

Se viene assegnato il valore `YES', `uugetty' attende un carattere dalla linea prima di iniziare a emettere l'invito alla connessione.

DELAY=<n-secondi>

Questa direttiva viene usata normalmente in congiunzione all'attivazione di `WAITCHAR', in modo da stabilire un ritardo in secondi dopo la ricezione del carattere dalla linea.

WAITFOR=<stringa>

Stabilisce una stringa da attendere prima di iniziare a mostrare l'invito della procedura di accesso. In pratica, al contrario di `WAITCHAR', si vuole attendere una stringa particolare, e non solo un carattere qualunque. Se viene usato in congiunzione a `DELAY', allora `uugetty' attende il numero di secondi stabilito a partire dal momento in cui la stringa è stata inserita completamente.

Questa direttiva viene usata normalmente per attendere la stringa `RING' da un modem che sta ricevendo una chiamata (quando squilla il telefono).

TIMEOUT=<n-secondi>

Fa in modo che il programma attenda per un numero massimo di secondi che l'utente completi la procedura di accesso; trascorso tale limite, `uugetty' termina l'esecuzione, e con lui la possibilità di accedere da quella linea.

Tuttavia, normalmente `uugetty' viene riavviato da Init, così si può ritentare la connessione e l'accesso.

INIT=<stringhe-di-attesa-invio>

Permette di definire una sequenza di stringhe di attesa e invio (expect, send) per inizializzare il modem prima di utilizzarlo.

CONNECT=<stringhe-di-attesa-invio>

Permette di specificare una sequenza di stringhe di attesa e invio specifiche per la connessione.

ALTLOCK=<linea>

Permette di specificare un nome di file di dispositivo (senza il prefisso `/dev/') utilizzato in modo alternativo per la stessa linea di comunicazione, per il quale creare un ulteriore file di lock.

In situazioni normali, questa direttiva dovrebbe essere inutile allo stato attuale con GNU/Linux. In passato, dovendo utilizzare sia i dispositivi `/dev/ttyS*' che `/etc/cua*', si poteva indicare in tal modo di bloccare anche questi dispositivi paralleli.

ALTLINE=<linea>

INITLINE=<linea>

Permette di specificare una linea alternativa per le operazioni di inizializzazione del modem. Si usava quando si dovevano gestire i dispositivi seriali a coppie. *1*

115.2.2 # uugetty

uugetty [<opzioni>] <linea> [<velocità> [<tipo>] ]

L'utilizzo di `uugetty' è piuttosto delicato, per cui è opportuno predisporre il file di configurazione di linea per tutto ciò che con questo è possibile definire. Eventualmente può essere utile l'opzione `-d', proprio per indicare esplicitamente quale sia tale file di configurazione.

Alcune opzioni

-d <file-di-configurazione>

Permette di indicare esplicitamente il file di configurazione di linea. Questa opzione è particolarmente utile quando non si sa precisamente quale sia il file di configurazione giusto per la versione di Getty_ps che si sta utilizzando.

Esempi

s1:2345:respawn:/sbin/uugetty -d /etc/default/uugetty.ttyS1 ttyS1 F115200 vt100

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 115200. 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'.

115.2.3 Sistema di lock

Quando GNU/Linux gestiva due tipi di file di dispositivo per le porte seriali, uno per le chiamate in entrata e l'altro per le chiamate in uscita, 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 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'.

115.2.4 INIT: inizializzazione della linea

`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 115.1 ne riporta l'elenco.

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 secondi.
\Tn Modifica del tempo di timeout.

Tabella 115.1: Sequenze di escape per le stringhe di attesa e invio di `uugetty'.

115.2.5 WAITCHAR, WAITFOR: attesa prima di iniziare

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'.

115.2.6 CONNECT: autobauding

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 un'ulteriore sequenza di attesa e invio, particolarmente utile 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 9600 bps, è 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, e quindi si attende 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.

115.2.7 Esempi

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, e quindi escludere, le direttive riferite alla gestione dei dispositivi obsoleti `/dev/cua*'.

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: 
#F230400

F115200# B115200 CS8 CRTSCTS # B115200 SANE -ISTRIP HUPCL CRTSCTS #@S login: 
#F115200

F57600# B57600 CS8 CRTSCTS # B57600 SANE -ISTRIP HUPCL CRTSCTS #@S login: 
#F57600

F38400# B38400 CS8 CRTSCTS # B38400 SANE -ISTRIP HUPCL CRTSCTS #@S login: 
#F38400

F19200# B19200 CS8 CRTSCTS # B19200 SANE -ISTRIP HUPCL CRTSCTS #@S login: 
#F19200

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: 
#115200

115200# B115200 CS8 CRTSCTS # B115200 SANE -ISTRIP HUPCL CRTSCTS #@S login: 
#57600

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

115.2.7.1 Connessioni in arrivo con attesa di una stringa

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

115.2.7.2 Connessioni in arrivo con risposta da parte del modem stesso

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, e quindi 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
AT&F\r OK\r\n AT&D2&C1\r OK\r\n ATM1E1Q0V1X3S0=1\r OK\r\n

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.

115.2.7.3 Connessioni in arrivo su linea dedicata

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.

115.2.7.4 Connessioni in arrivo su linea dedicata, varianti

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
# ... ...

115.2.7.5 Attivazione del PPP

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 detto 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.

115.3 Mgetty+Sendfax

Mgetty+Sendfax è già stato descritto in parte nel capitolo 36. Questo programma può utilizzare una serie di file:

115.3.1 # mgetty

mgetty [<opzioni>] <linea-tty>

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.

Di seguito vengono riportate le opzioni più interessanti per la gestione con il modem. Per il momento, la gestione del fax viene ignorata.

Alcune opzioni

-x n

Permette di definire il livello diagnostico attraverso l'indicazione di un numero, da zero a nove. Zero significa che non si vuole alcuna informazione, mentre il numero nove genera la maggior quantità di notizie. Tali indicazioni vengono inserite in un file di registrazioni, e dovrebbe trattarsi precisamente di `/var/log/log_mg.<linea>' (per esempio, la connessione con la prima porta seriale dovrebbe generare il file `/var/log/log_mg.ttyS0').

-s <velocità>

Imposta la velocità della porta.

-n <numero-squilli>

Permette di definire il numero di squilli dopo il quale rispondere. In modo predefinito, la risposta avviene dopo il primo squillo.

-D

Definisce in modo esplicito che il modem deve essere trattato per la trasmissione dati pura e semplice, escludendo la gestione del fax.

-a

Richiede di definire automaticamente la velocità della linea in base al responso `CONNECT'... È bene ricordare che questo meccanismo è utile solo quando si utilizzano dei modem molto vecchi che non sono in grado di operare a velocità fisse attraverso la connessione della porta seriale. In tutti gli altri casi, conviene evitare di utilizzare tale meccanismo, detto di autobauding, lasciando che la velocità di comunicazione attraverso la linea seriale resti fissa e sufficientemente grande da sopperire alle esigenze del modem.

-m <stringa-di-attesa-invio>

Definisce il colloquio con il modem attraverso una serie di sequenze di attesa e invio. L'argomento della stringa di colloquio è uno solo, per cui si utilizzano generalmente gli apici singoli all'esterno della stringa, e all'interno una serie di sottostringhe delimitate eventualmente da apici doppi.

Esempi

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 38400 bps, 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'.

115.3.2 Sistema di file di lock

La gestione dei dispositivi seriali da parte di Mgetty+Sendfax è diversa rispetto a quanto descritto riguardo a `uugetty'. Per prima cosa, 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.

115.3.3 Metodi di autenticazione

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 `uugetty', lasciando comunque agli utenti la possibilità di continuare a utilizzarla.

115.3.4 /etc/mgetty+sendfax/mgetty.config

Nel capitolo 36 è 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.

Alcune direttive

port <dispositivo>

Definisce l'inizio di una sezione specifica per una porta seriale particolare, identificata attraverso il nome del dispositivo.

speed <velocità>

Specifica la velocità della porta attraverso l'indicazione di un intero. È importante che il numero indicato esprima una velocità valida. Corrisponde all'uso dell'opzione `-s'.

direct {yes|no}

Se attivato (`yes') fa in modo che `mgetty' tratti la linea come un collegamento diretto, senza la presenza di un modem. Corrisponde all'uso dell'opzione `-r'.

data-only {yes|no}

Se attivato (`yes'), fa in modo che `mgetty' ignori la gestione del fax. Corrisponde all'uso dell'opzione `-D'.

init-chat <sequenze-di-attesa-invio>

Permette di definire la sequenza di colloquio necessaria a inizializzare il modem. Corrisponde all'uso dell'opzione `-m'.

rings <numero-squilli>

Definisce il numero di squilli da attendere prima di aprire la comunicazione. Corrisponde all'uso dell'opzione `-n'.

autobauding {yes|no}

Se attivato (`yes'), fa in modo che `mgetty' cerchi di definire automaticamente la velocità della linea in base al responso `CONNECT'... È bene ricordare che questo meccanismo è utile solo quando si utilizzano dei modem molto vecchi che non sono in grado di operare a velocità fisse attraverso la connessione della porta seriale. Corrisponde all'uso dell'opzione `-a'.

debug <livello-diagnostico>

Definisce il livello di dettaglio dei messaggi diagnostici inseriti nel file delle registrazioni, solitamente `/var/log/log_mg.ttyS*'. Il livello si esprime con un numero che va da zero (nessuna indicazione) a nove (massimo dettaglio). Corrisponde all'uso dell'opzione `-x'.

term <tipo-di-terminale>

Definisce il nome del terminale da utilizzare per inizializzare la variabile di ambiente `TERM'.

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 38400 bps.

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

115.3.5 Attivazione automatica del PPP

Tra gli esempi che riguardano `uugetty', 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').

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


1.) `ALTLINE' è probabilmente un sinonimo di `INITLINE', e inoltre, è possibile che `ALTLINE' sia proprio ignorato, e al suo posto venga riconosciuto solo `INITLINE'.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]