PPP, ou "Point-to-Point Protocol", est un protocole internet "officiel". Il est destiné à l'échange de paquets IP (ou autre type de réseau) sur une liaison série. Sa description se trouve dans le RFC 1661.
Contrairement à ce que beaucoup de personnes pensent, PPP ne signifie pas du tout "Peer to Peer Processing", bien qu'il soit possible d'effectuer des communications "peer-peer" en utilisant TCP/IP sur une liaison PPP.
En général, non. Une implémentation "classique" de PPP nécessite des modifications aux routages et interfaces réseau du système d'exploitation. Cela peut nécessiter la recompilation du noyau du système distant.
Ce n'est pas une tâche de simple utilisateur. Si vous arrivez à convaincre vos administrateurs système que PPP est une "bonne chose", alors vous aurez une chance de voir ce protocole installé. Si ils sont réfractaires à cette idée, vous ne pourrez probablement pas utiliser PPP.
Malgré tout, si vous utilisez un système qui est supporté par les
gens qui vendent "TIA" (The Internet Adapter) il y a un petit
espoir. Nous n'avons pas beaucoup d'informations sur ce paquetage,
mais nous avons entendu dire qu'ils comptent supporter PPP dans les
prochaines versions. (Ces informations sont sans doute très anciennes,
contactez-les directement. Vous trouverez des renseignements sur TIA
sur ftp.marketplace.com
dans le répertoire /pub/tia
).
Si votre système n'est pas supporté par TIA et que vous ne pouvez convaincre vos administrateurs de l'utilité de PPP, essayez d'utiliser le paquetage "term". Malgré tout, beaucoup refuseront pour des "raisons de sécurité".
Il existe une version de TIA pour Linux.
Il se décompose en deux parties, dont la première est dans le noyau, incluse depuis Linux 1.1.13.
NE REMPLACEZ PAS LE PILOTE FOURNI AVEC LE NOYAU PAR UNE VERSION TROUVEE DANS LE PAQUETAGE PPPD !!!
La seconde partie est le "démon pppd". Ce programme est
INDISPENSABLE, ses sources se trouvent dans le fichier ppp-2.1.2c.tar.gz
sur les sites diffusant Linux.
Pour les noyaux de version inférieure à 1.1.13, le pilote nécessaire est inclus dans un sous-répertoire de cette archive. C'est le seul cas où vous deviez utiliser ces fichiers système, mais il est préférable de mettre à jour votre noyau.
Lisez la documentation fournie. Elle a été écrite pour vous !
Commencez par lire les fichiers README et README.linux. Diverses autres sources de documentation sont indiquées ci-après.
(Où est la doc ? Où est la FAQ ? etc.)
Il existe plusieurs sources d'information concernant le protocole PPP tel qu'il est implémenté sous Linux.
pppd
".Le fichier HOWTO peut se télécharger sur les sites habituels diffusant
Linux, par exemple sur ftp.ibp.fr
dans le répertoire
/pub/linux/docs/HOWTO
.
Le Network Administration Guide
fait partie du projet de documentation
Linux, vous trouverez ce livre sous forme électronique au même endroit.
Il a été publié par O'Reilly et est disponible en version
française, sous le titre "Administration réseau sous Linux".
Si vous désirez un document de présentation professionnelle,
vous pourrez alors acheter cet ouvrage plutôt que de le télécharger et
l'imprimer vous-même.
Les pages de manuel sont fournies avec les sources. Il vous faudra les
placer dans les répertoires standard, /usr/man/man8
pour que
la commande man
puisse les traiter. Vous pouvez bien entendu
les examiner directement à l'aide de groff
.
La FAQ de PPP décrit le protocole en lui-même et ses diverses
implémentations sur différents systèmes. Vous trouverez ce document
dans le forum Usenet comp.protocols.ppp
, ou encore dans
news.answers
et il est bien entendu archivé sur
rtfm.mit.edu
dans le répertoire /usenet
.
Il est à l'heure actuelle composé de huit parties.
Il est préférable de les poser dans le groupe comp.protocols.ppp
.
Il est fait pour cela. Hélas, beaucoup d'utilisateurs ont tendance à
exposer d'abord leur problème dans les groupes comp.os.linux.*
,
dans lesquels ils reçoivent des réponses bien que ce ne soit pas l'endroit idéal.
Très peu de questions sur PPP sont directement liées à son implémentation sous Linux. La plupart des problèmes posés sont d'ordre général, concernent l'utilisation du paquetage PPP et les réponses sont applicables à n'importe quel autre système d'exploitation.
Aussi, pour réduire le trafic dans les groupes Linux, et pour
toucher les vrais spécialistes de PPP, si vous devez utiliser Usenet
à ce sujet, utilisez absolument le groupe comp.protocols.ppp
.
C'est l'une des questions les plus irritantes. Nous nous rendons bien compte que c'est un appel à l'aide, mais il est inutile de poster un tel message SANS AUCUNE AUTRE INFORMATION. La plupart des gens susceptibles de pouvoir vous aider l'ignoreront, purement et simplement.
Il vous faut fournir les traces système (syslog) produites lorsque
vous lancez le programme pppd avec l'option debug
. De plus,
si vous utilisez chat
pour l'appel du service, utilisez son
option -v
pour obtenir un enregistrement du dialogue.
Fournissez également la trace (log) de démarrage de votre noyau Linux. elle informe des différentes configurations propres à votre système, comme la version de PPP, le type de port série, etc.
Enfin, rajoutez toute information que vous pensez relative à votre problème. Bien entendu, votre machine, disques durs, boutons de souris, terminaux, n'ont aucun intérêt... Ce qui compte est surtout le système que vous tentez de contacter, la version de PPP ou de serveur de terminaux qu'il utilise, les types et vitesses des modems de part et d'autre, etc.
Faites attention, éditez soigneusement ces informations, en supprimant
éventuellement tout numéro de téléphone, login et mot de passe
susceptibles d'apparaître. Ils n'ont aucune utilité pour le déboguage,
et les diffuser sur Usenet ne serait pas très malin. Supprimez aussi
les lignes qui ne viennent pas du noyeau ou de pppd
.
Ne postez jamais intégralement la trace du programme pppd
lancé avec l'option kdebug 7
!
Si le problème demande une analyse du flux de données, vous serez contacté par courrier électronique et l'on vous demandera la trace par ce biais. Usenet coûte déjà bien trop cher pour beaucoup de gens.
L'information est écrite sous plusieurs niveaux. Les messages de
déboguage sont au niveau debug
. Ceux d'information le sont
au niveau info
, les erreurs au niveau error
.
Incluez tous les niveaux par le groupe local2
, issu du
processus pppd
.
Enfin, ne supprimez surtout pas les informations horaires, elles sont très importantes.
Le serveur m'attribue une adresse IP différente à chaque appel.
L'assignation de l'adresse IP locale dépend à la fois des options passées
à pppd
et du protocole IPCP
. Vous devez utiliser l'adresse
magique 0.0.0.0 s'il vous faut vraiment spécifier une adresse IP
locale. La plupart des gens préfèrent ne pas préciser du tout d'adresse locale
dans la liste des options.
Une autre option est intimement liée à cette adresse locale, il s'agit de
"noipdefault
". Celle-ci indique à pppd
de ne pas tenter
de deviner l'adresse IP locale à partir du nom de votre machine et des
adresses déclarées dans le fichier /etc/hosts
. La plupart des
utilisateurs emploient cette option lors d'un adressage dynamique.
Toutefois, elle ne signifie pas "utiliser des adresses dynamiques" ;
cet usage est automatique dès lors que l'adresse IP locale n'est pas
précisée.
Utilisez par exemple le script /etc/ppp/ip-up
. L'adresse IP locale
est le quatrième argument qui lui est passé ; ce script est automatiquement
exécuté s'il existe dès que pppd
connaît l'adresse IP du système
local. Le cinquième paramètre contient l'adresse IP du système distant, au
cas où vous auriez aussi besoin de connaître cette valeur.
Oui.
L'adresse locale n'est pas significative pour le système local. Vous devez avoir une adresse IP distante unique. Le routage est fait en fonction de l'adresse distante, et non locale.
Existe-t-il des versions pour HP-UX, AIX, ou... bien d'autres systèmes ?
Lisez les documentations mentionnées plus haut.
AIX sera supporté dans la version 2.2 du paquetage pppd
.
HP-UX n'est à notre connaissance supporté que par la version
commerciale MorningStar.
Si vous ne trouvez vraiment aucun renseignement, demandez dans
comp.protocols.ppp
, mais surtout pas dans un groupe Linux,
qui n'est en aucun cas concerné.
Oui, nous sommes au courant. Le paquetage "dp" fut envisagé au tout
début de l'implémentation de PPP sous Linux. Il est très bien, il
supporte l'appel à la demande. Il ne peut fonctionner que sur un
système supportant les streams
, c'est à dire principalement
le nouveau SunOS (Solaris).
Linux, pour l'instant, ne supporte pas les streams
.
Il existe d'autres ensembles PPP disponibles par l'Internet.
Le paquetage Portable ppp
ressemble beaucoup au code TIA ;
une autre implémentation se nomme tout simplement ppp
,
et on trouve du code pour PPP dans l'excellent paquetage KA9Q
.
De toutes ces versions, pppd
était le plus proche de ce que
Linux nécessitait pour assurer un portage correct.
(Si vous désirez plus d'informations sur ces autres implémentations,
demandez dans comp.protocols.ppp
).
L'implémentation courante de PPP est un mélange de plusieurs. La plus grande partie du code de PPP est réalisée selon les RFC 1331 et 1332. Ces documents sont maintenant obsolètes ; le 1331 fut remplacé par le 1548 qui, à son tour, fut remplacé par le 1661 six mois plus tard. Vous trouverez une liste complète dans la FAQ PPP.
La plupart des implémentations de PPP converseront sans problème avec celle de Linux.
Extrait de la FAQ PPP :
Tous les RFC 1134, 1171, et 1172 (et, de ce fait, 1055) sont maintenant obsolètes. Ils ne sont intéressants que si vous comptez déboguer une connection avec une ancienne implémentation de PPP, et si vous vous demandez pourquoi, par exemple, elle vous a demandé l'option IPCP 2 avec une longueur de 4 seulement, et un type de compression 0x0037.
(Il en circule encore de nombreuses versions, faites attention).
Le PPP de Linux ne supportera pas ces vieilleries.
Non. SLIP fonctionne avec SLIP, PPP fonctionne avec PPP.
Quelques distributeurs peuvent offrir des produits fonctionnant à la fois en SLIP et PPP. Toutefois, ils doivent être configurés dans l'un de ces deux modes. Il n'existe actuellement aucune méthode permettant de déterminer à la connexion quel type de protocoles SLIP, ou PPP, est attendu.
CELA DEPEND DE NOMBREUX FACTEURS !
Les gens qui posent ce genre de
question n'ont en général pas lu le moindre document sur ces
protocoles, à commencer par le Net-2-HOWTO
.
Un articles très intéressant sur ce sujet est disponible sur le
serveur Web de Morning Star, www.morningstar.com
.
Si vous avez le choix, prenez CHAP
.
Sinon, PAP
sera mieux que rien.
/etc/ppp/pap-secrets
?Le protocole pap
est le plus souvent implémenté sous la
forme de votre nom d'utilisateur associé à un mot de passe.
Vous devez mettre le nom du système distant, votre nom d'utilisateur,
et le mot de passe.
Prenons un exemple : L'utilisateur abbot
veut appeler
costello
. L'entrée sera la suivante :
#remote account password IP address list
* abbot firstbase
/etc/ppp/chap-secrets
?Le problème le plus courant est la non-reconnaissance de
cette négociation CHAP
par un couple de secrets
.
Chacun des deux ordinateurs devant se relier doit connaître les
deux secrets
pour que la communication aboutisse.
Par exemple, si abbot
veut communiquer avec costello
,
le fichier sur abbot
contiendra :
#local distant secret liste d'adresses IP
abbot costello firstbase
costello abbot who
Et celui de costello
sera :
#local distant secret liste d'adresses IP
abbot costello firstbase
costello abbot who
J'ai des erreurs lors de la compilation du noyau quand j'inclus le pilote ppp.c. Ce noyau est en version 1.1.8. Que faire ?
Ne tentez pas de faire fonctionner PPP avec un noyau aussi ancien, mettez votre système à jour ! Les versions 1.0 de Linux demandaient une modification des sources, les versions 1.1 supportaient déjà PPP mais nécessitaient beaucoup d'ajustements.
A partir de la version 1.2 du noyau, le pilote PPP est fourni en standard et est prévu pour fonctionner le plus simplement du monde.
pppd
si je ne suis pas root ?Le processus pppd
a besoin de modifier le paramétrage
du réseau, et ceci n'est autorisé qu'au super-utilisateur.
Si vous désirez pouvoir lancer pppd
sous un autre
nom d'utilisateur, le programme doit alors être "suid root" :
chown root pppd
chmod 4755 pppd
Si vous voulez n'autoriser pppd
qu'à un petit groupe
de personnes, attribuez-le à ce groupe et interdisez son exécution
à tous les autres.
Désolé, on s'est trompé, nous travaillons avec vos programmes du futur, que voulez-vous. Un jour où l'autre, vous disposerez également de ces bibliothèques.
En attendant,il va vous falloir recompiler le code vous-même, avec les bibliothèques dont vous disposez. C'est très facile :
Allez dans le répertoire pppd
, effacez le mauvais
binaire, et tapez la commande "make
". Faites de
même dans le répertoire chat
si vous comptez utiliser
ce programme.
Une autre solution est de vous procurer une version de ces bibliothèques et de jouer les alpha-testeurs :-) Quoi qu'il en soit, depuis le 21 mai 1995 Linux utilise le format binaire ELF par défaut, et ce paragraphe est obsolète. Assurez-vous avant toute compilation de l'ensemble de prendre l'archive la plus récente.
unable to create pid file
?Vous devez créer le répertoire /var/run
.
Dans certaines distributions, il s'agit d'un lien symbolique
vers le répertoire /etc
.
Ce n'est qu'un avertissement, qui n'empêche pas PPP de
fonctionner correctement. Toutefois, le script ppp-off
dépend de ce fichier, il est donc préférable de régler le
problème.
L'entête POSIX path.h
définit l'emplacement du fichier
pid
sous le nom _VAR_RUN
. Si vous désirez
utiliser un autre répertoire pour PPP ou d'autres programmes,
changez la valeur de cette définition et recompilez les
programmes.
/etc/ppp/options: no such file or directory
?Vous devez créer le répertoire /etc/ppp
et y mettre
un fichier nommé options
. Il doit être lisible par
le processus pppd
(root).
Ce fichier peut être vide, tout simplement. Dans ce cas,
utilisez la commande touch
pour le créer. Lisez
la page de manuel de pppd
pour obtenir une description
de ce fichier.
Il est possible de compiler pppd
pour qu'il n'utilise
pas ce fichier ; dans ce cas il faut supprimer (commenter) la
ligne SECURE_FLAGS = -DREQ_SYSOPTIONS=1
dans le
Makefile
.
Could not determine local IP address
".Cela se produit avec de nombreuses configurations du Telebit Netblazer. Le problème ne provient pas du serveur de terminaux, mais le site n'a pas égé configuré ce dernier avec un couple d'adresses IP.
Le Netblazer n'a pas votre adresse IP. Vous n'avez pas non plus votre adresse IP. La liaison ne s'effectuera pas tant que cette situation durera.
La connexion n'aboutira pas tant que ces deux adresses ne seront pas connues.
On a dû vous donner une feuille de papier sur laquelle ces
deux adresses IP sont indiquées. Vous devez signaler au
Netblazer l'adresse à utiliser. Indiquez alors ces deux adresses,
locale et distante, comme paramètres lors du lancement du
programme pppd
, selon le format suivant :
adresse_locale:adresse_distante
N'oubliez surtout pas les deux points (:
) de séparation.
Could not determine remote IP address
".Lisez donc la réponse à la question précédente...
La probabilité que les deux systèmes aient choisi le même nombre magique est d'une chance sur un milliard. Si vous obtenez continuellement cette erreur, prenez un billet de loterie et/ou surveillez votre femme :-)
Les deux causes les plus courantes de ce problème sont :
pppd
se plaint de se voir refuser le protocole fffb
. Qu'est-ce que c'est que ça ?La version 5.1 du logiciel des serveurs de terminaux Xyplex est connue pour avoir beaucoup de problèmes sous PPP. Il est fortement recommandé de faire une mise à jour pour passer en version 5.3 ou supérieure.
Si vous devez rester en version 5.1, utilisez alors l'option
"vj-max-slots 3
" pour limiter le nombre de slots
à trois, au lieu des 16 par défaut, qu'est censé supporter le logiciel
alors qu'il ne fonctionne pas au-delà du troisième. Il devrait retourner
une trame NAK, mais ne le fait pas.
Sinon, vous pouvez désactiver la compression
d'en-têtes Van Jacobson. Utilisez l'option -vj
de pppd
.
Essayez avec l'option debug
et examinez les traces système
(vous aurez de toutes façons besoin de ces traces si vous comptez demander
de l'aide). Si elles montrent que vous envoyez la séquence
"LCP-request" continuellement et que la valeur de "id" ne
s'incrémente pas, c'est qu'il n'y a pas de PPP à l'autre bout.
Les trois causes les plus courantes sont :
pppd
passera automatiquement la ligne
sous ce format. La machine distante doit également se
conformer à cette configuration sous peine de nombreuses
erreurs de format et parité.
PPP encode certains caractères. Il ne lui est pas possible
de travailler au niveau du bit comme kermit peut le faire.
PPP ne fonctionne pas sur une liaison 7 bits.
Il y a une option de compilation dans le pilote ppp.c (qui fait
partie du noyau) appelée CHECK_CHARACTERS, qui ajoute du code
destiné à effectuer des tests supplémentaires sur les caractères
reçus. Elle pourra vous indiquer si la parité était validée ou
si le système distant envoyait du 7 bits.
auth
", c'est que le système distant
est configuré pour demander l'authentification.merit
, et je me fais jeter.Des utilisateurs de ce réseau ont signalé qu'il nécessite PAP. Avez-vous essayé l'authentification PAP ?
Lorsque je tente d'utiliser mode ppp
depuis dip
j'obtiens une erreur disant que le mode PPP n'est pas supporté.
Est-il prévu d'utiliser dip
avec PPP ?
Le programme dip
contrôle l'établissement d'une
liaison SLIP. Puisque le processus pppd
doit faire
plusieurs choses à des moments différents que dans un lien
SLIP, il y a fort peu de chances pour que dip
et
pppd
puissent s'entendre un jour.
La commande dip
peut néanmoins être utilisée pour
l'appel téléphonique et le lancement de PPP sur le système
distant. Dans ce cas il est préférable de le lancer en tant
qu'argument connect
de pppd
.
La version en cours de dip-uri
supporte PPP en ce sens
qu'elle exécute le programme pppd
sur l'instruction
"mode ppp
". Toutefois, elle ne passe aucun des nombreux
arguments nécessaires au fonctionnement correct de pppd
,
aussi est-il indispensable de mettre ces options dans le fichier
/etc/ppp/options
.
La manière dont est exécuté pppd
importe peu pour la liaison
PPP. Mais ce programme doit absolument être lancé, car il est indispensable
au protocole PPP.
Non, il n'y en a pas.
Dans le répertoire chat
, vous trouverez un script
appelé ppp-off
. Il arrêtera la liaison PPP de la
même façon que votre dip -k
.
Le voici ci-dessous. Copiez-le dans un fichier que vous
rendrez exécutable par la commande chmod +x
et
le tour sera joué.
#!/bin/sh
DEVICE=ppp0
#
# Si le fichier pid de ppp0 est present, alors c'est que le programme
# tourne. Arretons-le.
if [ -r /var/run/$DEVICE.pid ]; then
kill -INT `cat /var/run/$DEVICE.pid`
#
# Si ca n'a pas marche, c'est qu'il n'y a plus de processus actifs
# correspondant a ce pid. Cela peut aussi signifier que le fichier
# de verrouillage a ete laisse en place. Il faut supprimer ce verrou.
if [! "$?" = "0" ]; then
rm -f /var/run/$DEVICE.pid
echo 'ERROR: Removed stale pid file'
exit 1
fi
#
# Succes. Laissons pppd faire son propre menage.
echo 'PPP link to $DEVICE terminated.'
exit 0
fi
#
# Le processus pppd n'est pas actif sur ppp0
echo 'ERROR: PPP link is not active on $DEVICE'
exit 1
pppd
ne se termine pas lorsque le modem se déconnecte. Je dois l'arrêter manuellement pour que getty
reprenne la main.Ce problème peut avoir plusieurs causes.
modem
?
Ce paramètre indique à pppd
d'honorer les signaux relatifs
à l'état du modem sur la ligne, qu'il ignore par défaut. Il est
décrit dans la page de manuel de pppd
.
Hayes
positionnant ce comportement est
généralement &C1
. Si vous remettez l'appareil
à zéro par ATZ
lors de la communication, assurez-vous
bien qu'il gère toujours le signal DCD. La configuration
d'usine fournie par beaucoup de constructeurs est --- hélas ! ---
d'ignorer ce Carrier Detect
.
Le signal DTR est généré par l'ordinateur et indique au modem
de raccrocher la ligne. La séquence Hayes pour cela est
généralement &D1
ou &D2
,
la seconde étant préférée pour utiliser PPP. La configuration
par défaut des constructeurs est souvent d'ignorer DTR.
pppd
correctement ? Le processus doit être lancé par un appel
exec
; si vous le lancez depuis le shell comme une
simple commande, ce sera le shell qui recevra SIGHUP et non
pas le processus pppd
.Le script doit avoir un format du type suivant :
#!/bin/sh
exec pppd -detach modem ...
Le contrôle de flux est-t-il bien en service ?
Il se valide par l'option crtscts
de pppd, pour ce qui
est du contrôle de flux matériel RTS/CTS, et par l'option
xonxoff
pour XON/XOFF. Sans contrôle de flux, vous
perdrez des caractères et le résultat sera désastreux pour
la compression vj, entre autres.
Le mieux est de ne pas l'utiliser, et de choisir RTS/CTS. Toutefois, si vous ne pouvez faire autrement, vous devez opérer selon les trois points suivants :
xonxoff
à pppd.
Cela indiquera au programme de configurer le port série
pour le contrôle de flux XON/XOFF, en indiquant ces
caractères au pilote.
asyncmap
de pppd. Cela indiquera
au système distant qu'il doit encoder XON et XOFF lorsqu'il
doit les envoyer en tant que caractères normaux. Il suffit
en principe d'indiquer asyncmap a0000
.
Mettez la vitesse désirée dans la commande de pppd. Si vous ne l'indiquez pas, ce sera celle qui est initialisée au moment ou vous lancez le programme qui sera utilisée, et elle peut être quelconque : tous les programmes ne remettent pas correctement les paramètres du port série qu'ils ont trouvé en arrivant. Certains peuvent même laisser des valeurs étranges amenant un fonctionnement curieux (une vitesse de 0, par exemple !).
Avez-vous bien indiqué l'option :
asyncmap 0
lors du lancement de pppd
? Si vous l'avez oubliée, l'autre
côté doit encoder (doubler) tous les caractères de contrôle entre les
valeurs hexadécimales 00 et 1F. Cette opération résulte en une perte
de vitesse moyenne de 12,5 % pour tout ce que vous recevez.
Le système distant est-il bien configuré ? Si oui, le contrôle de flux est-il bien en service ?
proxyarp
. La fonction proxyarp n'arrive pas à trouver l'adresse MAC avec Linux 1.0.Utilisez l'archive ppp-2.1.2d.tar.gz. Le programme pppd
était compilé par erreur sous Linux 1.1.8 et utilisait les
définitions Net-3 plutôt que celles de l'ancien Net-2.
Vous pouvez également consulter le document "mini-HOWTO" proxy-ARP pour obtenir plus de détails sur le sujet.
Cela n'a rien à voir avec PPP.
Bon, allez, on vous le dit : n'utilisez JAMAIS routed
!
N'auriez-vous pas oublié le paramètre defaultroute
?
Il ajoute une route par défaut dans vos tables de routage,
afin que les paquets vers toutes les autres adresses
IP soient envoyés par l'interface PPP.
Le programme ne remplacera pas une route par défaut déjà
existante. Cela est volontaire, pour éviter de détruire la
route par défaut vers d'éventuels routeurs Ethernet par
accident. Dans ce cas, un message d'avertissement est envoyé
au système de trace de la machine, via syslog
, et
ce sera à vous d'effectuer les opérations que vous jugerez
nécessaires.
Cela ne provient pas de votre système Linux local, mais probablement d'un problème de routage sur la machine distante.
Le système distant n'est pas configuré pour supporter l'IP forwarding. Les RFC stipulent que cette option ne soit PAS validée par défaut, pour des raisons de sécurité. Vous devez mettre cette option en service ; sous Linux il vous faut alors reconstruire le noyau en indiquant que vous désirez supporter "IP forwarding/gatewaying".
Le système distant a besoin d'une route vers vous, tout comme vous en avez une vers lui. Cela peut être réalisé de quatre façons différentes. Chaque méthode a ses avantages et inconvénients ; vous devez en choisir une, et une seule.
sii.com
,
nous avons plus de 300 systèmes actifs et seulement 3 routeurs).
gated
sur toutes les
passerelles et sur le serveur de terminaux. Cela fera diffuser
par le serveur de terminaux des informations vers les passerelles,
indiquant qu'il peut accepter des paquets pour votre adresse IP.
Puisque les machines auront une route par défaut vers l'une de
ces passerelles, ces dernières génèreront les requêtes ICMP de
redirection et le routage s'établira automatiquement.
proxy ARP
" sur le serveur de terminaux.
Cette méthode ne fonctionnera que si votre adresse IP locale
correspond à l'un des domaines IP des cartes réseau.En résumé, il n'y a pas de solution miracle, simple et unique. Vous devez faire votre choix parmi l'une de ces quatre-là.
Si votre routeur nécessite des trames RIP afin de mettre à jour la
route vers votre système, vous devrez utiliser le programme "bcastd
"
disponible sur sunsite.unc.edu
. Il générera les paquets RIP nécessaires
sans avoir besoin de déranger gated
.
ping
uer" mon adresse IP locale.Vous ne pouvez pas parce que vous n'avez pas de route vers cette adresse. C'est le fonctionnement normal. N'essayez pas.
Si vous voulez faire un ping
sur votre propre système,
utilisez l'adresse loopback
: 127.0.0.1.
Vous devriez pouvoir "ping
uer" l'adresse distante.
Toutefois, certains serveurs interdisent cette opération.
En règle générale, n'essayez pas ping
sur l'une
ou l'autre de ces adresse. Choisissez-en une troisième,
que vous savez accessible sur le réseau distant.
Bien que PPP ne s'occupe pas de cette tâche, vous pouvez ajouter manuellement une route vous-même une fois que la liaison est établie. La syntaxe est la suivante :
route add -host 192.187.163.32 looù l'adresse IP locale est ici représentée par 192.187.163.32. Tous les paquets destinés à votre adresse IP locale seront alors dirigés vers votre interface
loopback
.
Vous ne devrez pas oublier de supprimer manuellement cette route lorsque la liaison ne sera plus établie, bien entendu.
Trumpet n'aime pas du tout la compression d'en-têtes Van Jacobson.
Utilisez l'option -vj
pour la mettre hors service.
Il y a un bogue dans la version 3.1.2 de dp. Procurez-vous la version
3.1.2a ou plus récente sur le site de référence harbor.ecn.purdue.ecu
.
Tant que vous n'avez pas pu effectuer cette mise à jour, supprimez la
compression vj
.
Microsoft a choisi d'utiliser un protocole d'authentification
non standard dans Windows NT. C'est leur droit le plus strict,
à condition qu'ils aient enregistré leur numéro de protocole
auprès de l'IANA. (C'est le cas).
Si l'option "accept only Microsoft encrypted authentication"
de la boite check
de l'agenda téléphonique est positionnée,
la connexion n'aboutira jamais : celle-ci demande que le système
Windows NT n'échange d'authentification PPP qu'avec une autre implémentation
PPP de Microsoft.
Linux ne supporte pas ce protocole d'authentification.
Si vous avez la possibilité de changer le paramétrage du système Windows NT, allez dans la configuration de l'agenda téléphonique, et assurez-vous que "Accept any authentication including clear text" est validée et que "accept only Microsoft encrypted authentication" ne le soit pas. Les autres options sont fonction de ce que vous désirez.
Puis, utilisez PAP du côté Linux. Mettez votre compte (nom et mot de passe)
Windows NT dans le fichier /etc/ppp/pap-secrets
.
La séquence d'authentification Microsoft est de style PAP, avec leur propre algorithme de chiffrement DES pour ce qui concerne les mots de passe. La séquence normale envoie le mot de passe sous forme ASCII pure ; ce qui dans leur cas violerait la sécurité C2.
Les versions de PPP antérieures à 2.1.2c sous Linux ont un problème avec le décodage de la requête d'authentification. Elles ne fonctionneront pas avec un système Windows NT car elles ne négocient pas la méthode correcte. Utilisez la version 2.1.2c ou ultérieure si vous voulez vous connecter sur un bidule machin Windows NT. La version en cours, 2.1.2d est préférable.
Scott Hutton <shutton@habanero.ucs.indiana.edu>
nous a
indiqué ceci :
NT RAS (Remote Access Services) coupe la connexion dès lors que quelque chose de critique est REJeté (par exemple, le protocole d'authentification). Par conséquent, l'astuce consiste à créer un fichier chap-secrets bidon. Le mien contient :
* "" ""
Il a pour conséquence de faire envoyer un NAK
par pppd
,
plutôt qu'un REJ
. La clé d'enregistrement SPAP
supprimée,
le protocole suivant essayé est PAP
(c'est celui que
j'utilise).
Il faut également s'assurer que seuls les services TCP/IP sont validés dans RAS (et pas NetBEUI ni IPX). Il a aussi fallu prendre en considération deux autres clés pour éliminer les time-out (qui ne posent des problèmes qu'avec TCP/IP) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters
Autodisconnect: REG_DWORD: 0
Et pour obtenir un routage fonctionnel :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasArp\Parameters
DisableOtherSrcPackets: REG_DWORD: 0
Enfin, la clé pour éliminer complètement SPAP :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\SPAP
Alarm
. Est-ce grave ?Non.
Cela signifie simplement qu'une mesure de temps s'est écoulée, c'est une partie nécessaire de la phase d'établissement du protocole.
SIGHUP
. Le processus pppd
a reçu un signal HUP
. Celui-ci est
généré par le pilote de périphérique lorsque le système distant s'est
déconnecté de votre modem. Il signifie que le modem a raccroché la ligne,
tout simplement ; la communication est coupée.
On peut également utiliser la commande kill
pour envoyer ce signal
au programme pppd
.
Sur réception de ce SIGHUP
, le programme pppd
se termine
proprement.
SIGINT
. Le processus pppd
a reçu un signal INT
. Celui-ci
est généré par le pilote de la console lorsque vous pressez la
combinaison de touche CTRL-C et que pppd
est en avant-plan.
On peut également utiliser la commande kill
pour envoyer ce signal
au programme pppd
. En fait, c'est la méthode recommandée pour
arrêter le programme et terminer la liaison. Consultez la question concernant
"dip -k
", vous y trouverez un script effectuant cette opération.
Sur réception de ce SIGHUP
, le programme pppd
se termine
proprement.
protocol reject for protocol c025
. Qu'est-ce que c'est que cette histoire ?Le site distant voudrait mettre en service le protocole d'analyse de qualité de liaison sur la machine Linux. (LQR, "Link Quality Reporting"). Ce protocole n'est pas encore supporté, ce n'est pas une erreur. Linux signale en substance : "L'autre m'a demandé ça, je lui ai dit que je ne sais pas le faire pour l'instant et qu'il ne m'embête pas avec".
L'implémentation MorningStar tentera toujours LQR. C'est normal.
ioctl(TIOCSCTTY)
.Utilisez l'archive ppp-2.1.2d.tar.gz. Il s'agit d'un bogue qui n'était pas géré avant la diffusion de ppp-2.1.2a.
ioctl(TIOCGETD): I/O error
ou bien encore ioctl(PPPIOCSINPSIG): I/O error
. Allô ! Docteur ?Regardez les messages du noyau lors de l'amorçage de votre
système Linux. Si il affiche PPP version 0.1.2
,
vous avez une version beaucoup trop ancienne du pilote ppp.c
.
Si vous voyez PPP version 0.2.7
, vous disposez de la
version à jour, mais qui cependant n'a pas été compilée avec
les mêmes définitions pour les valeurs d'ioctl()
.
Vérifiez que vous disposez bien d'un fichier, ppp.h
,
qui doit se trouver dans le répertoire include/linux
des sources du noyau. Dans ce cas, recompilez le noyau, puis
le programme pppd
.
ioctl(PPPIOCGDEBUG): I/O error
", "ioctl(TIOCSETD): I/O error
" et "ioctl(TIOCNXCL): I/O error
". Pourquoi donc ?Parce que le système distant a raccroché le téléphone.
Les pilotes tty rétablissent alors la discipline de ligne correcte
sur le port série, et ces erreurs sont le résultat du processus
pppd
, tentant de faire la même chose.
Tout cela est parfaitement normal, il n'y a pas d'inquiétudes à avoir.
ifconfig
affiche autre chose que ce qui suit. Il indique l'interface ppp comme "unknown
" et une adresse MAC bizarroïde.
ppp0 Link encap Point-to-Point Protocol
inet addr 192.76.32.2 P-t-P 129.67.1.165 Mask 255.255.255.0
Ce n'est pas grave. Cet affichage n'est là que pour information.
Si vous utilisez un noyau 1.1. récent, mettez à jour vos
programmes réseau.
/proc/net/dev
comme indiqué dans la documentation et c'est vide... Pourquoi ?Avez-vous juste tapé la commande "ls -l /proc/net
" en
vous étonnant de trouver une taille de zéro octet ? Si c'est le
cas, c'est normal. Vous devez faire :
cat /proc/net/dev
Vous devriez alors voir le contenu de ce fichier, qui ne doit
pas être vide. Sa taille est toujours indiquée comme étant
nulle, c'est le système de fichiers "proc
" qui
veut ça. Ce ne sont pas de vrais fichiers, ils sont simulés
par le noyau. Ne tenez pas compte de la taille, tapez la
commande indiquée.
Les programmes more
, less
ou most
ne
peuvent pas être directement utilisés sur ce fichier. Si vous
voulez malgré tout les employer, faites-le comme ceci :
cat /proc/net/dev | less
slattach
, ifconfig
et route
et ça ne marche toujours pas ! J'ai lu ça dans le Net-2-HOWTO ; où est l'erreur ?N'utilisez jamais slattach
et ifconfig
avec PPP. Ces programmes ne sont utiles que pour SLIP.
Le processus pppd
s'occupe de ces fonctions tout seul
au moment opportun, c'est à dire après l'échange des protocoles
LCP et IPCP.
Vous ne pouvez pas remplacer pppd
par slattach
et ifconfig
.
La plus grande partie du protocole PPP se trouve dans pppd
.
Le noyau ne connaît que IP (et IPX dans l'avenir).
La route vers le site distant sera automatiquement ajoutée
par pppd
. Il n'y a pas d'option pour supprimer cette
opération. Le programme se terminera si la route ne peut pas
être ajoutée a la table de routage.
La route par défaut peut être automatiquement ajoutée, ou non.
Cela est controlé par l'option defaultroute
.
Si vous avez déjà une route par défaut, elle ne sera pas
modifiée.
Si vous devez router un réseau entier, mettez la commande dans
le script /etc/ppp/ip-up
. Les paramètres passés à ce
script sont :
Sur sunsite.unc.edu
se trouve un paquetage du nom de
devinfo.tar.gz
. Il contient quelques petits utilitaires
pratiques qui extraient les données concernant un périphérique
et font différentes opérations sur les notations d'adresses IP.
La documentation est fournie sous forme de pages de manuel.
Par exemple, si vous voulez router le domaine IP entier vers
le site distant, vous pouvez mettre les choses suivantes dans
le script /etc/ppp/ip-up
.
Bien entendu, si les valeurs ne sont pas variables, il vous
suffit d'utiliser les entrées appropriées avec la commande
route
.
# Obtention du masque reseau pour l'interface ppp0 (ou autres)
NETMASK = `devinfo -d $1 -t mask`
# Obtention du domaine IP (sans l'adresse host en supprimant les bits ad hoc)
DOMAIN = `netmath -a $5 $NETMASK`
# Ajout de la route vers le reseau que nous connaissons maintenant
route -net add $DOMAIN gw $5
Utilisez diald
. Il est disponible sur tous les sites
diffusant Linux et fonctionne très bien avec PPP.
Rien n'est prévu à ce sujet dans le code de PPP.
Utilisez le code ipfirewall
, c'est disponible
sur sunsite.unc.edu
. Aidez l'auteur à déboguer la
chose, et ça fera ce que vous désirez que ça fasse.
Les dernières versions de développement du noyau comprennent en
standard les modifications ad hoc (vous aurez toujours besoin du
code ipfirewall
). Là encore, le filtrage est relatif au
réseau en général et n'est pas spécifique au protocole PPP.
L'addition du support pour IPX se fait tranquillement. J'ai (Al Longyear) commencé à y travailler pour quelqu'un me l'ayant demandé sur l'IRC (Internet Relay Chat). Je dois d'abord approfondir les manuels Novell pour comprendre quelles sont les valeurs correctes pour les fonctions de routage nécessaires pour IPXCP (IPXCP est le protocole de contrôle d'IPX).
Il existe un protocole PPP Netbios. Toutefois, la meilleure
solution serait que vous utilisiez TCP/IP et le code "samba
".
Microsoft et quelques autres ont utilisé le protocole PPP Netbios.
Le protocole nbfcp
fait l'objet d'un document public,
disponible auprès de plusieurs sources d'information. Le protocole
Netbios n'est pas une famille valide sous Linux, pour l'instant.
Tant que Linux ne supportera pas le protocole, il n'y a aucun
intérêt à supporter Netbios sur PPP.
Pour cela, il faut un pilote ad hoc. La conception actuelle du pilote PPP n'est pas très adaptée, mais cela va changer. Un pilote pour l'interface Sonix est en cours de développement.
Supporter une interface synchrone demande quelques modifications. La
réécriture du pilote PPP aidera beaucoup. Kate Marika Alhola a l'intention
de réaliser ce type de pilote pour le matériel dont
elle dispose. Vous pouvez la contacter à l'adresse kate@digiw.fi
pour plus d'information.
Heu... ?
Vous vous trompez de groupe si vous cherchez des bricoles MS-DOS.
PPP n'a rien à voir du tout avec l'agent de transport de courrier !
Ils sont tous "compatibles" avec PPP :-)
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre