DOKK / manpages / debian 10 / manpages-pl / pppd.8.pl
PPPD(8) System Manager's Manual PPPD(8)

pppd - Demon protokołu PPP

pppd [ nazwa_tty ] [ szybkość ] [ opcje ]

Uwaga! To tłumaczenie może być nieaktualne!

Protokół Point-to-Point (PPP) daje metody transmisji datagramów poprzez szeregowe połączenia punkt-do-punktu. PPP składa się z trzech części: sposobu enkapsułowania datagramów w połączeniach szeregowych, rozwiniętego protokołu kontroli połączenia (LCP--Link Control Protocol) oraz rodziny protokołów kontroli sieciowej (NCP--Network Control Protocols) służących do zestawiania i konfigurowania różnych protokołów warstwy sieciowej.

Schemat enkapsułowania jest dawany przez kod sterownika w jądrze. Pppd daje podstawowe LCP, wsparcie uwierzytelniania i NCP do zestawiania i konfigurowania IP (nazywa się on IPCP-IP Control Protocol).

<nazwa_tty>
Komunikuj się poprzez wskazane urządzenie. Jeśli potrzeba, doklejany jest tu łańcuch "/dev/". Jeśli nie zostanie podana nazwa urządzenia, lub jeśli podana jest nazwa terminala podłączonego do standardowego wejścia, pppd użyje tego terminala i nie fork(2)nie by wstawić się w tło. Wartość tej opcji ustawiona w uprzywilejowanym źródle nie może być przeciążona przez nieuprzywilejowanego użytkownika.
<szybkość>
Ustaw szybkość przesyłu na <szybkość> (liczba dziesiętna). Na systemach takich, jak 4.4BSD czy NETBSD można podać dowolną szybkość. Inne systemy (np. SunOS) dopuszczają tylko ograniczony zbiór szybkości.
Ustaw mapę znaków async na <mapa>. Mapa ta opisuje, które znaki sterujace nie mogą być pomyślnie przesyłane poprzez linię szeregową. Pppd będzie prosił peera o przesyłanie tych znaków jako dwubajtowe sekwencje specjalne. Argument jest 32 bitową liczbą szesnastkową, gdzie każdy bit określa znak, który należy cytować. Bit 0 (00000001) określa znak 0x00; bit 31 (80000000) określa znak 0x1f lub ^_. Jeśli podanych jest wiele opcji asyncmap, to wartości są sklejane logicznym OR. Jeśli nie podane są żadne opcje asyncmap, znaki te w ogóle nie będą negocjowane w kierunku odbiorczym. Peer powinien wtedy cytować wszystkie znaki sterujące. Aby cytować przesyłane znaki, użyj opcji escape.
Żądaj od peera uwierzytelnienia przed zezwoleniem na przesyłanie pakietów sieciowych. Opcja ta jest domyślna, jeśli system ma trasę domyślną. jeśli nie podano ani tej opcji, ani noauth, pppd pozwoli jedynie używać peerowi adresów do których system nie ma jeszcze trasy.
Odczytaj opcje z pliku /etc/ppp/peers/nazwa. Plik ten może zawierać uprzywilejowane opcje, takie jak noauth, nawet jeśli pppd nie jest uruchamiane przez roota. Łańcuch nazwa nie może rozpoczynać się od /, ani zawierać znaków .. jako część ścieżki. Format pliku z opcjami jest opisany niżej.
Użyj programu wykonywalnego, podanego przez skrypt do skonfigurowania linii szeregowej. Skrypt ten zwykle wykorzystuje program chat(8) do wykręcenia numeru telefonu i rozpoczęcia zdalnej sesji ppp. Wartość tej opcji ze źródła uprzywilejowanego nie może być przesłonięta przez nieuprzywilejowanego użytkownika.
Używaj sprzętowego sterowania przepływem (tj. RTS/CTS) do sterowania przepływem danych na porcie szeregowym. Jeśli nie zostanie podana ani opcja crtscts, ani nocrtscts czy cdtrcts lub nocdtrcts, ustawienie sprzętowego sterowania przepływem portu pozostaje niezmienione. Niektóre porty szeregowe (np. Maca) nie posiadają prawdziwego wyjścia RTS. Porty takie używają tego trybu do implementacji jednokierunkowego sterowania przepływem. Port szeregowy zawiesi transmisję jeśli zażąda tego modem (przez CTS), lecz nie będzie w stanie zażądać od modemu zaprzestania nadawania danych do komputera. Tryb ten zachowuje możliwość używania DTR jako linii kontroli modemu.
Dodaj domyślną trasę do systemowych tablic trasowania, używając peera jako bramkę po pomyślnym zakończeniu negocjacji IPCP. Wpis ten [w tablicach routingu] jest usuwany po zerwaniu połączenia. Opcja ta jest uprzywilejowana w przypadku podania opcji nodefaultroute.
Wykonaj program skrypt po zakończeniu połączenia ppp. Skrypt ten może na przykład wysłać komendy, powodujące odwieszenie modemu gdy niedostępne są sprzętowe sygnały sterowania modemem. Skrypt rozłączenia nie jest uruchamiany jeśli modem już jest odwieszony. Wartość tej opcji pochodząca z uprzywilejowanego źródła nie może być przesłonięta przez nieuprzywilejowanego użytkownika.
Określa, że niektóre znaki powinny być podczas transmisji cytowane (niezależnie czy peer chciał by tak było w swojej mapie async). Cytowane znaki są podawane jako lista liczb szesnastkowych, rozdzielonych przecinkami. Zauważ, że prawie każdy znak można podać w tej opcji. Jest to odwrotnie niż w opcji asyncmap, gdzie można było podać jedynie znaki sterujące. Znaki, których nie można cytować to znaki o wartościach szesnastkowych 0x20 - 0x3f lub 0x5e.
Odczytaj opcje z pliku nazwa (format jest opisany niżej). Plik ten musi być dostępny dla odczytu dla użytkownka, który uruchomił pppd.
Uruchom program wykonywalny skrypt do zainicjalizowania linii szeregowej. Skrypt ten zazwyczaj używa programu chat(8) do skonfigurowania modemu celem włączenia autoodpowiadania. Wartość tej opcji, pochodząca z uprzywilejowanego źródła nie może być przesłonięta przez nieuprzywilejowanego użytkownika.
Podaje, że pppd powinien stworzy plik blokujący w stylu UUCP, aby zapewnić ekskluzywność dostępu do urządzenia szeregowego.
Ustaw MRU [Maximum Receive Unit] na n. Pppd poprosi peera o przesyłanie pakietów nie większych niż n bajtów. Minimalną wartością MRU jest 128. Domyślną jest 1500. Zalecana dla wolnych linii jest wartość 296 (40 bajtów na nagłówek TCP/IP + 256 bajtów danych). (Zauważ, że w IPv6 MRU musi być min. 1280).
Ustaw MTU [Maximum Transmit Unit] na n. O ile peer nie zażąda mniejszej wartości poprzez MRU, pppd zażąda by kod sieciowy jądra wysyłał pakiety nie większe niż n bajtów. (Zauważ, że w IPv6 MTU musi być min. 1280).
Włącza opcję pasywności LCP. Przy podaniu tej opcji, pppd spróbuje zapoczątkować połączenie; jeśli nie uzyska odpowiedzi od peera, to będzie czekać pasywnie na prawidłowy pakiet LCP, zamiast kończyć działanie, jak to ma miejsce w normalnej sytuacji.

<lokalny_adres_IP>:<zdalny_adres_IP>
Ustaw lokalny i/lub zdalny adres IP interfejsu. Dowolny z nich można pominąć. Adres IP może być podawany jako nazwa hosta, lub w dziesiętnej notacji kropkowej (np. 150.234.56.78). Domyślnym adresem lokalnym jest (pierwszy) adres IP systemu (o ile nie podano opcji noipdefault). Zdalny adres (w wypadku niepodania) jest pobierany od peera. W ten sposób, w prostych przypadkach opcja ta nie jest wymagana. Jeśli lokalny i/lub zdalny adres IP został jednak w tej opcji podany, pppd nie przyjmie innej wartości od peera w negocjacji IPCP, chyba że podano opcje ipcp-accept-local i/lub ipcp-accept-remote.
Ustaw 64-bitowy identyfikator lokalnego i lub zdalnego interfejsu. Dowolny z nich można pominąć. Identyfikator musi być podany w standardowej noracji ascii adresów IPv6 (np: ::dead:beef). Jeśli podana jest opcja ipv6cp-use-ipaddr, lokalnym identyfikatorem jest lokalny adres IPv4 (patrz wyżej). Na systemach, obsługujących unikalne stałe ID, można w zamianie do opisywanej opcji użyć opcji ipv6cp-use-persistent. W przeciwnym wypadku, identyfikator jest losowany.
Określa filtr pakietowy, stosowany do pakietów z danymi w celu określenia, które pakietu uznać za aktywność linii, a zatem kiedy kasować licznik bezczynności lub prowadzić połączenie w stan wymagający telefonowania. Opcja ta jest przydatna w połączeniu z opcją idle jeśli przez połączenie przesyłane są regularnie jakieś pakiety (np. pakiety informacji o trasach), które normalnie uniemożliwiają wejście w stan bezczynności. Składnia wyrażenia-filtru jest taka, jak dla tcpdump(1), lecz kwalifikatory nie mające sensu w połączeniu PPP, takie jak ether czy arp nie są dozwolone. Ogólnie, wyrażenie filtru powinno być ujęte w pojedyncze cytaty, aby uchronić je przed interpretacją spacji przez powłokę. Opcja ta jest obecnie dostępna tylko pod NetBSD i to tylko wtedy, gdy jądro i pppd były skompilowane ze zdefiniowanym PPP_FILTER.
Zezwol peerom na używanie podanych adresów IP lub podsieci bez uwierzytelniania. Parametr jest przetwarzany jak każdy element listy dozwolonych adresów IP z plików sekretów (zobacz sekcję UWIERZYTELNIANIE poniżej).
Zażądaj by peer kompresował wysyłane pakiety przy użyciu mechanizmu BSD-Compress z maksymalnym rozmiarem kodu nr bitów i zgódź się na kompresowania pakietów wysyłanych do peera z maksymalnym rozmiarem kodu nt bitów. Jeśli nt nie jest podane, to domyślnie odpowiada wartości nr. Wartości w zakresie 9 do 15 są typowymi wartościami tych parametrów; większe dają lepszą kompresję, lecz wymagają więcej pamięci jądra da słowniki kompresji. Alternatywnie, podanie wartości 0 jako nr lub nt wyłącza kompresję w danym kierunku. Aby wyłączyć kompresję całkowicie, użyj nobsdcomp lub bsdcomp 0.
Użyj niestandardowego sprzętowego sterowania przepływem (np. DTR/CTS) do sterowania przepływem danych przez port szeregowy. Jeśli nie podany jest ani crtscts, ani nocrtscts, ani cdtrcts lub nocdtrcts, ustawienie sprzętowego sterowania przepływem na danej linii pozostaje niezmienione. Niektóre porty (np. Maca) nie posiadają prawdziwego wyjścia RTS. Porty takieużywają tego trybu do implementowania prawdziwego, dwukierunkowego sterowania przepływem. Poświęceniem jest to, że tryb sterowania przepływem nie zezwala na używanie DTR jako lnii kontroli modemu.
Jeśli podana jest ta opcja, pppd będzie wyzywał peera co n sekund.
Ustaw maksymalną liczbę transmisji wyzwań CHAP na n (domyślnie 10).
Ustaw czas opóźnienia wyzwań na n sekund (domyślnie 3).
Czekaj do n milisekund po zakończeniu skryptu connect na prawidłowe pakiety ppp od peera. Pod koniec tego czasu lub gdy od peera nadejdzie prawidłowy pakiet PPP, pppd rozpocznie negocjację przez przesyłanie pierwszego pakietu LCP. Domyślną wartością jest 1000 (1 sekunda). Ten czas oczekiwania ma znaczenie tylko jeśli używana jest opcja connect lub pty.
Włącza zabudowę debuggowania połączenia. Po podaniu tej opcji, pppd raportuje zawartość wszystkich pakietów kontrolnych w czytelnej postaci. Pakiety są raportowane poprzez sysloga w zabudowie daemon i poziomie debug. Informacja ta może być przekierowana do pliku przez poprawne skonfigurowanie /etc/syslog.conf (zobacz syslog.conf(5)).
Wyłącz negocjację asyncmap i wymuś cytowanie wszystkich znaków sterujących w obu kierunkach.
Wyłącz negocjację MRU. Po włączeniu tej opcji, pppd użyje domyślnej wartości 1500 bajtów.
Żąda by peer kompresował wysyłane pakiety w mechanizmie deflate z maksymalnym rozmiarem okna 2**nr bajtów i zgodził się na kompresowanie pakietów wysyłanych do peera z maksymalnym rozmiarem okna 2**nt bajtów. Jeśli nie podano nt to przyjmowana jest wartość równa nr. Jako parametry używane są wartości w zakresie 8 do 15; większe dają lepszą kompesję, lecz zabierają więcej pamięci na słowniki kompresji. Wartość 0 wyłącza kompresję w danym kierunku. Kompresję można wyłączyć, stosując nodeflate lub deflate 0. (Uwaga: pppd preferuje kompresję deflate nad BSD-compress jeśli peer może i tamto.)
Inicjalizuj połączenie tylko na żądanie, tj. gdy istnieje natłok danych. Przy tej opcji, zdalny adres IP musi być podawany przez użytkownika w linii poleceń lub w pliku z opcjami. Pppd początkowo konfiguruje interfejs i otwiera je na dane IP bez łączenia się z peerem. Gdy pojawią się dane, pppd łączy się z peerem, dokonuje negocjacji, uwierzytelniania, etc. Gdy jest to zakończone, pppd rozpoczyna przekazywanie pakietów danych (tj. pakietów IP) poprzez łącze.

Opcja Idemand implikuje opcję persist. Jeśli zachowanie to nie jest pożądane, użyj opcji nopersist po opcji demand. W połączeniu z opcją demand przydatne są też idle i holdoff.

W celach uwierzytelniania, doklej nazwę domeny d do nazwy hosta lokalnego. Na przykład, jeśli gethostname() zwraca nazwę porsch, lecz w pełni kwalifikowaną nazwą domeny jest porsche.quotron.com, to powinieneś podać domain quotron.com. Pppd użyje wtedy nazwy porsche.quotron.com do podglądania sekretów w pliku z sekretami i jako domyślnej nazwy do wysyłania do peera podczas uwierzytelniania. Opcja ta jest uprzywilejowana.
Podczas raportowania zawartości pakietów PAP, opcja ta powoduje, że pppd nie załącza do raportu łańcucha z hasłem. Jest to zachowanie domyślne.
Podaje ile sekund czekać przed ponownym rozpoczęciem połączenia po jego zakończeniu. Opcja ta ma efekt tylko w połączeniu z opcjami persist lub demand. Okres holdoff nie jest używany gdy połączenie zostało zerwane z powodu bezczynności.
Określa, że pppd powinien rozłączyć się jeśli łącze było bezczynne przez n sekund. Łącze jest bezczynne jeśli nie przesyłane są przez nie żadne pakiety. Uwaga: nie zaleca się używania tej opcji z opcjią persist bez opcji demand. Jeśli podana jest opcja active-filter, odrzucane przez filtr aktywności pakiety liczą się również jako bezczynne łącze.
Przy podaniu tej opcji, pppd przyjmuje wyobrażenie peera o naszym lokalnym adresie IP, nawet jeśli adres lokalny podano jako opcję.
Przy podaniu tej opcji, pppd przyjmuje wyobrażenie peera o jego (zdalnym) adresie IP, nawet jeśli adres ten podany został jako opcja.
Ustaw maksymalną liczbę transmisji żądania konfiguracji IPCP na n (domyślnie 10).
Ustaw maksymalną liczbę NAK-ów konfiguracji IPCP zwróconych przed rozpoczęciem wysyłania Odrzuceń konfiguracji na n (domyślnie 10).
Ustaw maksymalną liczbę transmisji żądań zakończenia IPCP na n (domyślnie 3).
Ustaw interwał restartu IPCP (czas opóźnienia retransmisji) na n sekund (domyślnie 3).
Daje dodatkowy parametr dla skryptów ip-up i ip-down. Jeśli podana jest ta opcja, to łańcuch jest przekazywany jako 6 parametr tych skryptów.
Ustaw maksymalną liczbę transmisji żądań konfiguracji IPv6CP na n (domyślnie 10).
Ustaw maksymalną liczbę NAK-ów konfiguracji IPv6CP, zwracanych przed rozpoczęciem wysyłania Odrzuceń konfiguracji na n (domyślnie 10).
Ustaw maksymalną liczbę transmisji żądań zakończenia IPv6CP na n (domyślnie 3).
Ustaw interwał restartu IPv6CP (czas opóźnienia retransmisji) na n sekund (domyślnie 3).
Włącz protokoły IPXCP i IPX. Opcja ta jest obecnie obsługiwana jedynie pod Linuksem i tylko jeśli jądro ma wsparcie IPX.
Ustaw numer sieci IPX w ramce żądania konfiguracji IPXCP na n, liczbę szesnastkową (bez 0x na początku). Nie ma sensownej wartości domyślnej. Jeśli opcja ta nie jest podana, numer sieci jest pobierany od peera. Jeśli peer nie ma numeru sieci, protokół IPX nie zostanie uruchomiony.
Ustaw numery węzła IPX. Dwa numery węzła są rozdzielane od pozostałych znakiem dwukropka. Pierwszy numer n jest numerem węzła lokalnego. Drugi jest numerem węzła peera. Każdy numer węzła musi być liczbą szesnastkową o długości najwyżej 10 cyfr. Numery węzłów sieci ipx muszą być unikalne. Nie ma sensownej wartości domyślnej. Jeśli opcja ta nie jest podana, numery węzłów są pobierane od peera.
Ustaw nazwę routera. Łańcuch ten jest przesyłany do peera jako dane informacyjne.
Ustaw tą opcją odbierany protokół trasowania. Można podać więcej niż jedną instancję tej opcji. Opcja none (0) może być podana jako jedyna instncja tej opcji. Wartościami mogą być 0 (NONE), 2 (RIP/SAP), 4 (NLSP).
Przyjmij NAK peera dla numeru węzła podanego w opcji ipx-node. Jeśli podano niezerowy numer węzła, to domyślnie naciska się na używanie tej wartości. Jeśli załączasz tę opcję, to zezwalasz peerowi na przeciążanie wpisu numeru węzła.
Przyjmij NAK peera dla numeru sieci podanego w opcji ipx-network. Jeśli podano niezerowy numer sieci, to domyślnie naciska się na używanie tej wartości. Jeśli załączasz tę opcję, to zezwalasz peerowi na przeciążenie wpisu numeru węzła.
Użyj peerowego numeru sieci, podanego w ramce żądania konfiguracji. Jeśli dla peera podano numer węzła, a tej opcji nie podano, peer będzie zmuszony do używania wartości, którą podałeś.
Ustaw maksymalną liczbę ramek żądań konfiguracji IPXCP wysyłanych przez system na n. Domyślnie 10.
Ustaw maksymalną liczbę ramek NAK IPXCP, którą system wyśle przed odrzucaniem opcji. Domyślnie 3.
Ustaw maksymalną liczbę ramek żądań zakończenia zanim system lokalny uzna, że peer go nie słucha. Domyślnie 3.
Włącz kod debuggowania na poziomie jądra sterownika PPP. Argument n jest liczbą, która jest sumą następujących wartości: 1 włącza ogólne informacje debuggowe, 2 żąda by drukowana była zawartość odbieranych pakietów, 4 żąda by drukowana była zawartość przesyłanych pakietów. Na większości systemów, komunikaty drukowane przez jądro są raportowane przez syslog(1) do pliku wskazanego w pliku konfiguracyjnym /etc/syslog.conf.
Powoduje, że pppd poprawia odpowiednio ustawienia jądra. Pod linuksem pppd w przypadku używania opcji proxyarp włącza forwardowanie IP (tj. ustawia /proc/sys/net/ipv4/ip_forward na 1) oraz w trybie demand włącza (o ile adres lokalny się zmienia) opcję dynamicznego adresu IP (tj. ustawia na 1 /proc/sys/net/ipv4/ip_dynaddr).
Jeśli podana jest ta opcja, pppd przyjmuje, że peer nie żyje w momencie gdy n żądań echa LCP zostanie wysłanych bez odpowiedzi LCP. Jeśli zajdzie ta sytuacja, pppd przerwie połączenie. Używanie tej opcji wymaga niezerowej wartości parametru lcp-echo-interval. Opcja ta może być używana do umożliwiania pppd kończenia działania po zerwaniu fizycznego połączenia (np. po odwieszeniu słuchawki) w sytuacjach, gdzie nie są dostępne sprzętowe linię sterowania modemem.
Jeśli podana jest ta opcja, pppd do peera będzie wysyłać ramkę żądania echa LCP co n sekund. Normalnie peer powinien odpowiedzieć wysyłając odpowiedź na echo. Opcja ta może być używana w połączeniu z lcp-echo-failure do wykrywania czy peer jest wciąż podłączony.
Ustaw maksymalną liczbę transmisji żądań konfiguracji LCP na n. Domyślnie 10.
Ustaw maksymalną liczbę NAK-ów konfiguracji LCP, zwracanych przed rozpoczęciem wysyłania Odrzuceń konfiguracji. Domyślnie 10.
Ustaw maksymalną liczbę transmisji żądań zakończenia LCP na n (domyślnie 3).
Ustaw interwał restartu LCP (czas opóźnienia retransmisji) na n sekund (domyślnie 3).
Ustawia logiczną nazwę łacza na nazwa. Pppd utworzy plik o nazwie ppp-nazwa.pid w /var/run (lub na niektórych systemach w /etc/ppp), zawierający jego PID. Jest to przydatne do określania, która instancja pppd jest odpowiedzialna za łącze z danym peerem. Jest to opcja uprzywilejowana.
Nie używaj linii sterowania modemem. Przy użyciu tej opcji, pppd będzie ignorować stan CD (Carrier Detect) i nie będzie zmieniać stanu DTR (Data Terminal Ready).
Wysyłaj informacje raportowe do deskryptora pliku n. Pppd będzie wysyłać te informacje do najwyżej jednego pliku lub deskryptora (oraz wysyłaj komunikaty do sysloga), więc opcja ta i logfile są rozłączne. Domyślną wartością dla pppd jest wysyłanie wiadomości raportowych na stdout (deskryptor 1), chyba że port szeregowy jest już na ten deskryptor otwarty.
Doklejaj komunikaty raportowe do pliku nazwapliku (oraz wysyłaj komunikaty do sysloga). Plik otwierany jest z prawami użytkownika, który uruchomił pppd. Otwierany jest w trybie dopisywania.
Użyj systemowej bazy haseł do uwierzytelnienia peera z pomocą PAP i nagraj użytkownika do systemowego pliku wtmp. Zauważ, że peer musi mieć swój wpis w /etc/ppp/pap-secrets oraz w systemowej bazie haseł.
Zakończ połączenie po jego dostępności dla sieci przez n sekund (tj. n sekund po pierwszym przejściu protokołu kontroli sieci).
Zakończ po n kolejno nieudanych próbach połączenia. Wartość 0 oznacza brak limitów. Domyślną wartością jest 10.
Używaj linii sterowania modemem. Opcja ta jest domyślna. Z jej użyciem, pppd będzie czekać na sygnał CD (Carrier Detect) od modemu jako zapewnienie otwarcia urządzenia szeregowego (chyba że podany jest skrypt connect) i opuści DTR (Data Terminal Ready) gdy połączenie będzie zakończone i przed wywołaniem skryptu connect. Na ultriksie, opcja ta implikuje sprzętowe sterowanie przepływem, jak w opcji crtscts.
Jeśli pppd działa jako serwer klientów MS Windows, opcja ta umożliwia przekazywanie klientom jednego lub dwóch adresów DNS. Pierwsze pojawienie się tej opcji określa adres podstawowego DNS; druga podaje adres drugorzędny. (Opcja ta była obecna w starszych wersjach pppd pod nazwą dns-addr.)
Jeśli pppd działa jako serwer dla MS Windows lub dla klientów "Samby", to opcja ta umożliwia pppd przekazywanie jednego lub dwóch adresów serwerów WINS (Windows Internet Name Services) dla klientów. Pierwsze pojawienie tej opcji określa podstawowy adres WINS; drugie--drugorzędny.
Ustaw nazwę systemu lokalnego na nazwa. Jest to wykorzystywane w celach uwierzytelniania. Jest to opcja uprzywilejowana. Po jej włączeniu, pppd uzywa w plikach sekretów linii, które mają nazwę jako drugie pole linii. Tylko tych linii używa do uwierzytelniania peera. Dodatkowo, jeśli nie zostanie to przesłonięte opcją user, nazwa będzie używana jako nazwa wysyłana do peera podczas uwierzytelniania lokalnego systemu u peera. (Zauważ, że pppd nie dokleja do nazwy nazwy domeny.)
Ustaw maskę sieciową interfejsu na n, tj. 32 bitową maskę w kropkowej notacji dziesiętnej (np. 255.255.255.0). Jeśli podana jest ta opcja, to wartość jej zostanie połączona logicznym OR z domyślną maską sieciową. Domyślna maska sieciowa jest wybierana według wynegocjowanego zdalnego adresu IP; jest maską odpowiednią dla klasy zdalnego adresu IP, połączoną logicznym OR z maskami sieciowymi wszelkich interfejsów sieciowych point-to-point systemu, znajdujących się w tej samej sieci. (Uwaga: na niektórych platformach pppd zawsze jako maski sieciowej używa 255.255.255.255 jeśli jest to jedyna wartość odpowiednia dla intefejsu point-to-point.)
Wyłącz kompresję Address/Control w obydwu kierunkach (nadawania i odbioru).
Nie wymagaj od peera uwierzytelniania. Opcja ta jest uprzywilejowana.
Wyłącza kompresję BSD-Compress; pppd nie będzie żądać lub zgadzać się na kompresowanie pakietów wg. tego schematu.
Wyłącz negocjację CCP (Compression Control Protocol). Opcja ta powinna być używana jedynie jeśli peer jest zapchlony i nie potrafi obsłużyć żądań pppd o negocjację CCP.
Wyłącz sprzętowe sterowanie przepływem (RTS/CTS) portu szeregowego. Jeśli nie jest podane crtscts, nocrtscts, cdtrcts, ani nodtrcts, sprzętowe sterowanie przepływem nie jest zmieniane.
Opcja ta jest synonimem nocrtscts. Dowolna z tych opcji wyłącza obydwie postaci sterowania przepływem.
Wyłącz opcję defaultroute. Jeśli administrator chce zabronić użytkownikom tworzenia przez pppd domyślnych tras, to może umieścić tę opcję w pliku /etc/ppp/options.
Wyłącza kompresję Deflate; pppd nie zażąda i nie zgodzi się na kompresję pakietów wg tego schematu.
Nie odłączaj się od terminala sterującego. Bez tej opcji, w przypadku podania urządzenia szeregowego innego niż terminal standardowego wejścia, pppd fork(2)nie by przejść w tło.
Wyłącz negocjację IPCP i komunikację IP. Opcja ta powinna być używana tylko jeśli peer ma błędy i nie potrafi obsłużyć żądań negocjacji IPCP.
Wyłącz negocjację IPv6CP i komunikację IPv6. Opcja ta powinna być używana tylko jeśli peer ma błędy i nie potrafi obsłużyć żądań negocjacji IPv6CP.
Wyłącza domyślne zachowania gdy nie jest podany lokalny adres IP, którym jest określenie (jeśli się da) lokalnego adresu IP z nazwy hosta. Po użyciu tej opcji, peer będzie musiał przekazać lokalny adres IP podczas negocjacji IPCP (chyba że podano go jawnie w linii poleceń lub w pliku z opcjami).
Wyłącz protokoły IPXCP i IPX. Opcja ta powinna być używana tylko jeśli peer ma błędy i nie potrafi obsłużyć żądań negocjacji IPXCP.
Przeciwieństwo opcji ktune; nie zezwala pppd na zmianę ustawień systemowych.
Nie wysyłaj komunikatów raportowych do pliku lub deskryptora. Opcja ta unieważnia opcje logfd i logfile. nomagic Wyłącz negocjację magicznych numerków. Po włączeniu tej opcji, pppd nie potrafi wykryć linii zapętlonej (looped-back). Opcja ta powinna być używana tylko jeśli peer ma błędy.
Wyłącz negocjację kompresji pól protokołu w obydwu kierunkach transmisji.
Zakończ po dokonaniu i przerwaniu połączenia. Jest to wartość domyślna, chyba że użyto opcji persist lub demand.
Nie przyjmuj kompresji Predictor-1.
Wyłącz opcję proxyarp. Administrator może w ten sposób zabronić użytkownikom tworzenia wpisów proxy ARP. Wystarczy umieścić tę opcję w pliku /etc/ppp/options.
Normalnie pppd wymaga urządzenia terminalowego. Po użyciu tej opcji, pppd alokuje sobie parę master-slave pseudo-tty i używa niewolnika jako urządzenie terminalowe. Pppd utworzy proces potomny, zachowujący się jako `przetaczacz znaków', przesyłający znaki między masterem pseudo-tty i jego standardowym wejściem i wyjściem. W efekcie, pppd będzie przesyłać znaki na swoje standardowe wyjście i odbierać je ze swojego standardowego wejścia nawet, jeśli nie są one urządzeniami terminalowymi. Opcja ta zwiększa oczywiście zajętość CPU. Przy użyciu tej opcji nie można podawać jawnej nazwy urządzenia.
Wyłącz kompresję nagłówków TCP/IP w stylu Van Jacobsona. Tyczy się obu kierunków transmisji.
Wyłącz opcję kompresji ID-połączenia w kompresji nagłówka TCP/IP w stylu Van Jacobsona. Opcja ta powoduje, że pppd ani peer nie będą omijać bajtu ID-połączenia w skompresowanych Van Jacobsonowo nagłówkach TCP/IP.
Wskazuje, że wszystkie sekrety z pliku /etc/ppp/pap-secrets, używane do sprawdzania tożsamości peera są zakodowane i w związku z tym pppd nie powinien przyjmować haseł, które przed zakodowaniem są równoważne sekretom z pliku /etc/ppp/pap-secrets.
Ustaw maksymalną luczbę transmisji żądań uwierzytelnienia PAP na n. Domyślnie 10.
Ustaw interwał restartu PAP (czas opóźnienia retransmisji) na n sekund. Domyślnie 3.
Ustaw maksymalny czas, przez który pppd ma oczekiwać na uwierzytelnienie od peera z pomocą PAP. Czas w sekundach, 0 oznacza brak limitu.
Określa filtr pakietowy, załączany do przesyłanych pakietów danych w celu określenia, które pakiety mogą przepłynąć. Pakiety odrzucane przez filtr są po cichu niszczone. Opcja ta może być używana w celu uchronienia pewnych demonów sieciowych (jak routed) od używania pasma uplinka lub do zestawienia podstawowych elementów zapory ogniowej. Składnia wyrażenia-filtru jest taka jak dla tcpdump(1), lecz kwalifikatory nieodpowiednie dla połączenia PPP, takie jak ether czy arp nie są dozwolone. Ogólnie, wyrażenie filtru powinno być ujęte w pojedyncze cudzysłowy celem zapobieżenia interpretacji przez powłokę. Zauważ, że możliwe jest załączenie różnych przymusów na wchodzące i wychodzące pakiety z użyciem kwalifikatorów inbound i outbound. Opcja ta jest obecnie dostępna jedynie pod NetBSD, a i to tylko w wypadku, gdy jądro i pppd zostały skompilowane ze zdefiniowanym PPP_FILTER.
Nie kończ działania po zakończeniu połączenia. Zamiast tego spróbuj wznowić połączenie.
Załaduj plik obiektowy nazwapliku biblioteki dzielonej jako plugin. Jest to opcja uprzywilejowana.
Zażądaj by peer używał kompresjii Predictor-1 i zgódź się na wysyłanie ramek podobnie skompresowanych o ile takie będzie życzenie. Opcja ta nie daje żadnego efektu jeśli jądro nie obsługuje kompresji Predictor-1.
Zezwol członkom grupy nazwagrupy na używanie uprzywilejowanych opcji. Jest to opcja uprzywilejowana. Używanie jej wymaga uwagi, gdyż nie można zapewnić, że członkowie danej grupy nie spróbują użyć pppd w celu uzyskania praw roota. Uznaj to za równoważne wstawieniu członków danej grupy do grupy kmem lub disk.
Dodaj wpis do tablicy ARP [Address Resolution Protocol] tego systemu. Ma on zawierać adres IP peera i adres ethernetowy tego systemu. Będzie to miało efekt taki, że peer dla innych systemów będzie wyglądał jak na lokalnym ethernecie.
Określa polecenie skrypt, jako ośrodek komunikacji zamiast konkretnego urządzenia terminalowego. Pppd zaalokuje sobie parę master-slave pseudo-tty i użyje niewolnika jako swojego urządzenia terinalowego. skrypt zostanie uruchomiony w procesie potomnym z masterem pseudo-tty jako swoim standardowym wejściem i wyjściem. Przy używaniu tej opcji nie można podawać jawnej nazwy urządzenia. (Uwaga: jeśli w połączeniu z tą, użyta jest opcja record, proces potomny będzie miał łącza na swoim stadardowym wejściu i wyjściu.)
Po użyciu tej opcji, pppd będzie przyjmował wszystkie znaki sterujących od peera, łącznie z tymi zaznaczonymi w asyncmapie odbiorczej. Bez tej opcji, pppd będzie niszczył te znaki, zgodnie z RFC1662. Opcja ta powinna być używana tylko jeśli peer jest zapchlony.
Podaje, że pppd powinien nagrywać wszystkie wysyłane i odbierane znaki do pliku o nazwie nazwapliku. Plik ten jest otwierany w trybie dopisywania, z użyciem ID użytkownika i jego uprawnieniami. Opcja ta jest zaimplementowana z użyciem pseudo-tty i procesu do przesyłania znaków między pseud-tty a prawdziwym urządzeniem szeregowym. Powoduje ona więc wzrost obciążenia CPU. Znaki są wybierane w formacie oznaczonym pieczątkami czasowymi, które mogą być wyświetlane w czytelnej postaci z użyciem programu pppdump(8).
Ustaw zakładaną nazwę zdalnego systemu w celu uwierzytelniania na nazwę.
Po podaniu tej opcji, pppd nie zgodzi się na uwierzytelnianie się u peera z pomocą CHAP.
Po podaniu tej opcji, pppd nie zgodzi się na uwierzytelnianie się u peera z pomocą PAP.
Wymagaj od peera uwierzytelnienia się z pomocą CHAP [Challenge Handshake Authentication Protocol].
Wymagaj od peera uwierzytelnienia się z pomocą PAP [Password Authentication Protocol].
Podczas logowania zawartości pakietów PAP opcja ta powoduje, że pppd pokazuje w łańcuchach raportowych hasła.
Po podaniu tej opcji, pppd nie będzie przesyłać pakietów LCP do rozpoczęcia połączenia przed odebraniem od peera prawidłowego pakietu LCP (jak dla opcji `passive' w starożytnych opcjach pppd).
Użyj synchronicznego kodowania szeregowego HDLC zamiast asynchronicznego. Urządzenie używane przez pppd musi mieć obsługę synchroniczną. Obecnie pod linuksem i FreeBSD 2.2.8 i późniejszych wspierane są adaptery Microgate SyncLink.
Po podaniu tej opcji, pppd odłączy się od terminala sterującego po zestawieniu połączenia ppp (do momentu kiedy pojawi się pierwszy kontrolny protokół sieciowy, zwykle protokół IP).
Wymuś użycie nazwy hosta (z dodana ewentualnie nazwą domeny) jako nazwy systemu lokalnego w celach uwierzytelniania (przesłania opcję name). Opcja ta nie jest zwykle potrzebna, gdyż opcja name jest uprzywilejowana.
Zapytaj peera o dwa serwery DNS. Adresy przekazane przez peera są przekazywane od peera do pliku /etc/ppp/ip-up przez zmienne środowiskowe DNS1 i DNS2. Dodatkowo, pppd utworzy plik /etc/ppp/resolv.conf, zawierający jedną lub dwie linie z adresami, przekazanymi przez peera.
Ustaw nazwę używaną do uwierzytelniania systemu lokalnego u peera na nazwę.
Ustawia liczbę slotów połączeń, używanych w kodzie kompresji nagłówka TCP/IP Van Jacobsona. Liczba musi zawierać się między 2 a 16 (włącznie).
Uruchom program skrypt przed rozpoczęciem negocjacji PPP, ale po skrypcie connect. Wartość tej opcji nadana z uprzywilejowanego źródła nie może byc przeciążona przez nieuprzywilejowanego użytkownika.
Włącz programowe sterowanie przepływem (XON/XOFF).

Opcje mogą być pobierane z linii poleceń lub z plików. Pppd odczytuje je z plików /etc/ppp/options, ~/.ppprc i z /etc/ppp/options.nazwatty (w tej kolejności) przed przetworzeniem opcji z linii poleceń. (W rzeczywistości, opcje linii poleceń są skanowane w celu znalezienia nazwy terminala przed odczytem options.nazwatty.) Przy formowaniu nazwy pliku options.nazwatty, usuwany jest przedrostek /dev/,a wszelkie dodatkowe znaki / są zamieniane na kropki.

Plik z opcjami jest analizowany jako seria słów, rozdzielonych białymi spacjami. Białe spacje mogą być załączane do słowa przez ujęcie całości w podwójne cudzysłowy ("). Lewy ukośnik może cytować następujący po nim znak. Znak krzyżyka (#) rozpoczyna komentarz, trwający aż do końca linii. Nie ma ograniczeń w używaniu opcji file lub call w pliku z opcjami.

pppd udostępnia administratorom wydajną kontrolę dostępu dla określonych użytkowników, bez strachu o poświęcanie bezpieczeństwa serwera lub sieci, w ktrej się znajduje. Kontrola ta polega na ograniczaniu adresów IP, jakie może mieć peer, zależnie od identyfikacji i ograniczeń co do opcji, których może używać nieuprzywilejowany użytkownik. Różne opcje pppd są uprzywilejowane--są to głównie opcje, które mogą wprowadzać zagrożenia w konfiguracji; opcje te mogą być przyjmowane jedynie z plików znajdujacych się pod kontrolą administratora systemu lub gdy pppd jest uruchamiane z poziomu roota.

Domyślnym zachowaniem pppd jest zezwalanie nieuwierzytelnionemu peerowi na używanie danego adresu IP tylko jeśli system nie ma jeszcze trasy do tego adresu. Na przykład, system o stałym połączeniu do szerszego internetu normalnie ma trasę domyślną, więc wszystkie peery muszą się uwierzytelnić aby zestawić połączenie. Na takim systemi opcja auth jest domyślna. Z drugiej strony, system gdzie łącze ppp jest jedynym połączeniem do internetu normalnie nie ma trasy domyślnej, więc peer będzie w stanie używać prawie dowolnego adresu IP bez uwierzytelniania.

Jak wykazano wyżej, niektóre opcje bezpieczeństwa są uprzywilejowane, co znaczy, że nie mogą być używane przez zwykłego użytkownika uruchamiającego suid-root pppd--czy to z linii poleceń czy z pliku ~/.ppprc czy z opcji file. Opcje uprzywilejowane mogą być używane w pliku /etc/ppp/options lub w dowolnym pliku z opcjami, odczytywanym opcją call. Jeśli pppd jest używane przez roota, opcje uprzywilejowane mogą być używane bez ograniczeń.

Przy otwieraniu urządzenia pppd używa ID wołąjącego użytkownika lub UID roota (tj. 0), zależnie czy nazwa urządzenia została podana przez użytkownika czy administratora. Jeśli nazwa pochodzi ze źródła uprzywilejowanego, tj. z /etc/ppp/options lub z pliku z opcjami, odczytanego przy użyciu opcji call, pppd używa pełnych praw roota do dostępu do urządzenia. Tak więc tworzenie odpowiedniego pliku w /etc/ppp/peers umożliwia administratorowi zezwolenie użytkownikom na zestawianie połączeń ppp poprzez urządzenie, do którego normalnie nie mieliby prawa dostępu. W przeciwnym wypadku, pppd używa przy otwieraniu urządzenia rzeczywistego UID użytkownika.

Uwierzytelnianie jest procesem przekonywania przez peera drugiej strony o swojej tożsamości. Wymaga to wysłania najpierw przez peera swojej nazwy wraz z informacją sekretną, która może pochodzić tylko od autoryzowanego użytkownika o tej nazwie. W takiej wymianie pierwszego peera nazywa się "klientem", a drugiego "serwerem". Klient ma nazwę która określa go dla serwera, a serwer ma również nazwę, która określa go dla klienta. Ogólnie, klient dzieli pewien sekret (lub hasło) z serwerem i uwierzytelnia się poprzez udowodnienie, że zna sekret. Często nazwy używane w uwierzytelnianiu odpowiadają internetowym nazwom hostów peerów, lecz nie jest to konieczne.

Obecnie pppd obsługuje dwa protokoły uwierzytelniania: PAP i CHAP. PAP powoduje, że klient wysyła swoją nazwę oraz hasło do serwera. CHAP natomiast powoduje, że serwer wysyła klientowi wezwanie (pakiet wezwania zawiera nazwę serwera). Klient musi odpowiedzieć słowami, zawierającymi nazwę plus wartość hash, wyciągniętą z dzielonego sekretu i wezwania, udowadniając w ten sposób, że zna sekret.

Protokół PPP, będąc symetrycznym, umożliwia obydwu peerom wymaganie uwierzytelnienia siebie nawzajem. W tym wypadku następują dwie oddzielne i niezależne wymiany pakietów uwierzytelniających. Obydwie wymiany mogą używać różnych protokołów uwierzytelniania i, w ogólności, można w nich używać różnych nazw.

Domyślnym zachowaniem pppd jest zgoda na uwierzytelnienie po zażądaniu i nie wymaganie uwierzytelnienia od peera. Jednak pppd nie zgodzi się na uwierzytelnienie się w konkretnym protokole jeśli nie ma sekretów, których mógłby w tym celu użyć.

Pppd przechowuje swoje sekrety w plikach sekretów (/etc/ppp/pap-secrets dla PAP i /etc/ppp/chap-secrets dla CHAP). Obydwa pliki sekretów mają ten sam format. Pliki te mogą zawierać sekrety dla pppd, używane przy uwierzytelnianiu się dla innych systemów oraz sekrety dla pppd, używane przy uwierzytelnianiu innych systemów dla nas.

Każda linia pliku sekretów zawiera jeden sekret. Dany sekret jest specyficzny dla danej konfiguracji klienta/serwera - może być używana tylko przez tego klienta do uwierzytelnienia się przed tym serwerem. Z tego powodu każda linia ma trzy pola: nazwę klienta, serwera oraz sekret. Za polami tymi może nastąpić lista adresów IP, których dany klient może użyć po połączeniu z danym serwerem.

Plik z sekretami jest analizowany jako słowa, jak plik z opcjami, więc nazwa klienta, serwera i sekretów muszą być pojedynczymi słowami, gdzie osadzone spacje lub znaki specjalne można cytować lub ujmować w cudzysłowy. Zauważ, że rozmiar liter jest w przypadku nazw klienta i serwera oraz sekretu istotny.

Jeśli sekret rozpoczyna się od `@', to reszta jest rozumiana jako nazwa pliku, z którego odczytać sekret. "*" jako klient lub serwer odpowiada dowolnej nazwie. Podczas wybierania sekretu pppd wybiera najlepsze dopasowanie, tj. dopasowanie wykorzystujące najmniej jokerów.

Wszelkie następujące słowa tej samej linii są uważane za listę adresów IP dopuszczalnych dla klienta. Jeśli dane są tylko 3 słowa, lub jeśli pierwszym słowem jest "-", to zabronione są wszystkie adresy IP. Aby udostępnić dowolny adres, użyj "*". Słowo rozpoczynające się od "!" wskazuje, że podany adres nie jest dopuszczalny. Adres może mieć na końcu "/" i liczbę n, określającą całą podsieć, tj. wszystkie adresy, mające taką samą wartość w najbardziej znaczących n bitach. W tej postaci adres może mieć na końcu znak plus ("+"), określający, że jeden z adresów podsieci jest autoryzowany w oparciu o numer używanej jednostki sieciowego interfejsu ppp. W tym przypadku część hosta adresu będzie ustawiana na numer jednostki plus jeden.(???)

W ten sposób plik z sekretami zawiera sekrety używane do uwierzytelniania siebie u innych i innych u siebie. Gdy pppd uwierzytelnia peera (sprawdzając jego tożsamość), wybiera sekrety, zawierające nazwę peera w pierwszym polu i nazwę systemu lokalnego w drugim. Nazwa systemu lokalnego odpowiada nazwie hosta z doklejoną nazwy domeny przy użyciu opcji domain. To domyślne zachowanie można przeciążyć opcją name, poza przypadkiem użycia opcji usehostname.

Gdy pppd wybiera sekret używany do uwierzytelnienia się u peera, najpierw określa, jakiej nazwy użyć do przedstawienia się peerowi. Nazwa ta może być podana przez użytkownika opcją user. Jeśli opcja ta nie jest użyta, nazwa odpowiada nazwie systemu lokalnego, określanej jak opisano w poprzednim paragrafie. Następnie pppd szuka sekretów o tej nazwie w pierwszym polu i o nazwie peera w drugim. Pppd pozna nazwę peera w mechanizmie CHAP gdyż ten wyśle ją w pakiecie wyzwania. Jednak jeśli używany jest PAP, pppd będzie musiał określić nazwę peera z opcji podanych przez użytkowika. Użytkownik może określić nazwę peera bezpośrednio opcją remotename. W przeciwnym wypadku, jeśli adres IP zdalnego hosta podano nazwą (a nie numerycznie), to zostanie użyta ta nazwa peera. Gdy to się nie powiedzie, pppd użyje łańcucha zerowego jako nazwy peera.

Podczas uwierzytelniania peera przez PAP, przekazane hasło jest najpierw porównywane z sekretem z pliku sekretów. Jeśli hasło nie pasuje do sekretu, to jest ono kodowane z użyciem crypt() i porównywane raz jeszcze. W ten sposób, sekrety uwierzytelniające mogą być przechowywane w postaci zaszyfrowanej. Jeśli podana jest opcja papcrypt, pierwsze sprawdzenie (bez szyfrowania) jest pomijane.

Co więcej, jeśli podana była opcja login, nazwa użytkowika i hasło są sprawdzane również według systemowej bazy haseł. W rezultacie, administrator systemu może skonfigurować plik sekretów pap na zezwolenie dostępu do PPP jedynie dla określonych użytkowników i ograniczyć zestaw adresów IP, które każdy z użytkowników może wykorzystać. Zazwyczaj przy użyciu opcji login, sekret w /etc/ppp/pap-secrets wynosi "", co pasuje do dowolnego hasła, przekazanego przez peera. Zapobiega to potrzebie posiadania tego samego sekretu w dwóch miejscach.

Uwierzytelnianie musi być zakończone przed IPCP (lub dowolnym innym NCP). Jeśli peer musi się uwierzytelnić, a nie uda się mu to, pppd zakończy połączenie (zamykając LCP). Jeśli IPCP wynegocjuje niedopuszczalny adres IP dla hosta zdalnego, IPCP zostanie zamknięte. Pakiety IP mogą być przesyłane tylko jeśli IPCP jest otwarte.

W niektórych przypadkach oczekiwane jest umożliwienie niektórym hostom, które nie mogą się uwierzytelnić połączenie i używanie ograniczonego zbioru adresów IP, nawet jeśli lokalny host ogólnie wymaga uwierzytelnienia. Jeśli peer odmówi uwierzytelnienia po takim żądaniu, pppd bierze to za równoważność uwierzytelnienia przy użyciu pustego łańcucha nazwy użytkownika i hasła. W ten sposób, dodając linię sekretów z pustym klientem i hasłem, można umożliwić ograniczony dostęp dla hostów, które nie chcą się uwierzytelnić.

Po pomyślnym zakończeniu negocjacji IPCP pppd poinformuje jądro o lokalnym i zdalny adresie IP interfejsu ppp. Jest to wystarczający zabieg do utworzenia trasy do zdalnego końca połączenia, co umożliwia peerom wymianę pakietów IP. Komunikacja z innymi maszynami wymaga w ogólności dalszych modyfikacji tablic routingu i/lub tablic ARP. W większości wypadków wystarczające są opcje defaultroute i/lub proxyarp, lecz w niektórych wypadkach wymagana jest dalsza interwencja. Można do tego wykorzystać skrypt /etc/ppp/ip-up.

Czasami wymagane jest dodanie domyślnej trasy poprzez zdalny host, jak w wypadku maszyny, której jedynym połączeniem z internetem jest interfejs ppp. Opcja defaultroute powoduje, że pppd tworzy taką domyślną trasę po pojawieniu IPCP i kasuje ją po zakończeniu połączenia.

W niektórych przypadkach wymagane jest użycie proxy ARP, np. na maszynie serwerowej podłączonej do LAN, aby reszta hostów mogła komunikować się ze zdalnym hostem. Opcja proxyarp powoduje, że pppd szuka interfejsu sieciowego o tej samej podsieci co zdalny host (interfejs obsługujący broadcast i ARP, który jest włączony i nie jest interfejsem ppp lub loopback). Po znalezieniu, pppd tworzy perrmanentny publikowany wpis ARP z adresem IP zdalnego hosta i adresem sprzętowym znalezionego interfejsu sieciowego.

Gdy używana jest opcja demand, adresy IP są już ustawione przy pojawieniu IPCP. Jeśli pppd nie było w stanie wynegocjować tego samego adresu, którego używało do konfiguracji interfejsu (np. gdy peer jest ISP, używającym dynamicznych IP), pppd musi zmienić adresy interfejsu IP na wynegocjowane. Może to zniszczyć istniejące połączenia i używanie tego typu wydzwaniania z dynamicznymi peerami nie jest zalecane.

Następujące przykłady zakładają, że plik /etc/ppp/options zawiera opcję auth (jak w domyślnym pliku /etc/ppp/options w dystrybucji ppp).

Prawdopodbnie najpopularniejszym zastosowaniem pppd jest wykręcanie numeru ISP. Może to być dokonywane poleceniem takim, jak

pppd call isp

gdzie plik /etc/ppp/peers/isp jest skonfigurowany przez administratora systemu na zawieranie czegoś w rodzaju:

ttyS0 19200 crtscts
connect '/usr/sbin/chat -v -f /etc/ppp/chat-isp'
noauth

W tym przykładzie używamy chat(8) do wykręcenia numeru ISP i przechodzimy przez wymaganą sekwencję logowania. Plik /etc/ppp/chat-isp zawiera skrypt używany przez chat; może na przykład zawierać coś w rodzaju

ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "ERROR"
ABORT "NO ANSWER"
ABORT "BUSY"
ABORT "Username/Password Incorrect"
"" "at"
OK "at&d0&c1"
OK "atdt2468135"
"name:" "^Umyuserid"
"word:" "\qmypassword"
"ispts" "\q^Uppp"
"~-^Uppp-~"

Dla dalszych szczegółów obejrzyj stronę podręcznika do chat(8).

Pppd może również być używane do udostępniania usługi dial-in dla użytkowników. Jeśli użytkownicy mają już konta, to najprostszym sposobem skonfigurowania usługi ppp jest zezwalanie użytkownikom na logowanie się na ich konta i uruchamianie pppd z pomocą komendy takiej, jak

pppd proxyarp

Aby umożliwić użytkownikowi używanie zabudowy PPP, musisz zaalokować adres IP dla maszyny użytkowika i utworzyć wpis w /etc/ppp/pap-secrets lub /etc/ppp/chap-secrets (zależnie od metody uwierzytelniania, preferowanej przez użytkownika), aby użytkownik mógł się uwierzytelnić. Na przykład, jeśli Joe ma maszynę o nazwie "joespc", która może wdzwaniać się na maszynę o nazwie "server" i używać adresu IP joespc.my.net, to w pliku z sekretami należy umieścić następujący wpis:

joespc server "joe's secret" joespc.my.net

Alternatywnie możesz utworzyć użytkownika o nazwie (np.) "ppp", którego powłoką zgłoszeniową jest pppd i którego katalogiem domowym jest /etc/ppp. Opcje używane przez pppd w takim trybie mogą być wstawione do /etc/ppp/.ppprc.

Jeśli twoje połączenie szeregowe jest trochę bardziej złożone niż kawałek kabla, to możesz być zmuszonym zaaranżować jakieś znaki sterujące do cytowania. Na przykład często przydatne jest cytowanie XON (^Q) i XOFF (^S) przy użyciu asyncmap a0000. Jeśli ścieżka zawiera telneta, to prawdopodobnie powinieneś również cytować ^] (asyncmap 200a0000). Jeśli ścieżka zawiera rlogin, to na końcówce rloginowej powinieneś używać opcji escape ff, gdyż wiele implementacji rlogin nie jest przezroczystych; usuwają one sekwencje [0xff, 0xff, 0x73, 0x73, plus dowolnych osiem bajtów] ze strumienia.

Komunikaty są przesyłane do demona sysloga przy użyciu zabudowy LOG_DAEMON. (Może to być przesłonięte przez rekompilowanie pppd z makrem LOG_PPP przedefiniowanym na pożądaną zabudowę.) Aby zobaczyć komunikaty o błędach i debuggowe, musisz wyedytować plik /etc/syslog.conf tak, aby przekierowywał komunikaty na określone urządzenie wyjściowe lub plik.

Opcja debug powoduje, że zawartość wszystkich przesyłanych pakietów kontrolnych jest raportowana. Tzn. wszystkie pakiety LCP, PAP, CHAP lub IPCP. Może to być przydatne jeśli negocjacja ppp się nie powodzi lub jeśli zawodzi uwierzytelnianie. Jeśli debuggowanie jest włączone podczas kompilacji, opcja debug powoduje również raportowanie innych komunikatów debuggowych.

Debuggowanie może być też włączone lub wyłączone przez wysłanie do procesu pppd sygnału SIGUSR1. Sygnał ten działa jak przełącznik.

Kod wyjścia pppd jest ustawiany do wskazania czy zaszedł błąd lub pokazania powodu zakończenia połączenia. Dopuszczalne wartości to:

0
Pppd odłączyło się od terminala, lub też połączenie zostało pomyślnie zestawione i zakończone na żądanie peera.
1
Zaistniajł jakiś błąd krytyczny, taki jak niepowodzenie podstawowego wywołania systmowego czy brak pamięci.
2
W przetwarzaniu podanych opcji wykryto błąd, np. użyto dwóch wykluczających się opcji.
3
Pppd nie jest suid-root, a wołający użytkownik nie jest rootem.
4
Jądro nie daje wsparcia ppp, tj. sterownik ppp jądra nie jest załączony lub nie może zostać załadowany.
5
Pppd zakończyło działanie przez SIGINT, SIGTERM lub SIGHUP.
6
Port szeregowy nie mógł zostać zablokowany.
7
Port szeregowy nie mógł zostać otwarty.
8
Skrypt connect się nie powiódł (zwrócił niezerowy kod wyjścia).
9
Polecenie podane jako argument opcji pty nie mogło zostać uruchomione.
10
Negocjacja PPP się nie powiodła, tj. nie osiągnęła punktu w którym działałby choć jeden protokół sieciowy (np. IP).
11
System peera nie przeszedł procedury uwierzytelniania.
12
Połączenie zostało pomyślnie zestawione i zakończone z powodu bezczynności.
13
Połączenie zostąło pomyślnie zestawione i zakończone z powodu limitu czasu połączenia.
14
Wynegocjowano callback i wkrótce pojawi się nadchodzący telefon.
15
Połączenie zostało zakończone gdyż peer nie odpowiadał na żądania echa.
16
Połączenie zostało zakończone przez modem, który odwiesił słuchawkę.
17
Negocjacja PPP nie powiodła się przez wykrycie szeregowego zapętlenia (loopback).
18
Skrypt init się nie powiódł (zwrócił niezerowy kod wyjścia).
19
Nie uwierzytelniliśmy się u peera.

Pppd na różnych etapach działania wywołuje różne skrypty, używane do dokonywania specyficznego dla stacji przetwarzania. Skrypty te są zwykle skryptami powłoki, lecz mogą równie dobrze być programami binarnymi. Pppd nie czeka aż skrypty skończą działanie. Skrypty są wywoływane z uprawnieniami roota (z rzeczywistym i efektywnym UID 0), więc mogą robić takie rzeczy jak odświeżanie tablic routingu czy uruchamianie uprzywilejowanych demonów. Uważaj, by skrypty te nie osłabiły bezpieczeństwa systemu. Pppd uruchamia skrypty ze standardowym wejściem, wyjściem i wyjściem błędu przekierowanym na /dev/null i ze środowiskiem, które jest puste, poza pewnymi zmiennymi środowiskowymi, które dają informacje o łączu. Zmienne te są następujące:

Nazwa używanego urządzenia szeregowego tty.
Nazwa używanego interfejsu sieciowego.
Adres IP lokalnego końca połączenia. Jest to ustawione tylko po przejściu IPCP.
Adres IP zdalnego końca połączenia. Jest to ustawione tylko po przejściu IPCP.
Uwierzytelniona nazwa peera. Jest to ustawiane tylko jeśli peer się uwierzytelnił.
Szybkość urządzenia tty.
ID użytkownika, który wywołał pppd.
Nazwa użytkownika, który wywołał pppd. Jest to zawsze ustawione.

Dla skryptów ip-down i auth-down, pppd ustawia ponadto następujące zmienne, dające statystyki połączenia:

Liczba sekund od kiedy rozpoczęła się negocjacja PPP, aż do zakończenia połączenia.
Liczba wysłanych bajtów (na poziomie portu szeregowego) podczas połączenia.
Liczba odebranych podczas połączenia bajtów (na poziomie portu szeregowego).
Logiczna nazwa łącza, ustawiana opcją linkname.

Pppd wywołuje następujące skrypty, o ile one istnieją. Nie jest błędem, jeśli ich nie ma:

/etc/ppp/auth-up
Program lub skrypt wykonywany po uwierzytelnieniu przez zdalny system. Jest wywoływany z parametrami
nazwa-interfejsu nazwa-peera nazwa-użytkownika urządzenie-tty szybkość
Zauważ, że skrypt ten nie jest wykonywany jeśli peer się nie uwierzytelni, np. po użyciu opcji noauth.
/etc/ppp/auth-down
Program lub skrypt, który jest uruchamiany przy wyłączaniu połączenia, jeśli uruchamiano wcześniej /etc/ppp/auth-up. Jest wykoywany w ten sam sposób co do parametrów, jak auth-up.
/etc/ppp/ip-up
Program lub skrypt, który jest wykonywany gdy łącze jest w stanie przesyłać lub odbierać pakiety IP (tj. po przejściu IPCP). Jest wykonywany z parametrami
nazwa-interfejsu urządzenie-tty szybkość adres-lokalnego-IP adres-zdalnego-IP ipparam
/etc/ppp/ip-down
Program lub skrypt, który jest wykonywany gdy łącze nie jest już w stanie przesyłać pakiety IP. Skrypt ten może być wykonywany do odtwarzania zmiany wywołanych przez /etc/ppp/ip-up. Jest wywoływany z tymi samymi parametrami co skrypt up-up.
/etc/ppp/ipv6-up
Podobne do /etc/ppp/ip-up, lecz jest wykonywane gdy łącze jest w stanie przesyłać pakiety IPv6. Jest wykonywane z parametrami
nazwa-interfejsu urządzenie-tty szybkość adres-lokalnego-łącza adres-zdalnego-łącza ipparam
/etc/ppp/ipv6-down
Podobne do /etc/ppp/ip-down, lecz jest wykonywane gdy łącze nie jest w stanie już transmitować pakietów IPv6. Jest wykonywane z tymi samymi parametrami co skrypt ipv6-up.
/etc/ppp/ipx-up
Program lub skrypt, który jest wykonywany gdy łącze jest w stanie przesyłać lub odbierać pakiety IPX (tj. po przejściu IPXCP). Jest wykonywany z parametrami
nazwa-interfejsu urządzenie-tty szybkość numer-sieci lokalny-adres-węzła-IPX zdalny-adres-węzła-IPX lokalny-protokół-trasujący-IPX zdalny-protokół-trasujący-IPX lokalna-nazwa-routera-IPX zdalna-nazwa-routera-IPX ipparam pid-pppd
Pola lokalnego/zdalnego-protokołu-trasującego-IPX mogą być jednymi z następujących:
NONE określa brak protokołu trasującego
RIP określa chęć używania RIP/SAP
NLSP określa chęć używania Novell NLSP
RIP NLSP określa chęć używania RIP/SAP i NLSP
/etc/ppp/ipx-down
Program lub skrypt, który jest wykonywany gdy łącze nie może już przesyłać pakietów IPX. Skrypt ten może być używany do anulowania efektów działania skryptu ipx-up. Jest wywoływany z tymi samymi parametrami co ipx-up.

/var/run/pppn.pid (BSD lub Linux), /etc/ppp/pppn.pid (inne)
PID procesu pppd na jednostce interfejsu ppp numer n.
/var/run/ppp-nazwa.pid (BSD lub Linux), /etc/ppp/ppp-nazwa.pid (inne)
PID procesu pppd na logicznym łączu nazwa (zobacz opcję linkname).
/etc/ppp/pap-secrets
Użytkownicy, hasła i adresy IP do uwierzytelniania PAP. Plik ten powinien należeć do roota i nie nadawać się do odczytu/zapisu dla innych użytkowników. W innym wypadku pppd zgłosi ostrzeżenie.
/etc/ppp/chap-secrets
Nazwy, sekrety i adresy IP dla uwierzytelniania CHAP. Podobnie jak dla powyższego, plik ten również powinien być własnością roota i niczyją inną. W przeciwnym wypadku pppd zgłosi ostrzeżenie.
/etc/ppp/options
Domyślne opcje pppd systemu, odczytywane przed opcjami użytkownika lub linii poleceń.
~/.ppprc
Opcje użytkownika, odczytywane przed /etc/ppp/options.nazwatty.
/etc/ppp/options.nazwatty
Domyślne opcje systemowe dla używanego portu szeregowego, odczytywane po ~/.ppprc. W części nazwatty tej nazwy pliku usunięte jest poprzedzeające /dev/, a wszelkie ukośniki są zamienione na kropki.
/etc/ppp/peers
Katalog, zawierający pliki z opcjami, które mogą zawierać uprzywilejowane opcje nawet jeśli pppd został wywołany przez użytkownika innego niż root. Administrator systemu może tworzyć w tym katalogu pliki z opcjami, zezwalającymi nieuprzywilejowanym użytkownikom wydzwanianie bez wymagania uwierzytelnienia od peera, lecz tylko do zaufanych peerów.

Jacobson, V. Kompresowanie nagłówków TCP/IP dla wolnych łączy szeregowych. Luty 1990.
Rivest, R. Algorytm Message-Digest MD5. Kwiecień 1992.
McGregor, G. PPP Internet Protocol Control Protocol (IPCP). Maj 1992.
Lloyd, B.; Simpson, W.A. Protokoły uwierzytelniania PPP. Październik 1992.
Simpson, W.A. Protokół Point-to-Point (PPP). Lipiec 1994.
Simpson, W.A. PPP w ramkach typu HDLC. Lipiec 1994.
Haskin, D. IP wersja 6 w PPP Grudzień 1998.

Następujące sygnały mają podane działanie po wysłaniu do pppd:

Sygnały te powodują, że pppd kończy połączenie (zamykając LCP), odtwarza ustawienia urządzenia szeregowego i kończy działanie.
Sygnał ten powoduje, że pppd kończy połączenie, odtwarza ustawienia portu szeregowego i zamyka urządzenie szeregowe. Jeśli podana jest opcja persist lub demand, pppd spróbuje otworzyć urządzenie szeregowe i rozpocząć nowe połączenie (po okresie przetrzymania--holdoff). W przeciwnym wypadku, pppd zakończy działanie. Jeśli sygnał ten jest odebrany podczas okresu przetrzymania, powoduje on, że pppd kończy ten okres natychmiast.
Sygnał ten przełącza stan opcji debug.
Sygnał ten powoduje, że pppd renegocjuje kompresję. Może to być przydatne do ponownego włączania kompresji po jej wyłączeniu w wyniku krytycznego błędu dekompresji. (Błędy takie w ogólności wskazują na błąd w którejś implementacji.)

Paul Mackerras (Paul.Mackerras@cs.anu.edu.au), w oparciu o wcześniejsze prace Drewa Perkinsa, Brada Clementsa, Karla Foxa, Grega Christy'ego, i Brada Parkera.

Powyższe tłumaczenie pochodzi z nieistniejącego już Projektu Tłumaczenia Manuali i może nie być aktualne. W razie zauważenia różnic między powyższym opisem a rzeczywistym zachowaniem opisywanego programu lub funkcji, prosimy o zapoznanie się z oryginalną (angielską) wersją strony podręcznika za pomocą polecenia:

man --locale=C 8 pppd

Prosimy o pomoc w aktualizacji stron man - więcej informacji można znaleźć pod adresem http://sourceforge.net/projects/manpages-pl/.