Obstaja morje razlogov, zakaj vaša povezava ne deluje - chat ni uspel pravilno dokončati svojega dela, imate motnje na liniji itd. Preglejte sistemski dnevnik za namige.
Zelo pogosta težava je, da ljudje vključijo PPP podporo v jedro, in ko poskušajo pognati pppd, se jedro pritoži da ne podpira ppp-ja! Za takšno obnašanje obstajajo različni razlogi.
Medtem ko ste prevedli jedro s posporo za ppp, ne poganjate pravega
jedra. To se lahko zgodi, če ne osvežite datoteke /etc/lilo.conf in
poženete lilota.
Dober test jedra lahko dobite z ukazom uname -a, ki bi moral izpisati
takšno vrstico
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
To izpiše verzijo jedra ter datum, ko je bilo jedro prevedeno - kar bi vam moralo dati kar dober namig, kaj se dogaja.
Če ste prevedli podporo za ppp v jedru kot modul, toda niste prevedli
modulov in jih namestili, lahko dobite tako napako. Preberite Kernel-HOWTO
in datoteko README v /usr/src/linux!
Še ena možnost v povezavi z moduli je, da pričakujete, da bodo potrebni
moduli avtomatsko naloženi, vendar ne poganjate kerneld-ja. (ki
avtomatsko nalaga in odstranjuje module po potrebi). Preverite kerneld
mini-HOWTO za navodila za namestitev kerneld-ja.
Z jedrom 2.0.x morate uporabljati ppp-2.2. Ppp-2.2 lahko uporabljate z jedri 1.2.x (če popravite jedro), sicer morate uporabljati ppp 2.1.2.
Če pppd-ja ne poganjate kot root (in pppd ni suid root), lahko prejmete to sporočilo.
Na to temo obstajajo brezštevilne variacije (poglejte v comp.os.linux...).
ZELO pogosta napaka je, da ste nekaj zatipkali v vaših skriptah. Edina
stvar, ki jo lahko naredite je, da zapisujete chatov pogovor med vašim
računalnikom z Linuxom in strežnikom v sistemski dnevnik
(/var/log/messages) in greste skozi ta izpis vrsto po vrsto.
Mogoče se boste morali ročno prijaviti na strežnik, da stvari spet preverite.
Dnevnik morate zelo pazljivo primerjati z dejanskimi pozivi in ves čas misliti, da imamo ljudje navado, da preberemo kar mislimo, da smo napisali, ne pa kar je dejansko napisano!
serial line is not 8 bit clean...``
Tudi na to obstajajo variacije - kot naprimer serial line looped back
ipd., razlog pa je lahko ena (ali zaporedje) od številnih stvari.
Za razumevanje kaj se dogaja, je nujno nekoliko doumeti, kaj se dogaja ,,za odrom``, kjer nastopa pppd.
Ko se pppd zažene, pošlje LCP (link control protocol) pakete oddaljenemu računalniku. Če sprejme veljaven odgovor, gre na naslednjo stopnjo (uporabi IPCP - kontrolne pakete za IP) in šele ko se to pogajanje konča, se zažene dejanski sloj IP, tako da lahko uporabljate PPP povezavo.
Če na drugem koncu ni ppp strežnika ko vaš PC pošlje lcp pakete, se ti zrcalijo na prijavnem procesu na oddaljenem koncu. Ker ti paketki uporabljajo 8 bitov, odbijanje olupi 8. bit (ASCII je 7-bitna koda). PPP to vidi in se potemtakem pritoži.
Obstaja več razlogov, da se pripeti to odbijanje.
Ko se vaša chat skripta zaključi, se na vašem računalniku zažene pppd. Če niste končali prijavnega procesa na strežniku (vključno s pošiljanjem ukaza za zagon PPP-ja na strežniku), se PPP ne bo zagnal.
Torej se lcp paketi odbijejo in dobite to napako.
Skrbno morate preveriti ni popraviti (po potrebi) vašo chat skripto (glejte zgoraj).
Nekateri PPP strežniki zahtevajo, da vpišete ukaz in/ali RETURN po zaključku prijave, preden oddaljeni računalnik zažene ppp.
Preverite chat skripto (glejte zgoraj).
Če se prijavite ročno in ugotovite, da morate po tem poslati RETURN za zagon PPP-ja, enostavno dodajte prazen pričakuj/pošlji par na konec vaše chat skripte (prazen niz dejnsko pošlje RETURN).
Ta problem je nekoliko bolj prebrisan!
Po privzeti vrednosti vaš računalnik z Linuxom pošlje največ 10 lcp konfiguracijskih zahtevkov. Če je strežnik nekoliko počasen, je lahko vseh 10 poslanih preden je oddaljeni PPP pripravljen za njihov sprejem.
Na vašem računalniku vidi pppd vseh 10 zahtev vrnjenih (z osmim bitom odtrganim) in odneha.
Obstajata dve rešitvi:
Dodajte lcp-max-configure 30 vašim ppp možnostim. To poveča največje
število lcp konfiguracijskih paketov, ki jih pppd pošlje preden odneha. Za
res počasen strežnik jih boste morda potrebovali še več.
Lahko pa ste prebrisani tudi vi! Mogoče ste opazili, da ko se prijavite na
PPP strežnik in poženete PPP, je prvi znak od ppp smetja vedno tilda
(~).
Z uporabo tega podatka lahko dodamo nov pričakuj/pošlji par na
konec chat skripte, ki bo pričakoval tildo ali kaj podobnega. To bi
izgledalo takole:
\~ ''
Opomba: ker ima tilda v ukazni lupini poseben pomen, ji moramo dodati ubežni znak (leva poševnica)
Če pppd noče nastaviti privzete poti, je to zato, ker (dokaj pravilno) noče odstraniti oz. zamenjati že obstoječe privzete omrežne poti.
Običajni razlog za to napako je, da v nekaterih distribucijah privzeta pot kaže na Ethernet kartico namesto da bi bila to specifična omrežna pot.
Glejte Linux NAG (Network Administrators Guide) in NET2/3 HOWTO-je za informacije o pravilni nastavitvi Ethernet kartice in pripadajočih poti.
Možno je tudi, da vaša mreža že uporablja ,vozel` (gateway) ali usmerjevalnik in je vaša usmerjevalna tabela nastavljena, da kaže privzeta pot na to.
Urejanje te situacije zahteva kar precej znanja o IP omrežjih in presega namen tega HOWTO-ja. Priporočljivo je, da dobite nekaj strokovnih nasvetov (v novičarskih skupinah ali če koga poznate).
Poleg naštetih je še precej drugih razlogov, da se ppp ne poveže oz. deluje pravilno.
Poglejte v PPP-FAQ (ki je niz vprašanj in odgovorov). To je zelo obširen dokument, in odgovori SO v njem! Iz mojih (žalostnih) izkušenj lahko povem, da če odgovora ni tam, težava ni na strani PPP-ja! V mojem primeru sem uporabljal ELF jedro, programja za module pa nisem nadgradil. Zapravil sem samo 2 dni (in skoraj celo noč) preklinjajoč tisto, kar je bil predtem odličen PPP strežnik!