Skåne Sjælland Linux User Group - http://www.sslug.dk Forside   Tilmelding   Postarkiv   Oversigt   Kalender   Søg
 

Lidt tips og information om PPP og internetopkobling

Denne side skulle gerne give lidt bedre forståelse for hvordan PPP virker med linux, og give nogle tips til at komme udover diverse mangler i diverse ppp-opsætningsprogrammer som:   netcfg, suseppp, kppp,....

Siden omhandler lidt grundlæggende om PPP og chatscripts, så man får lidt forståelse for hvad disse ppp-opsætningsprogrammer laver. Specielt når de ikke virker, så kan det være rart at vide hvad der muligvis går galt.

Der er også vist init-strenge for de eksterne ISDN TA'erne Eicon Diva og Zyxel Omninet+. Desuden lidt info om problemer med Lasat 1280i, der har en lidt uheldig implementering af PPP protokollen.

Til ekspempler på anvendelse af diverse ppp opsætningsprogrammer henvises til internet.html og de links der er på denne side.

De hyppigste fejl i opsætningen af PPP er følgende:

Har man et internt ISDN kort, så er det mere specielt kort, og opfører sig ikke helt som et modem, og man skal hellere se på :

Indholdsfortegnelse:

top Først lidt grundlæggende om PPP

Når PPP skal starters så er det programet pppd der startes og som klarer en del af håndteringen af PPP protkollen. Pppd står for   "Point to Point Protocol daemon". Se også den tilhørende manualside med man pppd.

Ofte kan pppd ikke startes direkte, da der først skal etableres forbindelse over et modem eller en ISDN TA (ekstern boks). Til at initialisere modemet og etablere forbindelsen anvendes programmet chat. Dette program har også en manualside, se man chat

Chat programmet skal have et såkaldt "chatscript" som sørger for at sende passende AT kommandoer til modemet og så modemet ringer op. Hvis ens internetudbyder (ISP) ikke anvender immediate PPP (direkte start af PPP) og PAP-login, men kræver tekstlogin, så skal der reageres på en login/password konversation inden ppp forbindelsen kan etableres.

Når alt er klar til PPP protokollen så overtager pppd igen og klarer en eventuel PAP login og selve PPP.

Det suseppp, netcfg, kppp mv. gør, et at hjælpe med at lave de forskellige konfigurationsfiler. Nogen gange går det godt, men andre gange lykkes det ikke helt. Specielt har visse af disse programmer begrænsninger/problemer med direkte PAP-login.

top Eksempler på chatscript

Programmet kan kaldes på forskellige måder. Den ene måede er ved at kalde programmet med en fil der indeholder chatscriptet, og den anden ved at angive kommandoerne direkte på kommandolinien.

top Alle chat kommandoer i kommandolinien til chat:

PHONE=12345678
chat -v -r /var/log/ppp-chat.log \
REPORT CONNECT \
REPORT OK \
REPORT BUSY \
REPORT 'NO CARRIER' \
REPORT 'NO DIALTONE' \
TIMEOUT 5 \
'' 'ATZ' \
OK ATDT$PHONE \
ABORT 'NO CARRIER' \
ABORT 'BUSY' \
ABORT 'NO DIALTONE' \
ABORT 'WAITING' \
TIMEOUT 50 \
CONNECT  

Ovenstående virker med de fleste modemer og til de fleste større internetudbydere. DOG skal man selv finde en bedre modeminitialiseringsstreng end ATZ (se senere).

Vær opmærksom på at alle linier skal efterfølges af "\" da kommandoerne tilføjes kommandolinien til chat.

Den første timeout er sat til 5 sekunder, idet modemet normalt bør svare tilbage på disse kommandoer inden 5 sekunder. Når der ringes op (med ATDT) så kan der gå ganske længe inden der er forbindelse, så her er TIMEOUT sat til 50 sekunder.

Da internetudbyderen i dette eksempel anvender immediate PPP og PAP login, så skal chatsriptet afslutte med CONNECT, så derfor slutter det her. Der må ikke følge noget efter denne CONNECT, idet denne efterfølgende streng så også sendes til modemet, inklusive et linieskift ^M, og det selvom det er en tom streng "" elle ''. Hvis der sendes noget efter denne CONNECT så kan der enten ske det at PPP protokollen der er startet i den anden ende ophører, eller at man får en "tekst-login".

Dog i ovenståene "kommandolonieudgave" kan man være heldigt at de tomme strenge ikke anvendes af chat og at det så også virker med immediate PPP.

top Chatscriptet som fil

Denne ligner det forgående eksempel, blot er chat-kommandoerne lagt i en fil, og programmet kaldes med chat -f chatfil. Derudover er chatscript udvidet med tekstlogin for at vise hvordan dette foregår:

'ABORT' 'BUSY'
'ABORT' 'ERROR'
'ABORT' 'NO CARRIER'
'ABORT' 'NO DIALTONE'
'ABORT' 'Invalid Login'
'ABORT' 'Login incorrect'
'TIMEOUT' '5'
'' 'ATZ'
'TIMEOUT' '50'
'OK' 'ATDTnnnnnnn'
'CONNECT' ''
'ogin:' 'mit-brugernavn'
'ord:' 'mit-password'
'TIMEOUT' '5'
'~--' ''

I ovenstående får man ved opkaldet en "Login:" prompt og forventes at indtaste login og password. Hos nogle internetudbydere er det "user:" man skal vente på inden der sendes brugernavn, så her må scriptet tilrettes den aktuelle internetudbyder. Dog i Danmark anvender de fleste større internetudbydere (bla.: inet.tele.dk, get2net, og cybercity) immediate PPP, så det skulle være nok at sidste linie kun er CONNECT, men tekst-login skulle også virke, det er dog unødvendigt at anvende.

top Eksterne ISDN TA'ere

Eksterne ISDN TA'ere (af nogle lidt fejlagtigt kaldt ISDN modem) opfører sig normalt som et modem, idet der anvendes AT kommandoer til initialisering og opringning. Til ISDN anvendes dog ofte en specielle AT kommandoer, da ISDN TA'en ofte selv har en PPP protokol delvist indbygget. Så chatscriptet vil i så fald kommunikere med ISDN TA'en og ikke internetudbyderen, idet det er ISDN TA'en der varetager kommunikation med internetudbyderen:

           [serialkabel]                [ISDN forbindelse]
PC (pppd) -------------- ISDN TA (ppp) ------------------- Internetudbyder(pppd)

Denne måde at forbinde på, betyder at der kan være visse begrængsninger på PC'ens side. F.eks. med Zyxel Omninet er man begrænset til kun at kunne anvende PAP og ikke CHAP mellem PC og ISDN TA. Dog hvis nødvendigt/muligt så sørger Zyxel Omninet selv for at konvertere fra PAP til CHAP i den videre forbindelse til internetudbyderen.

Man bør læse den medfølgende manual til ISDN TA'en idet der bl.a. skal anvendes initstrenge til at få PPP til at virke. Til Zyxel Omninet+ er der følgende:

Og chatscriptet kommer så til at se ud som:

REPORT CONNECT \
REPORT OK \
REPORT BUSY \
REPORT ERROR \
REPORT 'NO CARRIER' \
REPORT 'NO DIALTONE' \
TIMEOUT 8 \
'' 'ATZ0' \
OK 'AT&K44' \
OK 'ATB40' \
OK ATDInnnnnnnn \
ABORT 'NO CARRIER' \
ABORT 'BUSY' \
ABORT 'NO DIALTONE' \
ABORT 'WAITING' \
TIMEOUT 25 \
CONNECT  

top Modem initstrenge

De viste init-strenge giver kun en korrekt initialisering af modemet hvis man har lavet en brugbar brugerprofil i modemet. USR anbefaler ofte AT&F1 til deres modems (reset factory default 1), men se i manualen til modemet for en anbefalet initstreng. Der skal bla. anvendes hardware-handshake (ikke Xon/Xoff), og "Normal Carrier Detect operation", dette kan ofte gøres f.eks. med: AT&C1&H1&I0. Dette virker muligvis ikke med alle modemer.

top Eicon Diva initstrenge

Udfra det jeg kunne læse af manualen (pdf-filen), er jeg kommet frem til følgende initialieringer som ser ud til at virke.


Links til mere om Eicon Diva:

top Lasat Speed II, Lasat 1280i A/B ISDN TA og andre

Lasat Speed II, med flg. initstreng: AT&F&D&B2%B7,
dette skulle virke til de fleste ppp opsætningsprogrammer, dog ikke dialup fra gnome. Se i emailarkivet for mere.

Ved problemer, så sørg for at få opdateret til nyeste pakker med ppp og initscripts, specielt ældre linux distributioner kan stadig anvende for gamle versioner. Se mere om RH6.1 og Lasat.

Lasat kan vist ikke opgradere firmware fra linux, så her skal man gøre det under Windows hvis man overhovedet har dette insrtalleret. Med andre mærker f.eks. Zyxel, kan det ske med xmodem protokollen som findes til linux.

En vejledning for Lasat II PnP ISDN modem (USB!)

Gammel model af Lasat (1280*) + gammel firmware

Dette afsnit er muligvis kun til glæde af dem med gamle modeller

Efter sigende skulle denne ISDN TA kun være testet under windows, så ppp-protokollen ikke virker helt med linux som har noget optimering af protokollen. Denne optimering kan slås fra i linuxkernen i ppp.c. Se også i mailarkivet til sslug-ppp. og hos Lasat : This FAQ is relevant for users of following systems: Linux Redhat 5.0, Linux Redhat 5.1, Linux RedHat 6.0

   Edit this file by finding the following line (ppp.c):

   #define OPTIMIZE_FLAG_TIME  ((HZ * 3)/2)

   This should be modified to:
   #define OPTIMIZE_FLAG_TIME      (0)

I øvrigt hedder filer ppp_async.c i kerne 2.4.x

Løsningen med ændring af ppp.c i 2.2.x måske unødvendig (og i 2.4), da OPTIMIZE_FLAG_TIME kun er en initiel værdi til "flag_time" som burde kunne ændres på load tidspunkt af modulet.

Så en (utestet) metode til 2.2 og 2.4 kerner er at tilføje til /etc/modules.conf:

options ppp flag_time=0

En init-streng til Lasat 1280i ser ud til at være :

eller forsøg med:

Tilføj føljende for at få hhv 1 eller 2 kanaler:

Ved at tilføje %B7 burde 2 kanaler være muligt også med Tele Danmark Internet. Men øjensynlig virker det ikke for godt.

top Zyxel Omninet+ og 2864I

Man kan kave en brugerprofil i stil med divaen med følgende i minicom:

AT&F              <-- full-reset, to factory defaults
AT&C1&H3          <-- hardware handshake CTS/RTS, er default? (dvs. overflødigt)
ATX5              <-- lidt mere CONNECT info/resultcodes, forsøg evt. med ATX7
ATB40                 <-- Vælg PPP protokol
AT&K44            <-- Vælg hardware komprimering (for PPP stac ellers V42)
AT&W0             <-- gem i brugerprofil "0", og gør denne profil
                      som standard ved power-on.
ATZ0  	          <-- og så en restart af modemet. (*)

Er der problemer med hardware-Stac med den internetudbyder man anvender, så erstattes AT&K44 med AT&K0, hvilket frakobler hardware komprimering.

(*) Desværre har Zyxel Omninet+ en mindre fejl i ATZn kommandoerne, så at visnummer i minicom med ATQP3 og udgående log ATQP2 devist slettes med ATZn. Kun en tænd/sluk af Omninet+ hjælper. Jeg er derfor gået over til at slet ikke have noget specielt initialisering i chatscriptet, men i stedet anvender den ønskede hardwareprofil som standard ved power-on reset. I minicom kan man checke hvilken brugerprofil der anvendes ved power-on med:

ATS15?

Normal returnes 2 hvis brugerprofil "0" anvendes, (og 34 for "1", 68 for "2", 96 for "3" og 132 for "factory default".

Se også afsnittet om eksterne ISDN TA.

top Modem med Rockwell chipsæt (analog modem, V34,V34+,K56,V90,..)

Mange billige "NoName" modem har et Rockwell chipsæt, og ofte de samme AT kommandoer. Ofte medfølger der ingen (eller kun en forenklet) manual. Derved er det svært at finjustere så man får den bedst mulige og stabile forbindelse til sin internetudbyder.

Jørgen Lorentsen har lavet følgende tips til opsætning af disse modem. Se også mailarkivet i sslug-misc og sslug-ppp: msg00331 i sslug-misc (juli 1999),   msg00337 i sslug-misc (juli 1999)   og msg00000 i sslug-ppp (juli 1999)

Her er et udklip fra Image support:
**********************************************************
Man kan risikere at komme ud for at ens modem kører for 
hurtigt i forhold til hvad den analoge telefonlinje kan 
klare. Dette vil resultere i at modemet undervejs
genforhandler hastighed. I de 10-15 sekunder, 
genforhandlingen finder sted, kan der ikke overføres 
andet data på linjen. Dette vil føles som huller i
datastrømmen. Senere vil man så kunne risikere at modemet 
igen kører op i hastighed, for igen at løbe ind i problemer...
**********************************************************
Og tak til Image for den oplysning...

Men hvordan stiller man så de der hastigheder?

Man kan styre det med initialiseringsstrengen på følgende måde:

  
      AT+MS=<mode>,<automode>,<min_rate>,<max_rate>

Hvor:

I K56flex kan man (på mit modem) stille følgende rates:
56K,54K,52K,50K,48K,46K,44K,42K,40K,38K,36K,34K og 32K

Hvordan finder man så den korrekte max. rate?
En god ide er at pinge een eller anden hurtigt host (f.eks. den som kører DNS). Lad være med at bruge opkoblingen til andet.
Hvis din <max_rate> ikke er for stor, vil responstiden for en pingpakke være næsten konstant. Stiller du <max_rate> for stor, vil svartiden variere.

F.eks. ses her svartider ved <max_rate>=46K:
F.eks. ses her svartider ved <max_rate>=46K:

PING 212.54.64.170 (212.54.64.170): 56 data bytes
64 bytes from 212.54.64.170: icmp_seq=0 ttl=62 time=107.5 ms
64 bytes from 212.54.64.170: icmp_seq=1 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=2 ttl=62 time=110.1 ms
64 bytes from 212.54.64.170: icmp_seq=3 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=4 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=5 ttl=62 time=110.1 ms
64 bytes from 212.54.64.170: icmp_seq=6 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=7 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=8 ttl=62 time=110.1 ms
64 bytes from 212.54.64.170: icmp_seq=9 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=10 ttl=62 time=110.0 ms

Det er rimeligt konstant. Skruer vi så hastigheden op til <max_rate>=48K fås følgende tider:

PING 212.54.64.170 (212.54.64.170): 56 data bytes
64 bytes from 212.54.64.170: icmp_seq=0 ttl=62 time=116.9 ms
64 bytes from 212.54.64.170: icmp_seq=1 ttl=62 time=109.9 ms
64 bytes from 212.54.64.170: icmp_seq=2 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=3 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=4 ttl=62 time=559.9 ms
64 bytes from 212.54.64.170: icmp_seq=5 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=6 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=7 ttl=62 time=109.9 ms
64 bytes from 212.54.64.170: icmp_seq=8 ttl=62 time=1170.0 ms
64 bytes from 212.54.64.170: icmp_seq=9 ttl=62 time=180.0 ms
64 bytes from 212.54.64.170: icmp_seq=9 ttl=62 time=180.0 ms
64 bytes from 212.54.64.170: icmp_seq=10 ttl=62 time=720.0 ms
64 bytes from 212.54.64.170: icmp_seq=11 ttl=62 time=110.0 ms
64 bytes from 212.54.64.170: icmp_seq=12 ttl=62 time=110.0 ms

Her ses varierende svartider. Svarende til at modemet een gang imellem forsøger at overskride telefon linjens grænse.
Så jeg har følgende chatscript:

ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
ABORT "Invalid Login"
ABORT "Login incorrect"
TIMEOUT 5
"" AT&F&C1S9=15
TIMEOUT 50
OK "AT+MS=56,1,32000,46000"
OK "ATDT104938833883"
CONNECT ""

Det virker som en drøm. Jeg håber der er nogen, som kan bruge mit råd.

Med venlig hilsen
-Jørgen Lorentsen

NB.Vær opmærksom på at diverse ppp-konfigurationsværktøjer (f.eks. netcfg i RH) vil overskrive eventuelle manuelle rettelser i /etc/sysconfig/network-scripts/chat-ppp0 næste gang netcfg kaldes.

Links:

top USR Courier/Sportster mv. (nu 3Com)

Normalt så vil AT&F1 kunne anvendes til initialisering.

Ønskes V42b komprimering og samtidig ingen MNP5 så kan AT&K3 anvendes.

Som til "Rockwell" modem, så er der kommandoer til at begrænse/sætte hastigheden på forbindelsen til internet udbyderen. Der anvendes AT&Nn til at sætte en fast maksimum hastighed. og AT&Un til minimum hastighed.
n er i USR Courier/Sportster:

  0:Variable  6:  9600   13: 26400   20: 42666   27: 52000
      rate    7: 12000   14: 28800   21: 44000   28: 53333
  1:   300    8: 14400   15: 31200   22: 45333   29: 54666
  2:  1200    9: 16800   16: 33600   23: 46666   30: 56000
  3:  2400   10: 19200   17: 37330   24: 48000   31: 57333
  4:  4800   11: 21600   18: 41333   25: 49333
  5:  7200   12: 24000   19: 42666   26: 50666

For at finde en egnet hastighed, så prøv i minicom at kalde op med ATX5DTnnnnnnnn. fås f.eks. en CONNECT 52000, så prøv at begrænse til 50666 bps med AT&U13&N25 (sætter minumum 26400 bps)

Som for Rockwell chipsæt, kan svartiden på ping anvendes til under PPP forbindelsen at checke om maksimum hastigheden er ok, ellers må der vælges en mindre værdi.

Links til 3com/USR. Check evt. om der er kommet opdateret firmware (specielt de modem der har med flash-rom).

top Hardware komprimering af data i modem eller ISDN TA

Dem der husker de gamle 300-2400 bps modem, vil vide at man let kunne få transmissionfejl. Derfor blev der tilføjet mulighed for at bruge en protokol der automatisk forsøger at retransmitere fejlbehæftede datablokke. En af disse protkoller var MNP . En anden blev lavet som tele standard af ITU (ITU hed tidligere CCIT), og protokollen kaldtes V42.

Mange datatyper som html og tekst kan komprimeres, prøv f.eks. med gzip eller tilsvarende. Derfor har man tilføjet hardware komprimering i selve modemet. Disse komprimeringsalgoritmer er ikke så effektive som gzip, men betydeligt hurtigere, og ofte tilpasset den type datatrafik der er over modemet.

Der blev lavet komprimering til MNP kaldet MNP5, og ITU tilføjede også komprimering til V42, og denne protokol blev så kaldt V42b.

Generelt er V42b bedre end MNP5, og MNP5 bør ikke anvendes på filer der er komprimerede, da MNP5 vil øge den samlede mængde data der transmiteres.

Fælles for disse protoller med og ude komprimering, er at de er beregnet for analoge modemer. V42b er idag den mest benyttede protokol. Visse modems har dog mulighed for at anvende enten MNP5 eller V42b, afhængig af opsætningen.

Man bør checke med manualen til sit modem for at vide hvilken AT kommando der tilkobler V42b. Det kan være lidt forskelligt for de forskellige producenter og modeller af modem.

Software komprimering er tilføjet PPP protokollen. Der er overflødigt at anvende det i hardware (MNP5 eller V42b) sammen med software komprimering. Til linux anvendes ofte frie/åbne standarder som f.eks. deflate eller bsdcomp. Desværre er der stort set ingen større internetudbydere der tilbyder disse. De tilbyder alle StackerLZS (Stac), da den er implementeret i den hardware de anskaffer til deres modempuljer. Og rigtigt gættet ; Windows har mulighed for software komprimering i PPP der virker med dette.
Eicon Diva har f.eks. i hardware mulighed for at anvende en af følgende: Stacker LZS, MPPC (Microsoft), og Ascend .

ISDN TA: Disse anvender en digital forbindelse, hvor de transmiterede data ikke har samme problemer som et analog modem. ISDN TA'ere har ofte indbygget PPP protokol. Er man så uheldig at have en gammel ISDN TA uden PPP infbygget, så kan man prøve med X75, V120 eller V110 protokol. Disse protokoller vil virke som en almindelig "modem" forbindelse til den modsatte ende, dog over en digital protokol (dvs. man kan ikke forbinde til et analogt modem). Ofte anvendes V120 af internetudbyderne, men ikke alle giver brugerne denne mulighed. Med X75 og V120 er der mulighed for at anvende V42b komprimering. Med PPP protokollen tilbydes gerne LZ-Stac (også kaldet MS-Stac).

Da PPP protkollen i ISDN TA'er er delvist indbygget, så har man lavet det sådan at hardware komprimering kun bliver slået til hvis clienten (på PC'en) ikke selv starter forhandling af komprimering. Derfor skal man huske at slå dette fra med relevante kommandoer i /etc/ppp/options :

  novj
  noccp
  nobsdcomp 
  noaccomp 
  nodeflate 
  nopcomp 
  novjccomp  

Software komprimering kan dog anvendes med linux hvis man kobler op til en anden linux/*bsd/unix box med disse PPP komprimeringsalgoritmer slået til.

top Fejlfinding af chatscript

Normal vil der i en eller flere logfiler under /var/log/ være en log af chatscriptet, så man kan se hvad der evt. gik galt. I redhat er det normalt /var/log/messages.

Man kan yderligere tilføje ekstra log til chatscriptet ved at tilføje "-v" og/eller "-r logfil" til chat kommandoen. Se manualside til chat for mere om dette

top Options til PPP mv.

Pppd kan kaldes på lidt forskellige måder idet kommandolinie parametrene også kan angives i /etc/ppp/options. Normalt er filen velkommenteret, og ellers bør man se på manualsiden til pppd. Fjerner man disse kommentarerer, så behøver der ikke være særligt meget i denne fil. Jeg har dog ofte:

# anvende hardware handshake på serielporten
# husk at fortælle modemet dette
crtscts   

# har man glemt at anvende hardwarehandshake, men anvender det langsommere
# Xon/Xoff, så skal følgende være asyncmap a0000 :
asyncmap 0

lock    # sikrer at kun et program ad gangen anvender serielport
modem   # brug modem styresignalerne i serielkablet (CarrierDetect mv.)

# tilføj ppp forbindelsen som gateway/route til internet
# da det er normalt det man ønsker :
defaultroute 

For at lave PAP (Password Authentication Protocol) skal filen /etc/ppp/pap-secrets findes og må kun være læsbar af root. Den kan indholde login/passwords til flere systemer, idet man med user option på pppd-kaldet kan specificere hvilken bruger der skal anvendes.

# user        server          secret          addrs
#-----------------------------------------------------
frank          *             mitpassword
NNNNNN         *             mitpassword2

Der findes også CHAP (Challenge Handshake Authentication Protocol) som kan anvendes til en del internetudbydere, og i så fald skal /etc/ppp/chap-secrets oprettes. Filen ligner pap-secrets.

top Fejlfinding af PPP

I de samme logfiler som til chatscriptet i /var/log/ kan man også finde en log af selve PPP protkollen. Den er dog lidt mere kryptisk end til chatscriptet. Ved at tilføje et eller flere -d til pppd kommandolinien, eller debug til /etc/ppp/options fås en mere udførlig log.

top Script eksempler

Det er nogle ekspempler på de scripts der skal anvendes for at få en PPP forbindelse. Diverse ppp-opsætningsprogrammer genererer diverse ppp-opsætningsfiler og kalder efterfølgende pppd på en lignende måde for at etablere en PPP forbindelse.

Når jeg selv laver ppp-on scriptet der kalder pppd kan det se ud som følgende:

#!/bin/sh
DEVICEOUT=/dev/ttyS1
# brugernavn:
PPPUSER=XXXXXXXXXXX
SPEED=115200
DIALERSCRIPT=/etc/ppp/chatscript
pppd $DEVICEOUT $SPEED connect $DIALERSCRIPT user $PPPUSER 

Det tilhørende chatscript med eksempel på anvendelse af ekstra log's og report-log:

#!/bin/sh
PHONE=12345678
exec chat -v -r /var/log/ppp-chat.log \
REPORT CONNECT \
REPORT OK \
REPORT BUSY \
REPORT 'NO CARRIER' \
REPORT 'NO DIALTONE' \
TIMEOUT 5 \
'' 'ATZ' \
OK ATDT$PHONE \
ABORT 'NO CARRIER' \
ABORT 'BUSY' \
ABORT 'NO DIALTONE' \
ABORT 'WAITING' \
TIMEOUT 50 \
CONNECT  

Et ppp-off script til at afbryde forbindelse kunne se ud som følgende:

#!/bin/bash
DEVICE=ppp0
# If the ppp0 pid file is present then the program is running. Stop it.
if [ -r /var/run/$DEVICE.pid ]; then
        kill -INT `cat /var/run/$DEVICE.pid`
        # If unsuccessful, ensure that the pid file is removed.
        if [ ! "$?" = "0" ]; then
                echo "removing stale $DEVICE pid file."
                rm -f /var/run/$DEVICE.pid
                exit 1
        fi
        # Success. Terminate with proper status.
        echo "$DEVICE link terminated"
        exit 0
fi
# The link is not active
echo "$DEVICE link is not active"
exit 1

top Nogle tips til at fejlfinde andre dele af internetforbindelsen

Udover PPP protkollen, så skal andre dele af netværsksopæstning også initialiseres på passende hvis.

top Nogle tips til SuSE / suseppp

Det ser ud til at chat-script laver en standard fejl, og sørger for altid at sende et ektra ^M efter modtagelse af CONNECT. Detter er specielt irriterende hvis man vil have en ren PAP-login.

Har man via YaST og suseppp valgt "generic" chatscript, så vil der være blevet lavet en fil /etc/suseppp/generic.chat:

TIMEOUT 60
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT ERROR
"" +++ATZ
OK ATDT103333361333
CONNECT ""

Fjern "" i sidste linie, så det kun står CONNECT Så virker suseppp med PAP. Efterfølgende ændringer/kald af suseppp opsætningen fra YaST skulle ikke ændre scriptet.

I SuSE 6.1 evaluation har der ikke været plads til SuSEPPP, så måske de har rettet dette.

top Redhat / netcfg

Her anvendes /etc/sysconfig/network-scripts/chat-ppp0. Før man forsøger at anvende PAP, så husk at vælge dette i netcfg. Hvis chatscriptet alligevel ikke gør det ønskede mht. CONNECT, så tilret filen /etc/sysconfig/network-scripts/chat-ppp0. Vær opmærksom på at netcfg selv overskriver scriptet næste gang det kaldes, så derfor skal det tilrettes hver gang man har ændret ppp-opsætningen med netcfg. Prøv evt. også at anvende linuxconf.

top KDE's kppp

I denne skal man fjerne lock fra /etc/ppp/options idet kppp påstår selv at kunne finde ud af at låse serielporten for andre programmer. Har dog ikke testet om det er sandt, men i hvert fald fungerer kppp ikke med lock.

Dernæst skal man huske at tilføje "noauth" i en af kppp's menuer: "Rediger PPP parametre"

En mere udførlig vejledning til kppp kan findes på:

topAndre tips

Prøv også at se på /usr/src/linux/Documentation/networking/ip_dynaddr.txt. Dette er specielt relevant ved anvendelse af diald eller ved diald-on-demand i 2.2 kerner. Selv har jeg i passende sted ved opstart af linux:

    if [ -f /proc/sys/net/ipv4/ip_dynaddr ]; then
       echo "3" >/proc/sys/net/ipv4/ip_dynaddr
    fi
top Andre links:
 
Forside   Tilmelding   Postarkiv   Oversigt   Kalender   Søg

 
 
Henvendelse vedrørende websiderne til <www_admin>. Senest ændret 2004-03-07, klokken 21:25
Denne side vedligeholdes af Frank Damgaard .