Vous trouverez dans la suite des questions fréquemment posées et leurs réponses.
Oui vous pouvez, jetez un coup d'oeil à TERM. TERM vous permet de transformer votre liaison en mode terminal en liaison réseau. Cela nécessite quelques modifications de vos applications réseau, mais la plupart des binaires et des sources sont déjà disponibles pour la majorité des besoins. Regardez le lien TERM-HOWTO pour plus de détails.
Vous avez votre résolveur de nom qui n'est pas configuré correctement. Relisez la section concernant /etc/resolv.conf. Vous devez avoir au moins une entrée de nom de serveur configuré.
RFC1597 spécifie quelques adresses IP réservées pour les réseaux privés. Vous devez les utiliser pour éviter d'avoir des problèmes si vous vous retrouvez relié à l'Internet par accident. Ces adresses sont :
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Note: les adresses réseau réservées sont de classes A, B et C, donc vous n'êtes pas restreint dans la conception de votre réseau. Comme vous n'allez pas etre relié à l'Internet, cela ne pose pas de problème que vous ayez la même adresse qu'un autre, du moment que vos adresses soient uniques dans votre réseau.
Vous avez trois possibiltés, qui sont:
IP-Masquerade. C'est probablement le moyen le plus simple, car il est vraiment direct et ne requiert pas de clients spéciaux sur votre machine. Ce logiciel réalise intelligemment les traductions d'adresses qui font que les machines de votre réseau semblent supporter elles-mêmes vos connexions. Il y a quelques limitations pour que ça marche bien, mais c'est moins lourd que de tourner avec une passerelle `full firewall'.Les archives d'Alan sont mirrorisées sur:
ftp.Uni-Mainz.DE
/pub/Linux/packages/Net2Debugged
et/ou ftp.infomagic.com
/pub/mirrors/linux/sunacm
Les versions du noyau et du code réseau sont maintenant synchronisées, donc faire :
uname -a
ou :
cat /proc/version
Le fichier /etc/issue est le message que les utilisateurs normaux de getty reçoivent à la connexion. Quelques programmes telnetd utilisent le fichier /etc/issue.net à la place. Ainsi si voyez qu'un changement dans votre fichier issue n'a pas d'effet, essayez l'autre.
Cela signifie généralement que votre câble ethernet est débranché ou que vos paramètres pour votre carte (adresse E/S, IRQ, etc.) ne sont pas corrects. Vérifiez les messages de démarrage pour voir si votre carte est reconnue avec la bonne adresse ethernet. Si tout est correct vérifiez que vous n'avez pas de conflit avec d'autres cartes, comme une carte soundblaster partageant la même IRQ ou le même port d'entrées/sorties.
Vous avez probablement une carte ethernet mal configurée. Regardez à deux fois dans le fichier /usr/src/linux/drivers/net/CONFIG. Si tout semble correct, vous pouvez en fait avoir un problème de câblage, vérifiez que vos câbles sont bien branchés.
Vous utilisez une version de route antérieure à celle de votre noyau. Vous devez mettre à jour votre version de route. Référez-vous à la section "Les outils de configuration du réseau" de ce document pour obtenir ces outils.
Ce message signifie que votre machine ou une autre ne sait pas comment atteindre une autre machine. Si vous avez ce message avec toutes les machines que vous essayez de joindre cela signifie que votre route par défaut est mal positionnée. Relisez la section `Routage'.
C'est probablement dû à un problème de routage. Reliser la section `Routage' de ce document. Si tout semble correct, assurez-vous que la machine à laquelle vous essayez de vous connecter possède une route vers vous. Si vous vous connectez en appelant par téléphone, une cause courante est que votre serveur ne fait pas fonctionner de programme comme gated ou routed, ni `prox arping' pour vous, sinon vous pourrez envoyer des paquets aux machines distantes mais elles ne pourront pas vous en envoyer.
Si vous avez le démon NFS Novell alors c'est simple, monter le volume NFS
que vous voulez utiliser. Sinon vous ne pourrez pas le faire directement, il
vous faudra un PC libre. Vous pouvez lancer un programme appelé Stan's Own
Server sur le PC libre. Ensuite configurer le PC en station de travail Novell
avec des cartes pour les répertoires que vous voulez monter NFS, puis lancer
SOS et exporter ces cartes de disques. SOS est disponible à
spdcc.com:pub/sos/sossexe.zooa
Autrement, si vous obtenez une copie de la distribution Caldera Preview, il y est inclus un programme client Netware avec plein de possiblités qui vous permettra d'attacher directement et d'organiser les volumes Novell dans votre sytème de fichiers Linux. Je n'ai pas d'expérience moi-même, mais on m'a assuré que ça marche très bien.
Certains vendeurs (Sun principalement) vendent leurs machines avec NFS sans vérification des checksums UDP. Bien avec ethernet, suicidaire ailleurs. Les checksums UDP peuvent être activées sur la plupart des serveurs. Linux l'a activée par défaut à partir du pl13 - mais les deux parties doivent l'avoir mis en route...
Le serveur NFS Linux est par défaut en lecture seule. RTFM :lisez les pages de man de `exports' et nfsd. Avec des serveurs autres que Linux vous devrez aussi modifier le fichier /etc/exports.
dip n'a pas vraiment besoin de connaître l'adresse de votre
serveur pour fonctionner. L'option remote a été ajoutée pour que
dip puisse automatiser les commandes ifconfig et
route pour vous. Si vous ne connaissez pas ou ne pouvez pas trouver
l'adresse de votre serveur SLIP, Peter D. Junger
Junger@samsara.law.cwru.edu suggère d'utiliser sa propre adresse où le
script dip demande l'adresse distante. C'est un petit truc qui fonctionne bien
car l'adresse du serveur n'apparaît jamais vraiment dans les en-têtes SLIP.
dip a besoin d'être suid root pour réaliser certaines tâches. Uri Blumenthal recommande ceci:
/etc/group et mettez-y chaque personne autorisée.# chown root.dip /usr/bin/dip # chmod u=rx,g=x,o= /usr/bin/dip # chmod u+s /usr/bin/dip
/etc/diphosts.
DIP: tty: set_disc(1): Invalid argument', pourquoi?Cela suggère habituellement que votre noyau n'a pas été compilé avec le support SLIP. Vérifiez que /proc/net/dev contient bien des dispositifs appelés sl0, sl1, etc.. Cela peut signifier aussi que votre version de dip est très vieille. Vous devez alors prendre une version récente.
wrong data byte #17..., pourquoi?Cela signifie en général que votre modem est configuré pour un contrôle de flux XON/XOFF. SLIP doit avoir une ligne 8 bits propre, vous ne pouvez donc utiliser le contrôle XON/XOFF. L'échange de données avec protocole matériel marche mieux, utilisez le.
C'est un désagrément causé par l'utilisation de la compression des en-têtes entre votre machine et le serveur. Vérifier que les deux extrémités de la liaison sont d'accord sur l'utilisation ou non de la compression.
Si vous utilisez dip pour numéroter la ligne SLIP, faites juste `dip -k'. Sinon essayez de tuer le processus dip qui tourne. Quand dip meurt il libère la ligne. Pour lui donner le plus de chance de bien se terminer, essayez la séquence suivante : `kill <pid>', `kill -hup <pid>', et puis `kill -9 <pid>' si le processus ne veut toujours pas mourir. La même méthode peut être appliquée à tout processus unix que vous voulez tuer.
Les outils réseau plus anciens rapportaient incorrectement le nombre de paquets compressés en les comptant comme paquets perdus. Ceci a été corrigé et ne devrait pas vous arriver si vous utilisez une version récente du noyau et des outils. Si cela continue à se produire, cela signifie probablement que votre machine n'arrive pas à suivre le flux de données arrivant. Si vous n'utilisez pas des UART 16550AFN, vous devriez les mettre à niveau. Les 16450 et les 8250 génèrent une interruption pour chaque caractère qu'ils reçoivent et dépendent donc beaucoup de la capacité du processeur à trouver le temps de lire le caractère avant qu'un autre arrive. Les 16500AFN ont un tampon de 16 caractères et ne génèrent une interruption que lorsque le tampon est quasiment plein, ou quand ils ont eu un caractère à attendre. Moins d'interruptions sont donc générées pour la même quantité d'information et donc moins de temps est dépensé à contrôler le port série. Si vous voulez utiliser plusieurs ports série vous devrez obligatoirement utiliser des UART 16550AFN de toute façon.
Oui. Si vous avez, par exemple, trois machines que vous voulez interconnecter. Vous pouvez utiliser deux interfaces SLIP sur une machine et connecter les deux autres machines à la première. Configurez simplement la seconde interface de la même manière que la première. NOTE : la seconde interface aura besoin d'une adresse IP différente de la première. Vous aurez aussi besoin de jouer un peu avec le routage, mais cela devrait fonctionner.
Le noyau est configuré par défaut avec un maximum de 4 pilotes SLIP, ceci
est configuré dans le fichier /usr/src/linux/drivers/net/slip.h. Pour
l'augmenter, disons à 16, mettez 16 pour #define
SL_NRUNIT à la place du 4 qui doit y être. Vous aurez aussi
besoin d'éditer le fichier /usr/src/linux/drivers/net/Space.c pour
ajouter les entrées pour sl4, sl5 etc. Vous pouvez copier les
définitions existantes comme modèles. Vous devrez bien sûr recompiler le noyau
pour que les changements soient effectifs.
Référez-vous à PPP-HOWTO pour une liste de questions-réponses sur PPP rassemblées par Al Longyear.