Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] pppd - démon du Protocole Point-à-Point (PPP) [size=18] [b]Résumé[/b] [/size] [b]pppd[/b] [ [i]nom_tty[/i] ] [ [i]vitesse[/i] ] [ [i]options[/i] ] [size=18] [b]Description[/b] [/size]     Le Protocole Point-à-Point (PPP) fournit une méthode de transmission de datagrammes au-dessus d'une connexion série point à point. PPP est composé de trois parties : une méthode pour encapsuler des datagrammes dans une liaison série, un protocole de contrôle de lien (LCP) extensible, et une famille de protocoles de contrôle réseau (NCP) pour établir et configurer différents protocoles de niveau réseau.     Le schéma d'encapsulation est fourni par le code du pilote dans le noyau. pppd fournit le LCP de base, le support de l'authentification, et un NCP pour établir et configurer le protocole IP (appelé IPCP pour IP Control Protocol). [size=18] [b]Options[/b] [/size] [i]<nom_tty>[/i] [table][row][col]    [/col][col]Communique sur le périphérique donné. Le préfixe "/dev/" est ajouté si nécessaire. Si aucun nom de périphérique n'est donné, ou si c'est le nom du terminal connecté à l'entrée standard, pppd utilisera ce terminal, et ne "forkera" pas pour passer en arrière-plan. Une indication pour cette option provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.[/col][/row][/table] [i]<vitesse>[/i] [table][row][col]    [/col][col]Fixe le nombre de bauds à <vitesse> (un entier décimal). Sur des systèmes comme 4.4BSD et NetBSD, n'importe quelle vitesse peut être spécifiée. D'autres systèmes (Linux, SunOS...) autorisent seulement un ensemble limité de vitesses.[/col][/row][/table] [b]asyncmap [i]<table>[/b][/i] [table][row][col]    [/col][col]Fixe la table de caractères asynchrone à <table>. Cette table décrit quels caractères de contrôle ne peuvent être reçus avec succès par la ligne série. pppd demandera à son correspondant de lui envoyer ces caractères comme séquence d'échappement de 2 octets. L'argument est un nombre hexadécimal de 32 bits, chaque bit représentant un caractère : à 1 s'il faut le transmettre via esc. Le bit 0 (00000001) représente le caractère 0x00, le bit 31 (80000000) représente le caractère 0x1f ou ^_. Si plusieurs options [i]asyncmap[/i] sont données, les valeurs sont combinées par OR. Si aucune option [i]asyncmap[/i] n'est donnée, aucune table de caractères asynchrone ne sera négociée en réception. Le correspondant devrait alors passer [i]tous[/i] les caractères de contrôle via une séquence d'échappement. Pour les caractères émis, utilisez l'option [i]escape[/i].[/col][/row][/table] [b]auth[/b] [table][row][col]    [/col][col]Demande au correspondant de s'authentifier avant d'autoriser la transmission de paquets réseau. Cette option est fixée par défaut si le système utilise une route par défaut (defaultroute). Si ni [i]auth[/i] ni [i]noauth[/i] n'est spécifiée, pppd n'autorisera son correspondant qu'à utiliser des adresses IP vers lesquelles le système n'a pas encore de route.[/col][/row][/table] [b]call [i]nom[/b][/i] [table][row][col]    [/col][col]Lit les options dans le fichier /etc/ppp/peers/[i]nom[/i]. Ce fichier peut contenir des options privilégiées, comme [i]noauth[/i], même si pppd n'est pas lancé par root. La chaîne [i]nom[/i] ne doit pas commencer par / ni inclure de .. comme composant de chemin. Le format du fichier d'option est décrit plus bas.[/col][/row][/table] [b]connect [i]script[/b][/i] [table][row][col]    [/col][col]Utilise l'exécutable ou la commande shell spécifiée par [i]script[/i] pour initialiser la ligne série. Ce script utilise en principe le programme chat(8) pour gérer le modem et lancer la session ppp distante. Pour cette option, une valeur provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.[/col][/row][/table] [b]crtscts[/b] [table][row][col]    [/col][col]Utilise le contrôle de flux matériel (RTS/CTS) pour contrôler le flux de données sur le port série. Si ni [i]crtscts[/i], ni [i]nocrtscts[/i], ni [i]cdtrcts[/i], ni [i]nocdtrcts[/i] n'est passée, le contrôle de flux du port série est laissé inchangé. Certains ports série (comme celui du Macintosh) manquent d'une vraie sortie RTS. Ces ports série utilisent ce mode pour implémenter un contrôle de flux unidirectionnel. Le port série arrêtera ses envois à la demande du modem (via CTS) mais sera incapable de demander au modem d'arrêter d'envoyer à l'ordinateur. Ce mode garde la possibilité d'utiliser DTR comme ligne de contrôle du modem.[/col][/row][/table] [b]defaultroute[/b] [table][row][col]    [/col][col]Ajoute à la table de routage du système une route par défaut utilisant le correspondant comme passerelle, une fois que la négociation IPCP est terminée. Cette entrée est supprimée quand la connexion PPP est coupée. Cette option est privilégiée si l'option [i]nodefaultroute[/i] a été spécifiée.[/col][/row][/table] [b]disconnect [i]script[/b][/i] [table][row][col]    [/col][col]Exécute le script ou la commande spécifiée par [i]script[/i] dès la fin de la connexion pppd. Ce script peut, par exemple, envoyer au modem l'ordre de raccrocher, si les signaux de contrôle matériel du modem ne sont pas disponibles. Le script de déconnexion n'est pas lancé si le modem a déjà raccroché. Pour cette option, une valeur provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.[/col][/row][/table] [b]escape [i]xx,yy,...[/b][/i] [table][row][col]    [/col][col]Spécifie que certains caractères doivent être "protégés" : précédés d'une séquence d'échappement durant la transmission (sans prendre en compte dans ce cas l'échappement de ces caractères par la table de caractères de contrôle asynchrone, le cas échéant). Les caractères à "protéger" sont spécifiés sous la forme d'une liste de nombre hexa, séparés par des virgules. Notez que presque tous les caractères peuvent être protégés par l'option [i]escape[/i], contrairement à l'option [i]asyncmap[/i] qui permet seulement de spécifier des caractères de contrôle. Les caractères qui ne peuvent pas être protégés sont 0x20 à 0x3f et 0x5e (^).[/col][/row][/table] [b]file [i]nom[/b][/i] [table][row][col]    [/col][col]Lit les options dans le fichier [i]nom[/i] (voir format ci-dessous). Le fichier doit être lisible par l'utilisateur qui a invoqué pppd.[/col][/row][/table] [b]init [i]script[/b][/i] [table][row][col]    [/col][col]Exécute le script ou la commande spécifiée par [i]script[/i] afin d'initialiser la ligne série. Ce script utilise typiquement le programme chat(8) pour configurer le modem pour autoriser la réponse automatique. Pour cette option, une valeur provenant d'une source privilégiée ne peut pas être remplacée par un utilisateur non privilégié.[/col][/row][/table] [b]lock[/b] [table][row][col]    [/col][col]Spécifie que pppd doit créer un fichier de verrouillage (lock) style UUCP pour le périphérique série, afin d'assurer un accès exclusif au périphérique.[/col][/row][/table] [b]mru [i]n[/b][/i] [table][row][col]    [/col][col]Règle la MRU [Unité Maximale de Réception, ou Maximum Receive Unit] à [i]n[/i]. Pppd demandera à son correspondant de ne pas envoyer de paquets de plus de [i]n[/i] octets. La valeur minimale est de 128, celle par défaut de 1500. Une valeur de 296 est recommandée pour les liens lents (40 octets pour l'en-tête TCP/IP + 256 octets de données). (Pour IPv6, la MRU minimale est de 1280)[/col][/row][/table] [b]mtu [i]n[/b][/i] [table][row][col]    [/col][col]Règle la MTU [Unité Maximale d'émission, ou Maximum Transmit Unit] à [i]n[/i]. À moins que le correspondant ne demande une valeur plus petite via la négociation MRU, pppd demandera au code réseau du noyau de limiter la taille des paquets émis sur l'interface PPP à[i]n[/i] octets. (Pour IPv6, la MTU minimale est 1280).[/col][/row][/table] [b]passive[/b] [table][row][col]    [/col][col]Active l'option "passive" du LCP. Avec cette option, pppd essaiera d'établir une connexion ; si aucune réponse n'est reçue du correspondant, pppd se contentera d'attendre passivement de celui-ci un paquet LCP valide, au lieu de s'arrêter, comme il le ferait sans cette option.[/col][/row][/table] [size=18] [b]Options[/b] [/size] [i]<adresse_IP_locale>[b]:[/b][i]<adresse_IP_distante>[/i][/i] [table][row][col]    [/col][col]Règle les adresses IP des interfaces locale et distante. L'une ou l'autre peut être omise. Les adresses IP peuvent être données par un nom d'hôte ou en notation décimale. L'adresse locale par défaut est la première adresse IP du système (à moins d'avoir spécifié l'option [i]noipdefault[/i]). L'adresse distante sera obtenue du correspondant si elle n'est spécifiée par aucune option ; ainsi, dans les cas simples, cette option n'est pas nécessaire. Si une adresse IP locale ou distante est spécifiée avec cette option, pppd n'acceptera pas du correspondant une valeur différente, à moins que l'option [i]ipcp-accept-local[/i] ou [i]ipcp-accept-remote[/i] (respectivement) ne soit passée.[/col][/row][/table] [b]ipv6 [i]<id_interface_locale>[/i],[i]<id_interface_distante>[/b][/i] [table][row][col]    [/col][col]Précise l'identificateur 64 bits d'interface locale ou distante. L'un ou l'autre peut être omis. L'identificateur doit être spécifié dans la notation standard des adresses IPv6 (par ex. ::dead:beef). Si l'option [i]ipv6cp-use-ipaddr[/i] est passée, l'identificateur local est l'adresse IPv4 locale (voir ci-dessus). Sur les systèmes qui supportent un identificateur persistant unique, comme l'EUI-48 dérivé de l'adresse MAC Ethernet, l'option [i]ipv6cp-use-persistent[/i] peut être utilisée en remplacement de [i]ipv6[/i] <local>,<distant>. Autrement, l'identificateur est tiré au hasard.[/col][/row][/table] [b]active-filter [i]expression-filtre[/b][/i] [table][row][col]    [/col][col]Spécifie un filtre à appliquer aux paquets de données, pour déterminer quels paquets doivent être considérés comme de l'activité sur le lien, et donc remettre à zéro le compteur de repos, ou déclencher l'activation du lien, en mode connexion à la demande (demand-dialing). Cette option est utile en conjonction avec l'option [b]idle[/b], s'il y a régulièrement des paquets envoyés ou reçus sur le lien (par exemple des informations de routage), qui sinon empêcheraient le lien d'apparaître au repos (idle). La syntaxe d'[i]expression-filtre[/i] est la même que celle décrite dans tcpdump(1), sauf que certains "qualificateurs" qui ne sont pas pertinents pour une ligne PPP, comme [b]ether[/b] et [b]arp[/b], ne sont pas autorisés. Généralement, l'expression-filtre doit être entre apostrophes pour empêcher les espaces dans l'expression d'être interprétés par le shell. Cette option est pour le moment disponible uniquement sous NetBSD, et seulement si le noyau et pppd ont été compilés tous deux avec l'option PPP_FILTER.[/col][/row][/table] [b]allow-ip [i]adress(es)[/b][/i] [table][row][col]    [/col][col]Permet aux correspondants d'utiliser l'adresse ou le sous-réseau IP donné sans s'authentifier. Le paramètre est analysé comme chaque élément de la liste des adresses IP autorisées, dans les fichiers "secrets" (voir la section AUTHENTIFICATION ci-dessous).[/col][/row][/table] [b]bsdcomp [i]nr,nt[/b][/i] [table][row][col]    [/col][col]Demande au correspondant de compresser les paquets qu'il envoie, en utilisant le schéma BSD-Compress, avec une longueur de code maximale de [i]nr[/i] bits, et dit à pppd de compresser les paquets envoyés au correspondant, avec une longueur de code maximale de [i]nt[/i] bits. Si [i]nt[/i] n'est pas précisé, il est pris égal à [i]nr[/i]. Des valeurs de 9 à 15 peuvent être utilisées pour ces paramètres. Des valeurs supérieures donnent une meilleure compression, mais consomment plus de mémoire noyau pour les dictionnaires de compression. Une valeur de 0 pour [i]nr[/i] ou [i]nt[/i] désactive toute compression dans la direction correspondante. Utilisez [i]nobsdcomp[/i] ou [i]bsdcomp[/i] 0 pour désactiver totalement la compression BSD-Compress.[/col][/row][/table] [b]cdtrcts[/b] [table][row][col]    [/col][col]Utilise un contrôle de flux matériel non standard (DTR/CTS) pour contrôler le flux de données sur le port série. Si aucune des options [i]crtscts[/i], [i]nocrtscts[/i], [i]cdtrcts[/i] et [i]nocdtrcts[/i] n'est passée, le contrôle de flux du port série est inchangé. Certains ports série (comme sur le Macintosh) manquent d'une vraie sortie RTS. Ces ports utilisent ce mode pour implémenter un vrai contrôle de flux bidirectionnel. L'inconvénient est que ce mode de contrôle ne permet plus d'utiliser DTR comme ligne de contrôle du modem.[/col][/row][/table] [b]chap-interval [i]n[/b][/i] [table][row][col]    [/col][col]Si cette option est passée, pppd relancera le "défi" d'authentification pour le correspondant toutes les [i]n[/i] secondes.[/col][/row][/table] [b]chap-max-challenge [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] le nombre maximal de transmissions de "défis" d'authentification CHAP (10 par défaut).[/col][/row][/table] [b]chap-restart [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] secondes le délai de redémarrage de CHAP (expiration de retransmission pour les défis). 3 secondes par défaut. [/col][/row][/table] [b]connect-delay [i]n[/b][/i] [table][row][col]    [/col][col]Attend jusqu'à [i]n[/i] millisecondes après la fin du script de connexion un paquet PPP valide du correspondant. Passé ce délai, ou à la réception d'un paquet PPP valide, pppd commencera sa négociation en envoyant son premier paquet LCP. La valeur par défaut est 1000 (1 seconde). Cette période d'attente ne s'applique qu'avec les options [b]connect[/b] et [b]pty[/b].[/col][/row][/table] [b]debug[/b] [table][row][col]    [/col][col]Active les sorties de débogage de la connexion. Si cette option est passée, pppd enregistrera sous une forme lisible les contenus de tous les paquets de contrôle émis ou reçus. Les paquets sont enregistrés par syslog, sous le service (facility) [i]daemon[/i] et la priorité [i]debug[/i]. Ces informations peuvent être envoyées directement vers un fichier en configurant correctement /etc/syslog.conf (voir syslog.conf(5)).[/col][/row][/table] [b]default-asyncmap[/b] [table][row][col]    [/col][col]Désactive la négociation asyncmap, en forçant la protection de tous les caractères de contrôle par une séquence d'échappement, dans les deux directions.[/col][/row][/table] [b]default-mru[/b] [table][row][col]    [/col][col]Désactive la négociation MRU [Maximum Receive Unit]. Avec cette option, pppd utilisera la valeur par défaut de 1500, dans les deux directions.[/col][/row][/table] [b]deflate [i]nr,nt[/b][/i] [table][row][col]    [/col][col]Demande au correspondant de compresser les paquets qu'il envoie, en utilisant le schéma Deflate, avec une taille de fenêtre maximale de [i]2^nr[/i] octets, et dit à pppd de compresser les paquets envoyés au correspondant, avec une taille maximale de [i]2^nt[/i] octets. Si [i]nt[/i] n'est pas précisé, il est pris égal à [i]nr[/i]. Des valeurs de 8 à 15 peuvent être utilisées pour ces paramètres. Des valeurs supérieures donnent une meilleure compression, mais consomment plus de mémoire noyau pour les dictionnaires de compression. Une valeur de 0 pour [i]nr[/i] ou [i]nt[/i] désactive toute compression dans la direction correspondante. Utilisez [i]nodeflate[/i] ou [i]deflate[/i] 0 pour désactiver totalement la compression Deflate. Note : si le correspondant gère aussi bien les compressions BSD-Compress que Deflate, pppd demande de préférence Deflate.[/col][/row][/table] [b]demand[/b] [table][row][col]    [/col][col]Établit le lien seulement à la demande, c'est-à-dire si du trafic est présent. Avec cette option, l'adresse IP distante doit être spécifiée par l'utilisateur sur la ligne de commande ou dans un fichier d'options. Pppd commencera par configurer l'interface et la rendre accessible au trafic IP, sans se connecter au correspondant, dans l'attente de trafic. À ce moment, pppd se connectera au correspondant, entreprendra la négociation et l'authentification, etc. Ensuite, il fera passer les paquets IP sur le lien. L'option [i]demand[/i] implique l'option [i]persist[/i]. Si ce comportement est indésirable, utilisez l'option [i]nopersist[/i] après [i]demand[/i]. Les options [i]idle[/i] et [i]holdoff[/i] sont également utiles en conjonction avec [i]demand[/i].[/col][/row][/table] [b]domain [i]d[/b][/i] [table][row][col]    [/col][col]Ajoute le nom de domaine [i]d[/i] à l'hôte local, à des fins d'authentification. Par exemple, si gethostname() retourne le nom porsche, mais que le nom de domaine pleinement qualifié est porsche.quotron.com, vous pouvez spécifier [i]domain[/i] quotron.com. Pppd utilisera alors le nom [i]porsche.quotron.com[/i] pour chercher les secrets dans le fichier secrets, et comme nom par défaut à envoyer au correspondant pour s'authentifier auprès du correspondant. Cette option est considérée comme privilégiée.[/col][/row][/table] [b]hide-password[/b] [table][row][col]    [/col][col]Lors de l'enregistrement (log) des paquets PAP, cette option dit à pppd d'exclure la chaîne mot de passe de l'enregistrement. Comportement par défaut.[/col][/row][/table] [b]holdoff [i]n[/b][/i] [table][row][col]    [/col][col]Spécifie combien de secondes pppd doit attendre avant de relancer le lien, après sa fin. Cette option n'a d'effet que si l'option [i]persist[/i] ou [i]demand[/i] est utilisée. La période de "raccrochage" (holdoff) n'est pas appliquée si le lien s'est terminé parce qu'il était au repos (idle).[/col][/row][/table] [b]idle [i]n[/b][/i] [table][row][col]    [/col][col]Spécifie à pppd de déconnecter si le lien est au repos pendant [i]n[/i] secondes. Le lien est au repos quand aucun paquet de données n'est reçu, ni envoyé. Il n'est pas conseillé d'utiliser cette option avec l'option [i]persist[/i] sans l'option [i]demand[/i]. Si l'option [b]active-filter[/b] est passée, les paquets de données qui sont rejetés par le filtre sont considérés comme un lien au repos.[/col][/row][/table] [b]ipcp-accept-local[/b] [table][row][col]    [/col][col]Avec cette option, pppd acceptera le choix de votre correspondant pour votre adresse IP, même si l'adresse IP locale est spécifiée dans une option.[/col][/row][/table] [b]ipcp-accept-remote[/b] [table][row][col]    [/col][col]Avec cette option, pppd acceptera l'opinion de votre correspondant sur sa propre adresse IP, même si l'adresse IP distante est spécifiée dans une option.[/col][/row][/table] [b]ipcp-max-configure [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] (10 par défaut) le nombre maximal d'émissions IPCP configure-request.[/col][/row][/table] [b]ipcp-max-failure [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] (10 par défaut) le nombre maximal de configure-NAKs IPCP (non-acquittement) retournés avant d'envoyer des configure-Rejects à la place.[/col][/row][/table] [b]ipcp-max-terminate [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] (3 par défaut) le nombre maximal d'émissions IPCP terminate-request.[/col][/row][/table] [b]ipcp-restart [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] secondes (3 s par défaut) le délai de relance IPCP (IPCP restart = expiration de réémission).[/col][/row][/table] [b]ipparam [i]chaîne[/b][/i] [table][row][col]    [/col][col]Fournit un paramètre supplémentaire aux scripts ip-up et ip-down. Avec cette option, la [i]chaîne[/i] fournie est passée en 6e paramètre à ces scripts. [NdT : utile pour passer l'uid de l'appelant par exemple][/col][/row][/table] [b]ipv6cp-max-configure [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] (10 par défaut) le nombre maximal d'émissions IPv6CP configure-request.[/col][/row][/table] [b]ipv6cp-max-failure [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] (10 par défaut) le nombre maximal de configure-NAKs IPv6CP (non-acquittement) retournés avant d'envoyer des configure-Rejects à la place.[/col][/row][/table] [b]ipv6cp-max-terminate [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] (3 par défaut) le nombre maximal d'émissions IPv6CP terminate-request.[/col][/row][/table] [b]ipv6cp-restart [i]n[/b][/i] [table][row][col]    [/col][col]Règle à [i]n[/i] secondes (3 s par défaut) le délai de relance IPv6CP (IPv6CP restart = expiration de réémission).[/col][/row][/table] [b]ipx[/b] [table][row][col]    [/col][col]Active les protocoles IPXCP et IPX. Cette option n'est pour l'instant supportée que sous Linux, et si votre noyau inclut le support IPX.[/col][/row][/table] [b]ipx-network [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i], un nombre hexadécimal (sans 0x), le numéro de réseau IPX dans la trame IPXCP configure-request. Il n'y a pas de valeur par défaut définie. Si cette option n'est pas spécifiée, le numéro de réseau est obtenu du correspondant. S'il ne fournit pas de numéro de réseau, le protocole IPX ne sera pas démarré.[/col][/row][/table] [b]ipx-node [i]n[/i][b]:[/b][i]m[/b][/i] [table][row][col]    [/col][col]Fixe les numéros de n½ud IPX, les deux numéros séparés par un double point. Le premier, [i]n[/i], est le numéro de noeud local ; le second, [i]m[/i], est le numéro de noeud du correspondant. Chaque numéro de noeud est un nombre hexadécimal, d'au plus 10 chiffres (5 octets). Les numéros de noeud sur le réseau ipx doivent être uniques. Il n'y a pas de valeur par défaut définie. Si cette option n'est pas spécifiée, les numéros de noeud sont obtenus du correspondant.[/col][/row][/table] [b]ipx-router-name [i]<chaîne>[/b][/i] [table][row][col]    [/col][col]Fixe le nom du routeur. C'est une chaîne envoyée au correspondant en tant que données d'information.[/col][/row][/table] [b]ipx-routing [i]n[/b][/i] [table][row][col]    [/col][col]Fixe le protocole de routage. Plusieurs instances d'[i]ipx-routing[/i] peuvent être spécifiées. L'option '[i]none[/i]' (0) peut être spécifiée comme seule instance d'[i]ipx-routing[/i]. Les valeurs peuvent être [i]0[/i] pour [i]NONE[/i], [i]2[/i] pour [i]RIP/SAP[/i], et [i]4[/i] pour [i]NLSP[/i].[/col][/row][/table] [b]ipxcp-accept-local[/b] [table][row][col]    [/col][col]Accepte un NAK (non-acquittement) du correspondant sur le numéro de noeud spécifié par l'option ipx-node. Si un numéro de n½ud est spécifié, et non nul, le comportement par défaut est d'insister pour que ce soit la valeur utilisée. Si vous passez cette option, vous permettez au correspondant de passer outre la valeur entrée du numéro de noeud.[/col][/row][/table] [b]ipxcp-accept-network[/b] [table][row][col]    [/col][col]Accepte un NAK (non-acquittement) du correspondant sur le numéro de réseau spécifié par l'option ipx-network. Si un numéro de réseau est spécifié, et non nul, le comportement par défaut est d'insister pour que ce soit la valeur utilisée. Si vous passez cette option, vous permettez au correspondant de passer outre la valeur entrée du numéro de réseau.[/col][/row][/table] [b]ipxcp-accept-remote[/b] [table][row][col]    [/col][col]Utilise le numéro de réseau du correspondant, tel qu'indiqué dans la trame configure-request. Si un numéro de réseau est spécifié pour le correspondant, et que cette option n'est pas passée, le correspondant est forcé d'utiliser le numéro de réseau que vous avez spécifié.[/col][/row][/table] [b]ipxcp-max-configure [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (10 par défaut) le nombre maximal de trames IPXCP configure-request que le système enverra.[/col][/row][/table] [b]ipxcp-max-failure [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (3 par défaut) le nombre maximal de trames IPXCP NAK que le système enverra avant de rejeter les options.[/col][/row][/table] [b]ipxcp-max-terminate [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (3 par défaut) le nombre maximal de trames IPXCP terminate-request avant que le système local considère que le correspondant ne l'écoute pas.[/col][/row][/table] [b]kdebug [i]n[/b][/i] [table][row][col]    [/col][col]Active le code de débogage du pilote PPP au niveau noyau. L'argument [i]n[/i] est un nombre qui est la somme des valeurs suivantes : 1 pour les messages généraux de débogage, 2 pour demander que le contenu des paquets reçus soit imprimé, et 4 pour le contenu des paquets envoyés. Sur la plupart des systèmes, les messages envoyés par le noyau sont journalisés par syslog(1) dans un fichier, selon le fichier de configuration /etc/syslog.conf.[/col][/row][/table] [b]ktune[/b] [table][row][col]    [/col][col]Permet à pppd de modifier les paramètres du noyau selon ce qui est nécessaire. Sous Linux, pppd activera l'IP forwarding (en mettant à 1 /proc/sys/net/ipv4/ip_forward) si l'option [i]proxyarp[/i] est utilisée, et l'option d'adresse IP dynamique (en mettant à 1 /proc/sys/net/ipv4/ip_dynaddr) en mode connexion à la demande si l'adresse locale change.[/col][/row][/table] [b]lcp-echo-failure [i]n[/b][/i] [table][row][col]    [/col][col]Si cette option est passée, pppd supposera que le correspondant est mort si [i]n[/i] echo-requests LCP sont envoyés sans qu'un echo-reply LCP valide ne soit reçu. Si c'est le cas, pppd coupera la connexion. Cette option nécessite une valeur non nulle pour [i]lcp-echo-interval[/i]. Cette option peut permettre à pppd de se terminer après la fin de la connexion physique (ex : raccrochage modem), dans des cas où aucune ligne de contrôle matériel du modem n'est disponible.[/col][/row][/table] [b]lcp-echo-interval [i]n[/b][/i] [table][row][col]    [/col][col]Si cette option est passée, pppd enverra une trame LCP echo-request au correspondant toutes les [i]n[/i] secondes. Normalement, le correspondant doit répondre par une LCP echo-reply. Cette option peut être utilisée en conjonction avec l'option [i]lcp-echo-failure[/i] pour détecter que le correspondant n'est plus connecté.[/col][/row][/table] [b]lcp-max-configure [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (10 par défaut) le nombre maximal d'émissions LCP configure-request.[/col][/row][/table] [b]lcp-max-failure [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (10 par défaut) le nombre maximal de configure-NAKs retournés avant de commencer à envoyer des configure-Rejects à la place.[/col][/row][/table] [b]lcp-max-terminate [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (10 par défaut) le nombre maximal d'émissions LCP terminate-request.[/col][/row][/table] [b]lcp-restart [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] secondes (3 s par défaut) le délai LCP restart (dépassement de temps de retransmission).[/col][/row][/table] [b]linkname [i]nom[/i][/b] [table][row][col]    [/col][col]Fixe à [i]nom[/i] le nom logique du lien. Pppd créera un fichier nommé [b]ppp-[/b][i]nom[/i][b].pid[/b] dans /var/run (ou /etc/ppp sur certains systèmes), contenant son ID de processus. Ce peut être utile pour déterminer quelle instance de pppd est responsable du lien vers un correspondant donné. C'est une option privilégiée.[/col][/row][/table] [b]local[/b] [table][row][col]    [/col][col]N'utilise pas les lignes de contrôle du modem. Avec cette option, pppd ignorera l'état du signal CD (Carrier Detect = détection de porteuse) en provenance du modem, et ne modifiera pas l'état du signal DTR (Data Terminal Ready = terminal prêt).[/col][/row][/table] [b]logfd [i]n[/b][/i] [table][row][col]    [/col][col]Envoie les messages de log au descripteur de fichier [i]n[/i]. Pppd enverra les messages de log (outre leur envoi à syslog) à au plus un fichier OU descripteur de fichier, donc cette option et l'option [b]logfile[/b] sont exclusives l'une de l'autre. Le comportement par défaut de pppd est d'envoyer les messages de log à stdout (fd=1), à moins que le port série ne soit déjà ouvert sur stdout.[/col][/row][/table] [b]logfile [i]nomfichier[/b][/i] [table][row][col]    [/col][col]Ajoute les messages de log (outre leur envoi à syslog) au fichier [i]nomfichier[/i]. Le fichier est ouvert avec les droits de l'utilisateur qui a invoqué pppd, en mode append (ajout).[/col][/row][/table] [b]login[/b] [table][row][col]    [/col][col]Utilise la base de mots de passe pour authentifier le correspondant, en utilisant le protocole PAP, et enregistre l'utilisateur dans le fichier système wtmp. Notez que le correspondant doit avoir une entrée dans le fichier /etc/ppp/pap-secrets et dans la base des mots de passe du système pour être autorisé à se connecter.[/col][/row][/table] [b]maxconnect [i]n[/b][/i] [table][row][col]    [/col][col]Termine la connexion après [i]n[/i] secondes de disponibilité pour le trafic réseau (c.-à-d. [i]n[/i] secondes après la première trame de NCP, protocole de contrôle réseau).[/col][/row][/table] [b]maxfail [i]n[/b][/i] [table][row][col]    [/col][col]Arrête les tentatives de connexion après [i]n[/i] (10 par défaut) échecs consécutifs. Une valeur de 0 signifie aucune limite.[/col][/row][/table] [b]modem[/b] [table][row][col]    [/col][col]Utilise les lignes de contrôle du modem. C'est le comportement par défaut. Avec cette option, pppd attendra de recevoir le signal CD (détection de porteuse) du modem pour ouvrir le périphérique série, à moins qu'un script de connexion ne soit spécifié, et il abaissera brièvement le signal DTR (terminal prêt) quand le connexion sera terminée, et avant d'exécuter le script de connexion. Sous Ultrix, cette option implique un contrôle de flux matériel, comme l'option [i]crtscts[/i].[/col][/row][/table] [b]ms-dns [i]<adr>[/b][/i] [table][row][col]    [/col][col]Si pppd est utilisé comme serveur pour des clients Microsoft Windows, cette option permet de leur fournir une ou deux adresses de DNS. La première instance de cette option spécifie l'adresse du DNS primaire, et la deuxième (le cas échéant) celle du DNS secondaire. (Cette option était présente dans des versions précédentes de pppd sous le nom [b]dns-addr[/b].)[/col][/row][/table] [b]ms-wins [i]<adr>[/b][/i] [table][row][col]    [/col][col]Si pppd est utilisé comme serveur pour des clients Microsoft Windows ou Samba, cette option permet de leur fournir une ou deux adresses de serveurs WINS (Windows Internet Name Service). La première instance de cette option spécifie l'adresse du WINS primaire, et la deuxième (le cas échéant) celle du WINS secondaire. [/col][/row][/table] [b]name [i]nom[/b][/i] [table][row][col]    [/col][col]Fixe à [i]nom[/i] le nom du système local, pour des usages d'authentification. C'est une option privilégiée. Avec cette option, pppd utilisera les lignes des fichiers secrets comportant [i]nom[/i] comme deuxième champ, lors de la recherche d'un secret à utiliser pour authentifier le correspondant. De plus, à moins d'être écrasé par l'option [i]user[/i], [i]nom[/i] sera utilisé comme nom à envoyer au correspondant lors de l'authentification du système local. (Notez que pppd n'ajoute pas le nom de domaine à [i]name[/i].)[/col][/row][/table] [b]netmask [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] le masque réseau de l'interface, un masque de 32 bits en "notation décimale pointée" (par ex. 255.255.255.0). Si cette option est passée, la valeur spécifiée est "ajoutée" (par un OR) avec le masque par défaut. Celui-ci est défini à partir de l'adresse IP distante négociée : c'est le masque approprié pour la classe de l'IP distante, composée (par un OR) avec les masques réseau de toutes les interfaces NON point à point du système qui sont sur le même réseau. (Note : sur certaines plates-formes, pppd utilisera toujours 255.255.255.255 comme masque réseau, si c'est la seule valeur appropriée pour une interface point-à-point).[/col][/row][/table] [b]noaccomp[/b] [table][row][col]    [/col][col]Désactive la compression Adresse/Contrôle dans les deux directions.[/col][/row][/table] [b]noauth[/b] [table][row][col]    [/col][col]Ne demande pas au correspondant de s'authentifier. Cette option est privilégiée.[/col][/row][/table] [b]nobsdcomp[/b] [table][row][col]    [/col][col]Désactive la compression BSD-Compress ; [b]pppd[/b] ne demandera, ni n'acceptera de compresser les paquets à l'aide du schéma BSD-Compress.[/col][/row][/table] [b]noccp[/b] [table][row][col]    [/col][col]Désactive la négociation CCP (Compression Control Protocol). Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation CCP.[/col][/row][/table] [b]nocrtscts[/b] [table][row][col]    [/col][col]Désactive le contrôle de flux matériel (RTS/CTS) sur le port série. Si aucune des options [i]crtscts[/i], [i]nocrtscts[/i], [i]dtrcts[/i], [i]nodtrcts[/i] n'est passée, le contrôle de flux matériel sur le port série reste inchangé.[/col][/row][/table] [b]nodtrcts[/b] [table][row][col]    [/col][col]Cette option est synonyme de [i]nocrtscts[/i]. Chacune de ces options désactive toute forme de contrôle de flux matériel.[/col][/row][/table] [b]nodefaultroute[/b] [table][row][col]    [/col][col]Désactive l'option [i]defaultroute[/i]. L'administrateur système désireux d'empêcher toute création de routes par défaut par un utilisateur avec pppd peut le faire en plaçant cette option dans le fichier /etc/ppp/options.[/col][/row][/table] [b]nodeflate[/b] [table][row][col]    [/col][col]Désactive la compression Deflate ; pppd ne demandera ni n'acceptera de compresser les paquets à l'aide du schéma Deflate.[/col][/row][/table] [b]nodetach[/b] [table][row][col]    [/col][col]Ne se détache pas du terminal de contrôle. Sans cette option, si un périphérique série autre que le terminal sur l'entrée standard est spécifié, pppd se passera en tâche de fond (via un fork).[/col][/row][/table] [b]noip[/b] [table][row][col]    [/col][col]Désactive la négociation IPCP et la communication IP. Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation IPCP.[/col][/row][/table] [b]noipv6[/b] [table][row][col]    [/col][col]Désactive la négociation IPv6CP et la communication IPv6. Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation IPv6CP.[/col][/row][/table] [b]noipdefault[/b] [table][row][col]    [/col][col]Désactive le comportement par défaut quand aucune adresse IP locale n'est spécifiée, qui est de déterminer (si possible) l'adresse IP locale à partir du nom d'hôte. Avec cette option, le correspondant devra fournir l'adresse IP locale durant la négociation IPCP (sauf spécification explicite en ligne de commande ou dans un fichier d'options).[/col][/row][/table] [b]noipx[/b] [table][row][col]    [/col][col]Désactive les protocoles IPXCP et IPX. Cette option ne devrait être utilisée que si le correspondant est bogué et est perturbé par les requêtes de pppd concernant la négociation IPXCP.[/col][/row][/table] [b]noktune[/b] [table][row][col]    [/col][col]L'opposé de l'option [i]ktune[/i] ; empêche pppd de changer les paramètres noyau.[/col][/row][/table] [b]nolog[/b] [table][row][col]    [/col][col]N'envoie les messages de log à aucun fichier, ni descripteur de fichier. Cette option annule les options [b]logfd[/b] et [b]logfile[/b].[/col][/row][/table] [b]nomagic[/b] [table][row][col]    [/col][col]Désactive la négociation de "nombre magique". Avec cette option, pppd ne peut pas détecter une ligne en boucle (locale). Cette option ne devrait être utilisée que si le correspondant est bogué.[/col][/row][/table] [b]nopcomp[/b] [table][row][col]    [/col][col]Désactive la négociation de compression du champ protocole, dans les deux directions.[/col][/row][/table] [b]nopersist[/b] [table][row][col]    [/col][col]S'arrête dès qu'une connexion a eu lieu et s'est terminée. C'est l'option par défaut, à moins que l'option [i]persist[/i] ou [i]demand[/i] n'ait été spécifiée.[/col][/row][/table] [b]nopredictor1[/b] [table][row][col]    [/col][col]Ne demande ni n'accepte la compression Predictor-1.[/col][/row][/table] [b]noproxyarp[/b] [table][row][col]    [/col][col]Désactive l'option [i]proxyarp[/i]. L'administrateur système qui désire empêcher les utilisateurs de créer des entrées proxy ARP par pppd peut le faire en spécifiant cette option dans le fichier /etc/ppp/options.[/col][/row][/table] [b]notty[/b] [table][row][col]    [/col][col]Normalement, pppd exige un terminal en périphérique. Avec cette option, pppd s'alloue lui-même une paire maître/esclave pseudo-terminal et utilise l'esclave comme terminal périphérique. Pppd créera un processus fils pour servir de "relai caractère", transférant les caractères entre le pseudo-tty maître et ses entrée et sortie standard. Ainsi, pppd enverra des caractères sur sa sortie standard et les recevra sur son entrée standard, même si ce ne sont pas des terminaux. Cette option augmente évidemment le temps de latence, et la charge CPU du transfert de données par l'interface ppp. Aucun nom de périphérique explicite ne doit être passé si cette option est utilisée.[/col][/row][/table] [b]novj[/b] [table][row][col]    [/col][col]Désactive la compression d'en-tête TCP/IP de Van Jacobson dans les deux directions.[/col][/row][/table] [b]novjccomp[/b] [table][row][col]    [/col][col]Désactive l'option de compression de l'ID-connexion dans la compression Van Jacobson de l'en-tête TCP/IP. Avec cette option, pppd n'omettra pas l'octet ID-connexion des en-têtes TCP/IP compressés Van Jacobson, ni ne demandera au correspondant de le faire.[/col][/row][/table] [b]papcrypt[/b] [table][row][col]    [/col][col]Indique que tous les secrets du fichier /etc/ppp/pap-secrets qui sont utilisés pour authentifier le correspondant sont encryptés, et donc que pppd ne doit pas accepter de mot de passe qui, avant encryptage, est identique au secret trouvé dans le fichier /etc/ppp/pap-secrets.[/col][/row][/table] [b]pap-max-authreq [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (10 par défaut) le nombre maximal d'émissions de requêtes d'authentification PAP.[/col][/row][/table] [b]pap-restart [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] secondes (3s par défaut) le délai de relancement de PAP (expiration de réémission).[/col][/row][/table] [b]pap-timeout [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] secondes (0 = aucune limite) le temps maximum que pppd attendra pour que le correspondant s'authentifie.[/col][/row][/table] [b]pass-filter [i]expression-filtre[/b][/i] [table][row][col]    [/col][col]Spécifie un filtre à appliquer aux paquets de données envoyés et reçus, pour déterminer lesquels sont autorisés à passer. Les paquets rejetés par le filtre sont purement oubliés. Cette option peut être utilisée pour empêcher certains démons réseau (comme routed) d'activer le lien ppp pour rien, ou pour fournir des capacités pare-feu de base. La syntaxe d'[i]expression-filtre[/i] est décrite dans tcpdump(1), sauf que les qualificateurs qui ne sont pas pertinents pour une liaison PPP, comme [b]ether[/b] et [b]arp[/b], ne sont pas autorisés. Généralement, l'expression-filtre doit être entre guillemets pour éviter que les blancs ne soient interprétés par le shell. Notez qu'il est possible d'appliquer des contraintes différentes aux paquets entrants et sortants, en utilisant les qualificateurs [b]inbound[/b] et [b]outbound[/b]. Cette option n'est pour l'instant disponible que sous NetBSD, et seulement si le noyau et pppd ont tous deux été compilés avec PPP_FILTER défini.[/col][/row][/table] [b]persist[/b] [table][row][col]    [/col][col]Ne s'arrête pas à la fin d'une connexion ; essaie plutôt de la rouvrir.[/col][/row][/table] [b]plugin [i]nomfichier[/b][/i] [table][row][col]    [/col][col]Charge la bibliothèque partagée de [i]nomfichier[/i] en module (plugin). C'est une option privilégiée.[/col][/row][/table] [b]predictor1[/b] [table][row][col]    [/col][col]Demande au correspondant de compresser les trames qu'il envoie avec le schéma Predictor-1, et accepte d'envoyer des trames ainsi compressées en cas de demande. Cette option n'a d'effet que si le pilote noyau gère la compression Predictor-1.[/col][/row][/table] [b]privgroup [i]nom-groupe[/b][/i] [table][row][col]    [/col][col]Permet aux membres du groupe [i]nom-groupe[/i] d'utiliser les options privilégiées. C'est une option privilégiée ! Cette option est à manipuler avec précaution, car il n'y a pas de garantie que les membres de [i]nom-groupe[/i] ne puissent utiliser pppd pour devenir root. Considérez que c'est équivalent à mettre les membres de [i]nom-groupe[/i] dans le groupe kmem ou disk.[/col][/row][/table] [b]proxyarp[/b] [table][row][col]    [/col][col]Ajoute une entrée à la table ARP [Address Resolution Protocol] de ce système, avec l'adresse IP du correspondant et l'adresse ethernet du système local. Cela aura pour effet de faire croire aux autres systèmes du réseau local ethernet que le correspondant est sur le même réseau physique.[/col][/row][/table] [b]pty [i]script[/b][/i] [table][row][col]    [/col][col]Spécifie que le [i]script[/i] de commandes doit être utilisé pour communiquer, au lieu d'un périphérique terminal spécifique. Pppd s'allouera une paire maître/esclave pseudo-tty et utilisera l'esclave comme terminal périphérique. Le [i]script[/i] sera lancé comme processus fils, avec pour entrée/sortie standard le pseudo-tty maître. Aucun nom de périphérique explicite ne doit être donné si cette option est utilisée. (Note : si l'option [i]record[/i] est utilisée en conjonction avec celle-ci, le processus fils aura des pipes sur ses entrée/sortie standard).[/col][/row][/table] [b]receive-all[/b] [table][row][col]    [/col][col]Avec cette option, pppd acceptera du correspondant tous les caractères de contrôle, y compris ceux marqués dans l'asyncmap de réception. Sans cette option, pppd rejettera ces caractères, comme il est spécifié dans le RFC1662. Cette option ne devrait être utilisée que si le correspondant est bogué.[/col][/row][/table] [b]record [i]nomfichier[/b][/i] [table][row][col]    [/col][col]Spécifie que pppd doit enregistrer tous les caractères envoyés et reçus dans le fichier [i]nomfichier[/i]. Ce fichier est ouvert en mode append (ajout), avec l'UID et les permissions de l'utilisateur. Cette option est implémentée en utilisant un pseudo-tty et un processus pour transférer les caractères entre le pseudo-tty et le périphérique série réel, donc elle augmente la charge CPU et le temps de latence du transfert de données par l'interface ppp. Les caractères sont stockées dans un format balisé, avec horodatage, qui peut être consulté par la suite grâce au programme pppdump(8).[/col][/row][/table] [b]remotename [i]nom[/b][/i] [table][row][col]    [/col][col]Fixe à [i]nom[/i] le nom supposé du système distant, en vue de l'authentification.[/col][/row][/table] [b]refuse-chap[/b] [table][row][col]    [/col][col]Avec cette option, pppd refusera de s'authentifier auprès du correspondant via CHAP.[/col][/row][/table] [b]refuse-pap[/b] [table][row][col]    [/col][col]Avec cette option, pppd refusera de s'authentifier auprès du correspondant via PAP.[/col][/row][/table] [b]require-chap[/b] [table][row][col]    [/col][col]Demande à l'hôte de s'authentifier via CHAP (Challenge Handshake Authentication Protocol).[/col][/row][/table] [b]require-pap[/b] [table][row][col]    [/col][col]Demande à l'hôte de s'authentifier via PAP (Password Authentication Protocol).[/col][/row][/table] [b]show-password[/b] [table][row][col]    [/col][col]Pendant l'enregistrement (log) des paquets PAP, cette option force pppd à montrer en clair le mot de passe dans le message de log.[/col][/row][/table] [b]silent[/b] [table][row][col]    [/col][col]Avec cette option, pppd n'enverra pas de paquets LCP pour démarrer une connexion jusqu'à ce qu'un paquet LCP valide soit reçu du correspondant (comme pour l'option 'passive' des anciennes versions de pppd).[/col][/row][/table] [b]sync[/b] [table][row][col]    [/col][col]Utilise l'encodage série HDLC synchrone au lieu d'asynchrone. Supporte actuellement les adaptateurs Microgate Synclink sous Linux et FreeBSD 2.2.8 et plus récents.[/col][/row][/table] [b]updetach[/b] [table][row][col]    [/col][col]Avec cette option, pppd se détache de son terminal de contrôle dès que la connexion ppp est établie (au moment où le premier protocole réseau, en général IP, se met en place).[/col][/row][/table] [b]usehostname[/b] [table][row][col]    [/col][col]Force l'utilisation du nom d'hôte (avec ajout du nom de domaine s'il est donné) comme nom du système local, pour l'authentification (écrase l'option [i]name[/i]). Cette option n'est normalement pas nécessaire, puisque l'option [i]name[/i] est privilégiée.[/col][/row][/table] [b]usepeerdns[/b] [table][row][col]    [/col][col]Demande au correspondant une ou deux adresses de serveurs DNS. Les adresses fournies (le cas échéant) sont passées au script /etc/ppp/ip-up dans les variables d'environnement DNS1 et DNS2. En plus, pppd créera un fichier /etc/ppp/resolv.conf contenant une ou deux lignes de serveurs de nom, avec les adresses fournies.[/col][/row][/table] [b]user [i]nom[/b][/i] [table][row][col]    [/col][col]Fixe à [i]nom[/i] le nom utilisé pour authentifier le système local auprès du correspondant.[/col][/row][/table] [b]vj-max-slots [i]n[/b][/i] [table][row][col]    [/col][col]Fixe à [i]n[/i] (entre 2 et 16, inclus) le nombre maximal de slots de connexion à utiliser par le code de (dé)compression des en-têtes TCP/IP de Van Jacobson. [/col][/row][/table] [b]welcome [i]script[/b][/i] [table][row][col]    [/col][col]Lance l'exécutable ou la commande shell spécifié par [i]script[/i] avant de commencer la négociation PPP, et après le script de connexion (le cas échéant). Une valeur de cette option spécifiée par une source privilégiée ne peut pas être outrepassée par un utilisateur non privilégié.[/col][/row][/table] [b]xonxoff[/b] [table][row][col]    [/col][col]Utilise le contrôle de flux logiciel (c.-à-d. XON/XOFF) sur le port série.[/col][/row][/table] [size=18] [b]Options[/b] [/size] Les options peuvent être spécifiées dans des fichiers ou sur la ligne de commande. Pppd lit les options dans les fichiers /etc/ppp/options, ~/.ppprc et /etc/ppp/options.[i]nomtty[/i] (dans cet ordre) avant de traiter les options de la ligne de commande. (En réalité, les options de la ligne de commande sont d'abord parcourues une fois, pour trouver le nom du terminal, avant que options.[i]nomtty[/i] ne soit lu). Pour former le nom du fichier options.[i]ttyname[/i], le "/dev/" initial est supprimé, et tout caractère / restant est remplacé par un point. Un fichier d'option est analysé en une série de mots, délimités par des blancs. Un blanc peut être inclus dans un mot en plaçant le mot entre guillemets ("") Un backslash () protège le caractère suivant. Un dièse (#) signale un commentaire, qui continue jusqu'à la fin de la ligne. Il n'y a aucune restriction à utiliser les options [i]file[/i] ou [i]call[/i] à l'intérieur d'un fichier d'options. [size=18] [b]SÉcuritÉ[/b] [/size] [i]pppd[/i] fournit à l'administration système un contrôle d'accès suffisant pour autoriser un accès PPP sur une machine serveur à des utilisateurs légitimes, sans compromettre la sécurité du serveur, ni celle du réseau local. Ce contrôle est fourni par les restrictions sur les adresses IP que peut utiliser le correspondant, fondées sur son identité authentifiée (le cas échéant) et sur les restrictions imposées aux options que peut employer un utilisateur non privilégié. Plusieurs options de pppd sont privilégiées, en particulier celles qui permettent d'établir des configurations potentiellement non sûres. Ces options ne sont acceptées que dans des fichiers qui sont sous le contrôle de l'administrateur système, ou si pppd est lancé par root. Le comportement par défaut de pppd est de ne permettre à un correspondant non authentifié d'utiliser une adresse IP donnée que si le système n'a pas déjà de route vers cette adresse. Par exemple, un système avec une connexion permanente vers l'Internet a normalement une route par défaut, et donc tous les correspondants devront s'authentifier pour établir une connexion. Sur un tel système, l'option [i]auth[/i] est activée par défaut. Réciproquement, un système où un lien PPP est la seule connexion à l'Internet n'a normalement pas de route par défaut, donc le correspondant aura le droit d'utiliser presque toute adresse IP sans s'authentifier. Comme indiqué ci-dessus, certaines options sensibles du point de vue sécurité sont privilégiées, c'est-à-dire qu'elle ne peuvent pas être employées par un utilisateur ordinaire non privilégié, lançant un pppd setuid-root, soit sur la ligne de commande soit dans un fichier de configuration utilisateur comme ~/.ppprc ou lu par l'option [i]file[/i]. Les options privilégiées peuvent être utilisées dans le fichier /etc/ppp/options ou dans tout fichier d'options lu par l'option [i]call[/i]. Si pppd est lancé par root, les options privilégiées peuvent être utilisées sans restriction. Quand il ouvre un périphérique, pppd utilise soit l'uid de l'utilisateur réel, soit l'uid root (0), selon que le nom de périphérique a été spécifié par l'utilisateur ou par l'administrateur. Si le nom de périphérique provient d'une source privilégiée (/etc/ppp/options ou un fichier lu par l'option [i]call[/i]), pppd utilise les privilèges root pour ouvrir le périphérique. Ainsi, en créant un fichier approprié sous /etc/ppp/peers, l'administrateur système peut permettre à des utilisateurs d'établir une connexion ppp via un périphérique auquel ils n'ont normalement pas accès. Dans les autres cas, pppd utilise l'UID réel de l'utilisateur appelant pour ouvrir le périphérique. [size=18] [b]Authentification[/b] [/size] L'authentification est le processus par lequel l'un des systèmes convainc l'autre de son identité. Cela implique que le premier système envoie au second son nom, accompagné d'une information secrète qui ne peut être connue que de l'utilisateur patenté de ce nom. Dans un tel échange, le premier système est appelé "client" et l'autre, "serveur". Le client a un nom grâce auquel il s'identifie auprès du serveur, et la réciproque est vraie. Généralement, le client patenté partage un secret (ou mot de passe) avec le serveur, et s'authentifie en prouvant qu'il le connaît. Très souvent, les noms utilisés pour l'authentification correspondent aux noms d'hôte internet des systèmes, mais ce n'est pas fondamental.     Actuellement, pppd supporte deux protocoles d'authentification : PAP (Password Authentication Protocol, ou authentification par mot de passe) et CHAP (Challenge Handshake Authentication Protocol, authentification par "défi à relever"). PAP implique que le client envoie son nom et un mot de passe en clair pour s'authentifier. Avec CHAP, c'est le serveur qui initie l'échange en envoyant au client un défi (et le nom du serveur). Le client doit répondre avec son nom, plus une valeur de hachage dérivée du secret partagé et du défi, afin de prouver qu'il connaît le secret.     Comme le protocole PPP est symétrique, il permet aux deux correspondants d'exiger chacun que l'autre s'authentifie. Dans ce cas, deux échanges séparés et indépendants auront lieu. Les deux peuvent utiliser des protocoles différents et, en principe, des noms différents peuvent être utilisés lors des deux échanges.     Le comportement par défaut de pppd est d'accepter de s'authentifier si on le lui demande, et de ne pas exiger d'authentification de son correspondant. Cependant, pppd n'acceptera pas de s'authentifier par un protocole particulier s'il ne connaît pas de secret qui le lui permette.     Pppd stocke les secrets à utiliser lors de l'authentification dans les fichiers secrets (/etc/ppp/pap-secrets pour PAP, /etc/ppp/chap-secrets pour CHAP). Les deux fichiers ont le même format. Les fichiers secrets peuvent aussi bien contenir les secrets à utiliser pour authentifier le système local auprès des correspondants que ceux utilisés pour authentifier les correspondants.     Chaque ligne d'un fichier de secrets contient un secret. Un secret donné est spécifique d'une paire client-serveur : il ne peut être utilisé que pour authentifier ce client auprès de ce serveur. Chaque ligne dans un fichier secrets a au moins 3 champs : le nom du client, le nom du serveur, et le secret. Ces champs peuvent être suivis par une liste d'adresses IP que le client spécifié peut utiliser pour se connecter au serveur spécifié.     Un fichier secrets est analysé en mots, comme un fichier d'options, donc le nom du client, le nom du serveur et le champ secret doivent être constitué d'un mot chacun, les blancs et autres caractères spéciaux devant être protégés par des guillemets ou un . Notez que la casse est importante dans les noms de client et de serveur, et dans les secrets.     Si le secret commence par un `@', ce qui suit est pris comme le nom d'un fichier dans lequel lire le secret. Un "" dans le nom du client ou du serveur correspond à n'importe quel nom. Quand il sélectionne un secret, pppd prend celui qui correspond le mieux, c'est-à-dire celui avec le moins de jokers.     Tous les mots suivants sur la même ligne sont pris comme liste d'adresses IP acceptables pour le client correspondant. S'il n'y a que trois mots sur une ligne, ou si le premier mot est "-", toutes les adresses IP sont interdites. Pour autoriser toutes les adresses, utilisez "". Un mot commençant par "!" indique que l'adresse suivante n'est [i]pas[/i] acceptable. Une adresse peut être suivie par un "/" et un nombre [i]n[/i], pour spécifier tout un sous-réseau, c'est-à-dire toutes les adresses qui ont les mêmes [i]n[/i] bits de poids fort. Avec cette forme, l'adresse peut être suivie d'un signe "+" pour indiquer qu'une adresse du sous-réseau est autorisée, basée sur le numéro d'unité de l'interface ppp utilisée. Dans ce cas, la partie hôte de l'adresse sera fixée au numéro d'unité plus un. [NdT : en clair, avec une adresse de 172.16.0.0/16+, l'interface ppp0 utilisera l'adresse 172.16.0.1, ppp1 utilisera 172.16.0.2, etc.]     Ainsi un fichier de secrets contient à la fois les secrets à utiliser pour authentifier les autres hôtes et les secrets utilisés pour s'authentifier auprès des autres. Quand pppd authentifie son correspondant (c'est-à-dire vérifie son identité), il choisit un secret avec le nom du correspondant dans le premier champ et le nom du système local dans le deuxième champ. Le nom du système local est par défaut le nom d'hôte, flanqué du nom de domaine si l'option [i]domain[/i] est passée. Ce comportement par défaut peut être outrepassé par l'option [i]name[/i], sauf si l'option [i]usehostname[/i] est utilisée.     Quand pppd choisit un secret pour s'authentifier auprès du correspondant, il commence par déterminer le nom qu'il va utiliser pour s'identifier. Ce nom peut être spécifié par l'utilisateur grâce à l'option [i]user[/i]. Sans cette option, le nom pris par défaut est celui du système local, déterminé comme indiqué au paragraphe précédent. Pppd cherche alors un secret comportant ce nom en premier champ et le nom du correspondant dans le deuxième champ. Pppd connaîtra le nom du correspondant si l'authentification CHAP est utilisée, car il est envoyé avec le "défi". Mais si PAP est utilisé, pppd devra déterminer le nom du correspondant à partir des options données par l'utilisateur. Celui-ci peut spécifier directement le nom du correspondant avec l'option [i]remotename[/i]. Autrement, si l'adresse IP distante a été spécifiée par un nom (et pas sous forme numérique), ce nom sera utilisé comme nom du correspondant. Sans aucune indication, pppd utilisera la chaîne vide comme nom de correspondant.     Lors de l'authentification du correspondant avec PAP, le mot de passe fourni est d'abord comparé avec le secret contenu dans le fichier de secrets. Si le mot de passe ne correspond pas au secret, le mot de passe est encrypté par crypt(), et de nouveau comparé au secret. Ainsi, les secrets d'authentification peuvent être stockés sous forme encryptée si désiré. Si l'option [i]papcrypt[/i] est passée, la première comparaison (en clair) est omise, pour plus de sécurité.     De plus, si l'option [i]login[/i] a été spécifiée, le nom d'utilisateur et le mot de passe sont encore vérifiés par rapport à la base des mots de passe système. Ainsi, l'administrateur système peut configurer le fichier pap-secrets pour permettre l'accès PPP à certains utilisateurs seulement, et pour restreindre l'ensemble des adresses IP que chaque utilisateur peut utiliser. Typiquement, en utilisant l'option [i]login[/i], le secret dans /etc/ppp/pap-secrets serait "", qui correspondra à n'importe quel mot de passe fourni par le correspondant. Cela permet d'éviter de mettre le même secret en deux endroits différents.     L'authentification doit se terminer avec succès avant qu'IPCP (ou tout autre Protocole de Contrôle Réseau -NCP, Network Control Protocol-) ne démarre. Si le correspondant doit s'authentifier et n'en est pas capable, pppd coupera la connexion (en fermant LCP). Si IPCP négocie une adresse IP inacceptable pour l'hôte distant, IPCP sera fermé. Les paquets IP ne peuvent être transmis que si IPCP est ouvert.     Dans certains cas, il est nécessaire de permettre à certains hôtes qui ne peuvent pas s'authentifier de se connecter et d'utiliser une adresse IP d'une classe restreinte, même si l'hôte local exige en règle générale une authentification. Si le correspondant refuse de s'authentifier quand ça lui est demandé, pppd considère cela comme une authentification PAP avec un nom d'utilisateur et un mot de passe vides. Ainsi, en ajoutant au fichier pap-secrets une ligne avec des chaînes vides comme client et mot de passe, il est possible d'autoriser un accès restreint à des hôtes qui refusent de s'authentifier. [size=18] [b]Routage[/b] [/size]     Quand la négociation IPCP se termine avec succès, pppd informe le noyau des adresses IP locale et distante pour l'interface PPP. C'est suffisant pour créer une route vers l'extrémité du lien, qui va permettre aux correspondants d'échanger des paquets IP. La communication avec d'autres machines requiert généralement des modifications supplémentaires dans les tables de routage ou dans les tables ARP (Address Resolution Protocol). Dans la plupart des cas, les options [i]defaultroute[/i] ou [i]proxyarp[/i] sont suffisantes, mais dans certains cas, d'autres interventions sont nécessaires. Elles peuvent être spécifiées dans le script /etc/ppp/ip-up.     Il est souvent nécessaire de rajouter une route par défaut via l'hôte distant, dans le cas d'une machine dont la seule connexion à l'Internet se fait par l'interface ppp. L'option [i]defaultroute[/i] permet à pppd de créer cette route par défaut au démarrage d'IPCP, et de la détruire dès que le lien est coupé.     Dans certains cas, il est nécessaire d'utiliser un proxy ARP, par exemple sur une machine serveur connectée à un LAN, afin de permettre aux autres machines locales de communiquer avec l'hôte distant. L'option [i]proxyarp[/i] permet à pppd de rechercher une interface réseau sur le même sous-réseau que l'hôte distant (une interface supportant le broadcast et ARP, ni loopback, ni interface point-à-point). S'il en trouve une, pppd crée une entrée ARP publique et permanente avec l'adresse IP de l'hôte distant et l'adresse MAC de l'interface réseau trouvée.     Quand l'option [i]demand[/i] est utilisée, les adresses IP de l'interface ont déjà été fixées au moment où IPCP entre en action. Si pppd n'a pas pu négocier les mêmes adresses que celles utilisées pour configurer l'interface (par exemple si le correspondant est un FAI qui utilise l'attribution dynamique d'adresses IP), il est obligé de changer les adresses IP de l'interface. Cela peut couper les connexions IP existantes, de sorte que l'utilisation de la connexion à la demande avec des correspondants qui utilisent l'attribution dynamique n'est pas recommandée. [size=18] [b]Exemples[/b] [/size]     Les exemples suivants supposent que le fichier /etc/ppp/options contient l'option [i]auth[/i] (comme dans le fichier /etc/ppp/options par défaut dans la distribution de ppp).     L'usage le plus commun de pppd est probablement la connexion à un FAI. Cela peut être fait avec une commande de type [table][row][col]    [/col][col]pppd call fai[/col][/row][/table]     où le fichier /etc/ppp/peers/fai est configuré par l'administrateur système, pour contenir quelque chose comme : [table][row][col]    [/col][col]ttyS0 19200 crtscts [b][/b] connect '/usr/sbin/chat -v -f /etc/ppp/chat-fai' [b][/b] noauth[/col][/row][/table]     Dans cet exemple, on utilise chat pour appeler le modem du FAI, et initier la séquence de login nécessaire. Le fichier /etc/ppp/chat-fai contient le script utilisé par chat ; il pourrait par exemple contenir quelque chose comme : [table][row][col]    [/col][col]
Fichier