Ci possono essere diversi motivi per i quali la propria connessione non funziona: chat non è arrivato correttamente alla fine della sua esecuzione, oppure si ha una linea molto disturbata, ecc. Quindi si controlli nei log di sistema per indicazioni.
Un problema molto comune è che la gente compila il supporto per il PPP nel kernel, ed ancora quando provano a lanciare pppd, il kernel afferma che non ha il supporto per il ppp! Ci sono diverse ragioni per le quali ciò può accadere.
Sebbene si sia ricompilato il supporto per il ppp nel proprio
kernel, non si è fatto il boot con il nuovo kernel. Ciò può succedere
se non si è aggiornato /etc/lilo.conf e rilanciato lilo.
Un buona verifica sul kernel la si può ottenere usando il comando
uname -a, che dovrebbe produrre una riga simile a
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
Questa mostra la versione del kernel e la data della sua compilazione, che dovrebbero dare un'idea abbastanza buona di cosa sta funzionando.
Se si è compilato il supporto per il ppp a livello kernel come modulo,
ma non si sono creati ed installati i moduli, allora si può ottenere
questo tipo di errore. Si veda il Kernel-HOWTO e il file README in
/usr/src/linux!
Un'altra possibilità connessa ai moduli è che ci si aspetta che il
modulo sia caricato automaticamente, ma non è in esecuzione il demone
kerneld (che automaticamente carica e scarica i moduli quando
necessario). Si veda il kerneld mini-HOWTO per informazioni su come
configurare kerneld.
Si deve usare ppp-2.2 con kernel versione 2.0.x. Si può usare ppp-2.2 con kernel versione 1.2.x (se si applica una patch al kernel) altrimenti si deve usare ppp-2.1.2.
Se non si esegue pppd come utente root (e pppd non è suid a root), si può ricevere questo messaggio.
Ci sono innumerevoli variazioni sul tema (si dia un'occhiata a comp.os.linux...).
Un errore MOLTO comune è che si è scritto male qualcosa nei propri script. La sola cosa da fare in questo caso è assicurarsi di registrare nei log di sistema (/var/log/messages) la conversazione di chat tra il proprio PC Linux e il server e poi analizzarla riga per riga. Può essere necessario connettersi manualmente al server PPP e controllare ancora tutto.
Nella registrazione si devono controllare molto attentamente i prompt reali, tenendo bene in mente che noi umani abbiamo la tendenza a leggere quello che PENSIAMO di aver scritto, e non quello che c'è realmente scritto!
serial line is not 8 bit clean..."
Ci sono anche qui delle varianti, come serial line looped back,
ecc., e le cause possono essere molteplici (anche più di una
contemporaneamente).
Per capire cosa succede in questi casi, è necessario comprendere un po' di quel che succede dietro le quinte durante l'esecuzione di pppd.
Quando pppd viene avviato, invia pacchetti LCP (Link Control Protocol - Protocollo di Controllo del Collegamento) alla macchina remota. Se riceve una risposta valida allora passa allo stadio successivo (usando pacchetti IPCP - IP Control Protocol - Protocollo di Controllo IP) e solo quando questa negoziazione è completa viene avviato lo strato IP in modo che si possa usare la connessione PPP.
Se non c'è un server ppp funzionante all'altro capo quando il proprio PC invia pacchetti LCP, questi vengono riflessi dal processo di login della terminazione remota della connessione. Poiché questi pacchetti usano 8 bit, la loro riflessione causa la soppressione dell'ottavo bit (si ricorda che ASCII è un codice a 7 bit). Il PPP vede questo e si comporta di conseguenza.
Ci sono diverse ragioni per cui può avvenire questa riflessione.
Quando il proprio script di conversazione termina, pppd viene avviato nel proprio PC. Comunque, se non si è completato il processo di login nel server (incluso l'invio di un qualsiasi comando necessario per avviare il PPP nel server), PPP non verrà avviato.
Quindi, i pacchetti LCP sono riflessi e si riceve questo errore.
Si deve controllare attentamente e correggere (se necessario) il proprio script di conversazione (si veda più indietro).
Alcuni server PPP richiedono l'inserimento di un comando e/o di un RETURN dopo la completazione del processo di login prima di avviare il ppp dal loro lato della connessione.
Si verifichi il proprio script di conversazione (si veda più indietro).
Se si fa il login manualmente e si scopre che è necessario inviare un RETURN per avviare il PPP, si aggiunga semplicemente una coppia di stringhe attesa/inviata vuote alla fine del proprio script di conversazione (una stringa vuota in realtà invia un RETURN).
Questa è un po' una birichinata!
Di default, il proprio pppd è compilato per inviare un massimo di 10 richieste di configurazione lcp. Se il server è un po' lento a partire, tutte le 10 richieste possono essere spedite prima che il server sia pronto a riceverle.
Nella propria macchina, pppd si vede tutte le 10 richieste che gli tornano indietro (senza l'ottavo bit) ed esce.
Ci sono due modi per aggirare questo problema:
Aggiungere un lcp-max-configure 30 alle proprie opzioni del
ppp. Ciò incrementa il numero massino di pacchetti di configurazione
LCP che pppd invia prima di uscire. Per server veramente lenti, può
essere necessario incrementare ancora di più tale numero.
In alternativa, si può essere un po' furbini. Si dovrebbe aver notato che quando si fa il login a mano nel server PPP e il PPP viene avviato, il primo carattere ad apparire fra le porcherie prodotte dal server ppp è sempre il carattere tilde (~).
Usando questa conoscenza a priori, si può aggiungere una nuova coppia
di stringhe attesa/inviata alla fine dello script di
conversazione che aspetta una tilde e non invia niente. Cioè qualcosa
di simile a:
\~ ''
Nota: poiché il carattere tilde ha un significato particolare nella shell, ne deve essere fatto l'escape (e quindi metterci prima un backslash).
Default route not set)
Se pppd si rifiuta di impostare un instradamento predefinito, è perché (abbastanza giustamente) si rifiuta di rimuovere/rimpiazzare un instradamento predefinito preesistente.
La ragione classica per cui capita questo errore è che alcune distribuzioni impostano l'instradamento predefinito verso la propria scheda Ethernet invece di impostare uno specifico instradamento di rete.
Si veda la Linux NAG ed il Net2/3 HOWTO per informazioni su come impostare correttamente la propria scheda Ethernet e gli instradamenti associati.
Un'altra ragione potrebbe essere che la propria LAN usi già un gateway/router e che la propria tabella di instradamento sia già impostata per puntare, tramite l'instradamento predefinito, a tale gateway.
Sistemare questa situazione può richiedere un po' di buone nozioni di IP networking e va oltre lo scopo di questo HOWTO. Si consiglia di trovare qualche aiuto esperto (tramite news group o da qualcuno a cui si possa chiedere la soluzione e che sia raggiungibile in maniera diretta).
Ci sono molte ragioni oltre a queste che possono causare il fallimento della connessione ppp e/o non farla funzionare correttamente.
Si vedano le PPP FAQ (che sono veramente una serie di domande e risposte). È un documento omni comprensivo e le risposte SONO lì! Per la mia (brutta) esperienza, se le risposte al proprio problema non solo lì, il problema NON è un errore del ppp! Nel mio caso usavo un kernel ELF e non avevo aggiornato i moduli correttamente. Ho perso solamente due giorni (e buona parte di una notte) a stanare quello che si è rivelato essere un perfetto server PPP prima delle luci dell'alba!