Sophie

Sophie

distrib > Mandriva > 9.1 > i586 > by-pkgid > f1098342ec4a2b28475e34123ce17201 > files > 816

howto-html-it-9.1-0.5mdk.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE>Linux PPP HOWTO: Risoluzione dei problemi</TITLE>
 <LINK HREF="PPP-HOWTO-19.html" REL=next>
 <LINK HREF="PPP-HOWTO-17.html" REL=previous>
 <LINK HREF="PPP-HOWTO.html#toc18" REL=contents>
</HEAD>
<BODY>
<A HREF="PPP-HOWTO-19.html">Avanti</A>
<A HREF="PPP-HOWTO-17.html">Indietro</A>
<A HREF="PPP-HOWTO.html#toc18">Indice</A>
<HR>
<H2><A NAME="problems"></A> <A NAME="s18">18. Risoluzione dei problemi</A></H2>

<P>Ci possono essere diversi motivi per i quali la propria connessione non
funziona: chat non &egrave; arrivato correttamente alla fine della sua
esecuzione, oppure si ha una linea molto disturbata, ecc. Quindi si
controlli nei log di sistema per indicazioni.
<P>
<H2><A NAME="ss18.1">18.1 Ho compilato il supporto per il PPP nel kernel, ma...</A>
</H2>

<P>Un problema molto comune &egrave; 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&ograve; pu&ograve; accadere.
<P>
<H3>Si &egrave; fatto il boot con il kernel giusto?</H3>

<P>Sebbene si sia <B>ricompilato</B> il supporto per il ppp nel proprio
kernel, non si &egrave; fatto il boot con il nuovo kernel. Ci&ograve; pu&ograve; succedere
se non si &egrave; aggiornato <CODE>/etc/lilo.conf</CODE> e rilanciato lilo.
<P>
<P>Una buona verifica sul kernel la si pu&ograve; ottenere usando il comando
<CODE>uname -a</CODE>, che dovrebbe produrre una riga simile a
<P>
<HR>
<PRE>
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
</PRE>
<HR>
<P>
<P>Questa mostra la versione del kernel e la data della sua compilazione,
che dovrebbero dare un'idea abbastanza buona di cosa sta funzionando.
<P>
<H3>Si &egrave; compilato il supporto per il ppp come modulo?</H3>

<P>Se si &egrave; compilato il supporto per il ppp a livello kernel come modulo,
ma non si sono creati ed installati i moduli, allora si pu&ograve; ottenere
questo tipo di errore. Si veda il Kernel-HOWTO e il file README in
<CODE>/usr/src/linux</CODE>!
<P>
<P>Un'altra possibilit&agrave; connessa ai moduli &egrave; che ci si aspetta che il
modulo sia caricato automaticamente, ma non &egrave; in esecuzione il demone
<CODE>kerneld</CODE> (che automaticamente carica e scarica i moduli quando
necessario). Si veda il kerneld mini-HOWTO per informazioni su come
configurare kerneld.
<P>
<H3>Si sta usando la versione corretta di PPP per il proprio kernel?</H3>

<P>Si <B>deve</B> usare ppp-2.2 con kernel versione 2.0.x. Si pu&ograve; 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.
<P>
<H3>Si sta eseguendo pppd come root?</H3>

<P>Se non si esegue pppd come utente root (e pppd non &egrave; suid a root), si
pu&ograve; ricevere questo messaggio.
<P>
<H2><A NAME="ss18.2">18.2 Il mio modem si connette ma il ppp non parte mai</A>
</H2>

<P>Ci sono innumerevoli variazioni sul tema (si dia un'occhiata a
comp.os.linux...).
<P>
<P>Un errore <B>MOLTO</B> comune &egrave; che si &egrave; scritto male qualcosa nei
propri script. La sola cosa da fare in questo caso &egrave; 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 <EM>riga
per riga</EM>. Pu&ograve; essere necessario connettersi manualmente al server PPP
e controllare ancora tutto.
<P>
<P>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'&egrave;
realmente scritto!
<P>
<H2><A NAME="ss18.3">18.3 Il log di sistema dice ``<CODE>serial line is not 8 bit clean</CODE>''</A>
</H2>

<P>Ci sono anche qui delle varianti, come <CODE>serial line looped back</CODE>,
ecc., e le cause possono essere molteplici (anche pi&ugrave; di una
contemporaneamente).
<P>
<P>Per capire cosa succede in questi casi, &egrave; necessario comprendere un
po' di quel che succede dietro le quinte durante l'esecuzione di pppd.
<P>
<P>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 &egrave; completa viene avviato lo strato IP
in modo che si possa usare la connessione PPP.
<P>
<P>Se non c'&egrave; 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&eacute; questi pacchetti
usano 8 bit, la loro riflessione causa la soppressione dell'ottavo bit
(si ricorda che ASCII &egrave; un codice a 7 bit). Il PPP vede questo e si
comporta di conseguenza.
<P>
<P>Ci sono diverse ragioni per cui pu&ograve; avvenire questa riflessione.
<P>
<H3>Non ci si &egrave; loggati correttamente nel server</H3>

<P>Quando il proprio script di conversazione termina, pppd viene avviato
nel proprio PC. Comunque, se non si &egrave; completato il processo di login
nel server (incluso l'invio di un qualsiasi comando necessario per
avviare il PPP nel server), PPP non verr&agrave; avviato.
<P>
<P>Quindi, i pacchetti LCP sono riflessi e si riceve questo errore.
<P>
<P>Si deve controllare attentamente e correggere (se necessario) il
proprio script di conversazione (si veda pi&ugrave; indietro).
<P>
<H3>Non si &egrave; avviato il PPP nel server</H3>

<P>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.
<P>
<P>Si verifichi il proprio script di conversazione (si veda pi&ugrave; indietro).
<P>
<P>Se si fa il login manualmente e si scopre che &egrave; 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&agrave; invia un RETURN).
<P>
<H3>Il processo PPP remoto &egrave; lento a partire</H3>

<P>Questa &egrave; un po' una birichinata!
<P>
<P>Di default, il proprio pppd &egrave; compilato per inviare un massimo di 10
richieste di configurazione lcp. Se il server &egrave; un po' lento a
partire, tutte le 10 richieste possono essere spedite prima che il
server sia pronto a riceverle.
<P>
<P>Nella propria macchina, pppd si vede tutte le 10 richieste che gli
tornano indietro (senza l'ottavo bit) ed esce.
<P>
<P>Ci sono due modi per aggirare questo problema:
<P>
<P>Aggiungere un <CODE>lcp-max-configure 30</CODE> alle proprie opzioni del
ppp. Ci&ograve; incrementa il numero massimo di pacchetti di configurazione
LCP che pppd invia prima di uscire. Per server veramente lenti, pu&ograve;
essere necessario incrementare ancora di pi&ugrave; tale numero.
<P>
<P>In alternativa, si pu&ograve; 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 <B>primo</B> carattere ad apparire fra le porcherie prodotte
dal server ppp &egrave; sempre il carattere tilde (~).
<P>
<P>Usando questa conoscenza a priori, si pu&ograve; aggiungere una nuova coppia
di stringhe <CODE>attesa/inviata</CODE> alla fine dello script di
conversazione che aspetta una tilde e non invia niente. Cio&egrave; qualcosa
di simile a:
<P>
<HR>
<PRE>
\~      ''
</PRE>
<HR>
<P>
<P>Nota: poich&eacute; il carattere tilde ha un significato particolare nella
shell, ne deve essere fatto l'escape (e quindi metterci prima un
backslash).
<P>
<H2><A NAME="ss18.4">18.4 Instradamento predefinito non impostato (<CODE>Default route not set</CODE>)</A>
</H2>

<P>Se pppd si rifiuta di impostare un instradamento predefinito, &egrave; perch&eacute;
(abbastanza giustamente) si rifiuta di rimuovere/rimpiazzare un
instradamento predefinito preesistente.
<P>
<P>La ragione classica per cui capita questo errore &egrave; che alcune
distribuzioni impostano l'instradamento predefinito verso la propria
scheda Ethernet invece di impostare uno specifico instradamento di
rete.
<P>
<P>Si veda la Linux NAG ed il Net2/3 HOWTO per informazioni su come
impostare correttamente la propria scheda Ethernet e gli instradamenti
associati.
<P>
<P>Un'altra ragione potrebbe essere che la propria LAN usi gi&agrave; un
gateway/router e che la propria tabella di instradamento sia gi&agrave;
impostata per puntare, tramite l'instradamento predefinito, a tale
gateway.
<P>
<P>Sistemare questa situazione pu&ograve; 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 newsgroup o da qualcuno a cui
si possa chiedere la soluzione e che sia raggiungibile in maniera
diretta).
<P>
<H2><A NAME="ss18.5">18.5 Altri problemi</A>
</H2>

<P>Ci sono molte ragioni oltre a queste che possono causare il fallimento
della connessione ppp e/o non farla funzionare correttamente.
<P>
<P>Si vedano le PPP FAQ (che sono veramente una serie di domande e
risposte). &Egrave; un documento omnicomprensivo e le risposte SONO l&igrave;! Per
la mia (brutta) esperienza, se le risposte al proprio problema non
solo l&igrave;, il problema NON &egrave; 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 &egrave; rivelato essere un perfetto server PPP prima delle luci
dell'alba!
<P>
<HR>
<A HREF="PPP-HOWTO-19.html">Avanti</A>
<A HREF="PPP-HOWTO-17.html">Indietro</A>
<A HREF="PPP-HOWTO.html#toc18">Indice</A>
</BODY>
</HTML>