Voici quelques unes des questions les plus frequemment posees a propos de l'utilisation de Linux avec une connexion Ethernet. Certaines des questions les plus specifiques sont triees `par ordre de constructeur'. Toutefois, puisque par nature ce document est `vieux' au moment ou vous l'obtenez, les `nouveaux' problemes n'apparaitront pas ici de facon instantanee. Pour ceux-ci, je vous suggere d'utiliser intelligement votre lecteur de news. Par exemple, les utilisateurs de `nn' pourront taper
nn -xX -s'3c'
afin d'obtenir tous les articles des groupes auxquels vous avez
souscrits, qui contiennent `3c' dans leur sujet (i.e. 3com, 3c509,
3c503, etc.).
Morale: lisez la page de manuel de votre lecteur de news.
J'ai entendu dire qu'il y avait une version mise-a-jour ou un pilote alpha disponible pour ma carte. Ou puis-je l'obtenir?
Les plus recents des `nouveaux' pilotes peuvent etre trouves sur le
site FTP de Donald: cesdis.gsfc.nasa.gov
dans la
partie /pub/linux/
. Les choses y changent frequemment, donc
jetez-y un coup d'oeil de temps a autre.
Vous pourrez preferer utiliser un navigateur WWW sur:
La page Linux de Donpour localiser le pilote que vous cherchez. (Prenez garde des navigateurs WWW qui modifient le source sans rien dire en remplacant les tabulations par des espaces, etc. - si vous n'etes pas sur(e), utilisez ftp, ou au moins une URL FTP, pour le chargement.)
Maintenant, s'il s'agit reellement d'un pilote alpha, voire pre-alpha, s'il vous plait considerez-le comme tel! En d'autre mots, ne vous plaignez pas parce que vous n'arrivez pas a deviner ce que vous devez en faire. Si vous n'arrivez pas a deviner comment il faut l'installer, alors vous ne devriez certainement pas etre en train de le tester. De meme, s'il plante votre machine, ne vous plaignez pas. A lieu de cela, envoyez-nous un rapport detaille sur le probleme, ou meme mieux, un patch!
Notez que certains des pilotes experimentaux ou alpha `utilisables'
sont inclus dans l'arborescence standard du noyau. Lorsque vous
executez make config
, l'une des premieres choses qui vous sera
demandee est si vous souhaitez etre interroge(e) sur les pilotes en
cours de developpement (``Prompt for development and/or incomplete
code/drivers''). Vous devrez repondre ``Y''
(pour `Yes', `Oui') a cette question si vous
souhaitez etre interroge(e) sur l'inclusion d'un pilote alpha ou
experimental.
Que faut-il faire pour que Linux puisse gerer deux cartes Ethernet?
Linux contient tout ce qu'il faut pour utiliser plusieurs cartes Ethernet. Toutefois, notez que pour le moment, seulement une carte Ethernet est detectee automatiquement par defaut. Cela evite plus facilement des blocages au moment du demarrage causes par la detection de cartes `sensibles'.
Vous pouvez activer la detection automatique de la deuxieme (et de la troisieme, et de...) carte de deux facons differentes.
La methode la plus simple consiste a passer des arguments au noyau
au moment du demarrage, ce qui est generalement fait par LILO.
La detection de la deuxieme carte peut etre obtenue en utilisant un
argument de demarrage aussi simple que ether=0,0,eth1
. Dans ce
cas, eth0
et eth1
seront affectes dans l'ordre dans lequel
les cartes seront trouvees au demarrage. Par contre, si vous
souhaitez que la carte sur le port 0x300
soit eth0
et
que la carte sur le port 0x280
soit eth1
, vous pourrez
utiliser
LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1
La commande ether=
accepte plus d'informations que le numero
d'IRQ + le port d'E/S + le nom qui sont montres ci-dessus.
Veuillez
consulter
Passage des arguments Ethernet...
pour la syntaxe complete, les parametres specifiques a
chaque carte, et des astuces pour LILO.
Ces arguments de demarrage peuvent etre rendus permanents afin de ne
pas devoir les re-entrer a chaque fois. Consultez la documentation
sur l'option de configuration `append
' de LILO.
La seconde methode (non recommandee) est d'editer le fichier
Space.c
et de remplacer la valeur 0xffe0
pour l'adresse
d'entree-sortie par un zero. La valeur 0xffe0
indique au noyau
qu'il ne doit pas essayer de detecter ce peripherique -- la
remplacer par un zero autorisera l'auto-detection du peripherique.
Notez que si vous avez l'intention d'utiliser Linux sur une machine qui servira de passerelle entre deux reseaux, vous devrez recompiler un noyau avec l'option ``IP forwarding''. Mais generalement un vieil AT/286 avec quelque chose comme le logiciel `kbridge' est une meilleure solution.
Si vous consultez ce document tout en surfant sur le reseau, vous pourrez jeter un coup d'oeil a un mini-HOWTO que Donal a sur son site WWW. Consultez
Plusieurs Cartes Ethernet .
Si vous utilisez les modules avec des cartes basees sur la 8390, un seul module peut suffire pour controler plusieurs cartes de la meme marque. Veuillez consulter Les cartes a base de 8390 comme modules pour des informations specifiques sur l'utilisation des modules avec plusieurs cartes.
Voici une liste de quelques clones de la NE-2000 qui sont connus
pour avoir divers problemes. La plupart de ceux-ci ne sont pas
fatals.
Dans le cas de ceux qui sont indiques comme `mauvais clones',
cela signifie que les cartes n'ont pas les deux octets qui
identifient une NE2000. Les clones NEx000 ont une PROM d'adresse de
station (Station Address PROM, SAPROM) dans l'espace-memoire du
tampon de paquets. Les clones NE2000 ont 0x57,0x57
aux octets
0x0e,0x0f
de la SAPROM, tandis que les autres clones NE2000
supposes doivent etre detectes par leur prefixe d'adresse de station.
Cette liste n'est pas une liste exhaustive de tous les clones NE2000
qui ne possedent pas 0x57,0x57
dans les octets 0x0e,0x0f
de la SAPROM. Il en existe certainement des centaines. Si vous
utilisez une carte qui oblige le pilote a indiquer une `signature
invalide' (invalid signature en anglais), vous devrez alors
ajouter la signature de votre carte dans le pilote. La maniere de
proceder est decrite ci-dessous.
Accton NE2000 -- risque de ne pas etre detectee au demarrage, voir ci-dessous.
Artisoft LANtastic AE-2 -- OK, mais a des registres d'indication d'erreur qui fonctionnent imparfaitement.
AT-LAN-TEC NE2000 -- clone qui utilise la puce Winbod qui bloque les pilotes SCSI
ShineNet LCS-8634 -- clone qui utilise la puce Winbod qui bloque les pilotes SCSI
Cabletron E10**, E20**, E10**-x, E20**-x -- mauvais clones, mais le pilote les verifie. Consultez E10** .
D-Link Ethernet II -- mauvais clones, mais le pilote les verifie. Consultez DE-100 / DE-200 .
DFI DFINET-300, DFINET-400 -- mauvais clones, mais le pilote les verifie. Consultez DFI-300 / DFI-400 .
EtherNext UTP8, EtherNext UTP16 -- mauvais clones, mais le pilote les verifie.
Probleme: Une carte PCI clone NE2000 n'est pas detectee au demarrage avec un noyau 2.0.x.
Raison:
Le pilote ne.c
jusqu'a la version 2.0.30 ne connait que le numero
d'identification PCI des cartes clones basees sur la puce 8029 de
RealTek. Comme depuis Winbond et Compex ont eux fait des cartes PCI
clones NE2000, avec des numero d'identification PCI differents, le
pilote ne les detecte pas.
Solution: La solution la plus simple est de mettre a jour votre noyau pour une version 2.0.31 (ou plus recente). Cette derniere connait les identificateurs de pres de cinq puces NE2000 PCI differentes, et les detectera automatiquement au demarrage ou lors du chargement en module.
Autrement, apres le demarrage,
vous pouvez obtenir l'adresse d'E/S (et
d'interruption) que la carte utilisera en faisant
``cat /proc/pci
''.
Disons par exemple que cette commande indique l'IRQ 9 et le port
d'E/S 0xffe0
, alors vous pourrez ajouter au prompt de demarrage
de LILO la commande ether=9,0xffe0,eth0
qui orientera
directement le pilote vers votre carte et evitera les tentatives de
detection basees sur le PCI en meme temps. (Les futurs noyaux des
versions 2.1 et suivantes connaitront les identificateurs PCI des
clones NE2000 de Winbond et Compex, donc ceci ne sera plus
necessaire a ce moment-la.)
Probleme:
Ma carte PCI clone NE2000 est indiquee comme etant une NE1000 (une
carte 8 bits!) au demarrage ou lorsque je charge le module ne.o
sous 2.0.x, et par consequent la carte ne fonctionne pas.
Raison: Certains clones PCI n'implementent pas l'acces de largeur un octet (et par consequent ne sont donc pas reellement compatibles NE2000 a 100%). Cela entraine que la procedure de detection pense qu'il s'agit de cartes NE1000 si la detection PCI n'a pas ete utilisee (ce qui est le cas lorsqu'une adresse d'E/S explicite est donnee au module ou au moment du demarrage).
Solution:
Vous pouvez passer a la version 2.0.31 (ou une version plus
recente) comme dit ci-dessus, ou realiser a la main le changement
suivant dans le fichier drivers/net/ne.c
:
- if (pci_irq_line) + if (pci_irq_line || ioaddr >= 0x400) wordlength = 2; /* Catch broken PCI cards mentioned above. */
ne.o
-- il vaut mieux le laisser detecter automatiquement
la cartes sous ces versions.
Probleme: Ma carte NE2000 PCI a des performances affreuses, meme en reduisant la taille de la fenetre comme il est decrit dans la section sur les trucs pour les performances.
Raison: Les specifications de la puce 8390 originelle, concue et vendue il y a plus de dix ans, notaient qu'une operation de lecture (depuis la puce) etait necessaire avant l'operation d'ecriture pour avoir une securite maximale. Le pilote possede la fonctionnalite de le faire mais cela a ete desactive par defaut depuis les jours des versions 1.2, une fois que le probleme qui causait le plantage avait alors ete localise. Un utilisateur a indique que le fait de re-activer cette `contre-fonctionnalite' avait aide les performances sur une carte PCI clone de NE2000 bon marche.
Solution:
Puisque cela n'a ete rapporte comme solution que par une seule
personne, ne vous echauffez pas trop. Pour re-activer le correctif
de `lecture avant ecriture', il suffit d'editer le fichier
linux/drivers/net/ne.c
, d'enlever les commentaires qui
entourent la ligne contenant NE_RW_BUGFIX
puis de
reconstruire le noyau ou le module selon le cas.
Merci d'envoyer un courrier decrivant la difference de performance
et le type de carte / de puce que vous avez, si cela vous a aide.
Probleme: Ma carte NE*000 bloque ma machine, parfois avec un message `DMA conflict' (conflit DMA), parfois sans aucun message.
Raison: Certains noyaux anciens contenaient des erreurs dans le pilote et les couches superieures du reseau qui causaient ce comportement. Ces erreurs ont ete corrigees il y a bien longtemps, dans les versions 1.2.9 (et superieures) du noyau. Mettez votre noyau a jour.
Probleme: Ma carte NE*000 bloque ma machine pendant la detection des NE, ou il est impossible de lire l'adresse de la station (Station Address, SA) correctement.
Raison:
Les versions du noyau anterieures a la 1.3.7 ne reinitialisaient pas
la carte apres l'avoir trouvee au demarrage. Certaines cartes bon
marche ne sont pas laissees dans un etat raisonnable apres
l'allumage de la machine et doivent etre completement reinitiliasees
avant que le moindre essai soit fait pour les utiliser. De meme,
une procedure de detection precedente a pu deconfigurer la carte NE
avant que la procedure de detection des NE ne prenne place. Dans ce
cas, essayez d'utiliser le mot-cle reserve=
au demarrage afin
de proteger la carte des autres procedures de detection.
Problem:
Le pilote NE*000 indique `not found (no reset ack)
' (carte non
trouvee, pas d'acquittement de la reinitialisation) pendant la
procedure de detection au demarrage.
Raison: Ceci est lie au changement precedent. Apres la verification initiale qu'une 8390 se trouve a l'adresse d'E/S testee, la reinitialisation est effectuee. Quand la carte a termine sa reinitialisation, elle est suppose envoyer un acquittement indiquant que la reinitialisation s'est achevee. Votre carte ne l'a pas fait, et le pilote estime donc qu'aucune carte Ne n'est presente.
Solution:
Vous pouvez indiquer au pilote que vous possedez une mauvaise
carte (bad card) en utilisant une valeur hexadecimale de
0xbad
au moment du demarrage pour le parametre mem_end
(qui n'est normalement pas utilise). Vous devez aussi fournir
une adresse de base non nulle pour les ports d'E/S de la carte
quand vous utilisez la valeur 0xbad
. Par exemple, une carte
qui se trouve a 0x340
et qui n'acquitte pas la
reinitialisation utilisera quelque chose comme:
LILO: linux ether=0,0x340,0,0xbad,eth0
Ceci permettra a la procedure de detection de la carte de continuer,
meme si votre carte n'acquitte pas la reinitialisation. Si vous
utilisez le pilote comme un module, vous pouvez alors fournir
l'option bad=0xbad
exactement comme vous indiquez l'adresse
d'E/S. Notez que les modules des versions 2.0.x ne comprendront pas
l'option bad=
, car elle a ete ajoutee durant le developpement
des versions 2.1.
Probleme: Ma carte NE*000 bloque la machine au premier acces reseau.
Raison: Ce probleme a ete rapporte pour des noyaux aussi vieux que le 1.1.57 jusqu'aux noyaux actuels. Il apparait etre confine a un petit nombre de cartes clones configurables par logiciel. Il apparait que ces cartes s'attendent a etre initialisees d'une maniere speciale.
Solution:
De nombreuses personne ont indique que le fait d'executer le
programme DOS de configuration fourni avec la carte et/ou le pilote
DOS fourni avec la carte avant de redemarrer a chaud (i.e. en
utilisant loadlin
ou le `salut-aux-trois-doigts'
(Ctrl-Alt-Suppr
, NDT)) pour lancer Linux permet a la carte de
fonctionner. Ceci indiquerait que ces cartes doivent etre
initialisees d'une facon particuliere, legerement differente de ce
que le pilote Linux actuel realise.
Probleme:
Ma carte Ethernet NE*000 a l'adresse 0x360
n'est plus detectee.
Raison:
Les noyaux recents ( > 1.1.7X) comprennent plus de verification
de sante mentale
en ce qui concerne les chevauchements de zone d'E/S.
Votre carte NE2000 a une largeur d'espace d'adressage d'E/S de
0x20
, ce qui lui fait atteindre la zone utilisee par le port
parallele a l'adresse 0x378
.
D'autres peripheriques qui pourraient etre a cet endroit-la seraient
le controleur du deuxieme lecteur de disquette (s'il y en a un) a
l'adresse 0x370
le controleur IDE secondaire aux adresses
0x376--0x377
.
Si le(s) port(s) sont deja enregistres par un autre pilote, le noyau
ne laissera pas s'executer la detection.
Solution:
Vous pouvez soit deplacer votre carte vers une adresse d'E/S comme
0x280, 0x340, 0x320
, ou compiler votre noyau sans l'option pour
l'imprimante parallele.
Problem: Le reseau `disparait' a chaque fois que j'imprime quelque chose (NE2000).
Raison: Meme probleme que precedemment, mais vous avez un vieux noyau qui ne verifie pas les chevauchements de zones d'adressage d'E/S. Utilisez la meme solution que ci-dessus, et profitez-en pour recuperer un nouveau noyau, tant qu'a faire.
Probleme:
NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found.
(invalid signature yy zz)
(carte Ethernet NE*000 testee a l'adresse 0xNNN: 00 00 C5 ... non
trouvee, signature yy zz non valide)
Raison:
Avant tout, avez-vous une carte NE1000 ou NE2000 a l'adresse 0xNNN?
Si oui, est-ce que l'adresse materielle indiquee ressemble a une
adresse valide? Si oui, alors vous avez un clone NE*000 bas de
gamme. Tous les clones NE*000 sont supposes avoir la valeur
0x57
dans les octets 14 et 15 de leur SA (Station Address) PROM.
La votre n'a pas ces valeurs -- elle a `yy zz' a la place.
Solution: Il existe deux moyens de contourner ce probleme.
Le plus simple est d'utiliser une valeur 0xbad
pour le
parametre mem_end
comme indique ci-dessus pour le probleme du
non-acquittement de la reinitialisation. Cela evitera la
verification de la signature, pour autant qu'un port d'E/S non nul
soit fourni en meme temps. De cette facon, aucune recompilation du
noyau n'est necessaire.
La seconde methode necessite de changer le pilote lui-meme, puis de
recompiler votre noyau.
Le pilote (usr/src/linux/drivers/net/ne.c/) comporte un "Mur de
la Honte" aux environs de la ligne 42. Cette liste
est utilisee pour detecter les clones bas de gamme.
Par exemple, la carte DFS utilise `DFI' dans les trois premiers
octets de la PROM, au lieu d'utiliser
0x57
aux octets 14 et 15,
tels qu'ils sont supposes etre.
Vous pouvez determiner le contenu des trois premiers octets de la PROM de votre carte en ajoutant une ligne comme:
printk("PROM prefix: %2.2x %2.2x %2.2x\n",SA_prom[0],SA_prom[1],SA_prom[2]);dans le pilote, juste après le message d'erreur que vous avez obtenu ci-dessus, et juste avant le "
return ENXIO
" de la ligne 227.
Redémarrez avec ce changement en place, et après l'échec de la
détection, vous obtiendrez les trois premiers octets de la PROM
comme l'exemple pour DFI ci-dessus.
Vous pourrez alors ajouter votre carte dans la
bad_clone_list[]
aux environs de la ligne 43.
Imaginons que la ligne ci-dessus ait affiché:
PROM prefix: 0x3F 0x2D 0x1C
après que vous ayez redémarré. Et imaginons que la version 8 bits de
votre carte s'appelle la "FOO-1k" et que la version 16 bits s'appelle
la "FOO-2k". Vous pourrez alors ajouter la ligne suivante à la
bad_clone_list[]
:
{"FOO-1k", "FOO-2k", {0x3F, 0x2D, 0x1C,}},
Notez que les deux chaînes de caractères qui contiennent les noms
peuvent être n'importe quoi -- elles sont juste affichées au
démarrage, et ne sont comparées avec rien du tout dans la carte.
Vous pourrez aussi enlever la commande printk()
que vous aviez
ajoutée, si vous voulez. Le noyau ne devrait plus atteindre cette
ligne de toute façon. Puis recompilez une fois de plus, et votre
carte devrait être détectée.
Problème:
Des erreurs comme DMA address mismatch
(l'adresse DMA ne
correspond pas).
Est-ce que la puce est une vraie puce 8390 de National
Semiconductor? (DP8390, DP83901, DP83902 ou DP83905)?
Si ce n'est pas le cas, certaines puces clones n'implémentent pas
correctement le registre de vérification de transfert. Les pilotes
MS-DOS ne font jamais de vérification d'erreur, donc cela ne leur
importe guère. (Note: La vérification d'adresse DMS n'est pas
effectuée par défaut depuis la version 1.2.4 pour
des raisons de performance. Autorisez-la en utilisant la macro
`NE_SANITY
' dans ne.c
si vous souhaitez que la
vérification soit bien effectuée.)
Est-ce que les messages se trompent d'un facteur 2? Si c'est le cas: utilisez-vous la NE2000 dans un emplacement 16 bits? Est-elle configurée pour n'utiliser que des transferts 8 bits?
Le pilote Linux s'attend à ce qu'une carte NE2000 se trouve dans un emplacement 16 bits. Une carte NE1000 peut être dans un emplacement de taille quelconque. Ce problème peut aussi se produire avec certains clones, de façon notoire les anciennes cartes 16 bits de D-Link, qui n'ont pas les octets d'identification corrects dans la SAPROM.
Utilisez-vous le bus ISA à une vitesse supérieure à 8 MHz? Si vous pouvez changer la vitesse (plus rapide ou plus lente), regardez si cela provoque un comportement différent. La plupart des clones NE2000 fonctionneront à 16 MHz, mais certains non. Le changement de vitesse peut aussi masquer un bus bruyant.
Quels autres périphériques y'a-t-il sur le bus? Si le fait de déplacer les périphériques change la fiabilité, alors vous avez un problème de bruit sur le bus -- exactement ce que ce message d'erreur était destiné à détecter. Félicitations, vous avez certainement trouvé la source d'autres problèmes du même coup.
Problème:
La machine se bloque pendant le démarrage après le
message `8390...
' ou le message `WD....
'. Le fait
d'enlever la carte NE2000 résoud le problème.
Solution:
Changez votre adresse d'E/S de base pour une valeur comme 0x340
.
Autre solution, vous pouvez utiliser l'argument de démarrage
``reserve=
'' pour protéger la carte des procédures de
détection des autres pilotes de périphériques.
Raison: Votre clone NE2000 n'est pas un assez bon clone. Une carte NE2000 est un puits sans fond qui attirera tout pilote qui tenterait une détection dans son espace d'adressage. Le fait de changer la carte NE2000 vers une adresse moins populaire l'écartera du chemin des autres procédures de détection automatique, permettant à votre machine de démarrer.
Problème: La machine se bloque pendant la détection du SCSI au démarrage.
Raison:
C'est le même problème que précédemment; changez l'adresse d'E/S de
la carte Ethernet, ou utilisez les arguments de démarrage
reserve
et ether
.
Problème: La machine se bloque pendant la détection de la carte son au démarrage.
Raison: Non, en fait c'est pendant la détection silencieuse du SCSI, et c'est le même problème que ci-dessus.
Problème: Ma carte NE2000 n'est pas détectée au démarrage. Il n'y a aucun message pendant le démarrage.
Solution: Il n'existe pas de `solution magique' parce qu'il existe tout un tas de raisons pour qu'elle ne soit pas détectée. La liste suivante devrait vous aider à parcourir les problèmes possibles.
1) Construisez un nouveau noyau ne contenant que les pilotes de
périphérique dont vous avez besoin.
Vérifiez que vous êtes réellement en train de démarrer le noyau tout
frais. Oublier de lancer lilo
, etc. peut amener à démarrer
l'ancien. (Regardez de près la date et l'heure de compilation
indiquée au démarrage.) Cela peut paraître idiot, mais nous l'avons
tous fait un jour. Assurez-vous que le pilote est bien inclus dans
le nouveau noyau, en consultant le fichier System.map
à la
recherche de noms comme ne_probe
.
2) Consultez attentivement les messages au démarrage.
Est-ce qu'ils mentionnent une tentative de détection d'une NE2000
comme `NE*000 probe at 0xNNN: not found (bla bla)
' ou est-ce
que la détection se contente d'échouer sans rien dire?
Cela fait une grosse différence. Utilisez dmesg|more
pour
relire les messages de démarrage après vous être loggé, ou tapez
Majuscule+PageUp (page précédente) pour faire défiler l'écran vers
le haut après que le démarrage soit terminé et que le prompt de
login soit apparu.
3) Après le démarrage, faites un cat /proc/ioports
et
vérifiez que tout l'espace d'E/S que la carte demandera est vacant.
Si vous avez 0x300
comme adresse de base, alors le pilote
NE2000 demandera la plage d'adresse 0x300-0x31f
. Si un autre
pilote de périphérique a enregistré ne serait-ce qu'un port à
n'importe quel endroit dans cet intervalle, la procédure de
détection ne pourra pas s'effectuer à cette adresse et continuera
sans rien dire jusqu'à la prochaine adresse testée. Un cas classique
est que le pilote lp
(imprimante) réserve 0x378
ou
que le second canal IDE réserve 0x376
ce qui empêche le pilote
ne
de tester la plage 0x360-0x380
.
4) Même chose que précédemment avec cat /proc/interrupts
.
Assurez-vous qu'aucun autre périphérique n'a enregistré
l'interruption que vous avez fixée pour la carte Ethernet. Dans ce
cas, la détection s'effectuera, et le pilote Ethernet se plaindra
vigoureusement au démarrage de ne pas être capable d'obtenir la
ligne d'IRQ désirée.
5) Si vous séchez encore sur l'échec silencieux du pilote, éditez-le
et ajoutez quelques printk()
à la procédure de détection.
Par exemple, avec une NE2000 vous pouvez ajouter/enlever des lignes
(marquées respectivement par un '+' ou un '-') dans net
ne.c/
comme:
int reg0 = inb_p(ioaddr); + printk("NE2k probe - now checking %x\n",ioaddr); - if (reg0 == 0xFF) + if (reg0 == 0xFF) { + printk("NE2k probe - got 0xFF (vacant i/o port)\n"); return ENODEV; + }
Le noyau émettra alors des messages pour chaque port qu'il vérifie, et vous verrez alors si l'adresse de votre carte a été testée ou pas.
6) Vous pouvez aussi récupérer le programme de diagnostic pour
NE2000 sur le site FTP de Don (indiqué dans le Howto) et regarder
s'il est capable de détecter votre carte après que vous ayez démarré
Linux. Utilisez l'option `-p 0xNNN
' pour lui dire où regarder
pour la carte. (La valeur par défaut est 0x300
et il ne va pas
regarder ailleurs, à la différence de la procédure de détection au
démarrage.)
Le résultat, s'il trouve une carte, ressemblera à:
Checking the ethercard at 0x300. Register 0x0d (0x30d) is 00 Passed initial NE2000 probe, value 00. 8390 registers: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00 SA PROM 0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20 SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57 NE2000 found at 0x300, using start page 0x40 and end page 0x80.
Vos valeurs de registres et de PROM seront probablement différentes.
Notez que toutes les valeurs de la PROM sont doublées pour une carte
16 bits, et que l'adresse Ethernet (00:00:c0:b0:05:65
) apparaît
dans la première ligne, et que la signature avec le double 0x57
apparaît à la fin de la PROM.
Le résultat, s'il n'y a aucune carte installée en 0x300
,
ressemblera à:
Checking the ethercard at 0x300. Register 0x0d (0x30d) is ff Failed initial NE2000 probe, value ff. 8390 registers: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Invalid signature found, wordlength 2.
Les valeurs 0xff
apparaissent parce que c'est la valeur qui est
retournée lorsque l'on lit un port d'E/S vacant. Si vous avez un
autre matériel dans la zone qui est testée, vous pourrez voir des
valeurs différentes de 0xff
aussi.
7) Essayez de démarrer Linux à chaud depuis une disquette de
démarrage DOS (via loadlin
) après avoir exécuté le pilote DOS
fourni ou le programme de configuration de la carte. Il se peut
qu'il exécute quelques tours de passe-passe supplémentaires
(c'est-à-dire non standards) pour initialiser la carte.
8) Essayez le pilote en mode paquet (packet driver) ne2000.com
de Russ Nelson pour voir s'il peut au moins voir votre carte -- si
ce n'est pas le cas, alors les choses vont vraiment mal.
Exemple:
A:> ne2000 0x60 10 0x300
Les arguments sont: le vecteur d'interruption logiciel, l'IRQ
matérielle, et le port d'E/S. Vous pouvez obtenir ce programme de
n'importe quelle archive msdos dans le fichier pktdrv11.zip
--
la version actuelle peut avoir un numéro plus récent que 11.
Problème: Vous obtenez des messages semblables au suivant:
eth0: bogus packet size: 65531, status=0xff, nxpg=0xff
Raison: Il y a un problème de mémoire partagée.
Solution:
Les machines PCI qui n'ont pas été configurées pour traduire les
périphériques ISA en mémoire constituent la source la plus courante
pour ce problème. De fait vous lisez la mémoire vive du PC (toutes
les valeurs 0xff
que donne le message) au lieu de la mémoire
vive de la carte, qui elle contient les données du paquet reçu.
D'autres problèmes qui eux sont faciles à régler sont des conflits de carte, le fait d'avoir activé le cache ou la mémoire morte 'shadow ROM' pour cette zone, ou encore de faire fonctionner le bus ISA plus vite que 8 MHz. Il existe aussi un nombre étonnant de pannes de la mémoire sur les cartes Ethernet, donc utilisez le programme de diagnostic si vous en avez un pour votre carte Ethernet.
Problème: Une carte EtherEZ de SMC ne fonctionne pas en mode de mémoire non-partagée (PIO).
Raison: Les versions les plus anciennes du pilote Ultra ne pouvaient utiliser la carte que dans le mode de travail à mémoire partagée.
Solution: Le pilote de la version 2.0 (et supérieures) sait aussi utiliser le mode d'E/S programmées (PIO). Mettez votre noyau à jour vers une version 2.0, ou récupérez le fichier de remplacement pour le noyau 1.2.13 sur le site FTP/WWW de Donald.
Problème: Une vieille wd8003 et/ou une wd8013 configurable par cavaliers ont toujours la mauvaise IRQ.
Raison: Les vieilles cartes wd8003 et les clones wd8013 configurables par cavaliers ne possèdent pas l'EEPROM que le pilote sait lire pour y trouver le paramétrage de l'IRQ. Si le pilote ne sait pas lire l'IRQ, il essaie de déterminer automatiquement l'IRQ. Et si la procédure de détection automatique retourne zéro, le pilote se contente d'affecter l'IRQ 5 pour une carte 8 bits ou l'IRQ 10 pour une carte 16 bits.
Solution: Evitez le code de détection automatique de l'IRQ, et indiquez au noyau la valeur d'IRQ que vous avez configurée sur la carte avec les cavaliers en la lui passant comme argument au démarrage. Par exemple, si vous utilisez l'IRQ 9, la ligne suivante devrait fonctionner.
LILO: linux ether=9,0,eth0
Problème: Une carte SMC Ultra est détectée comme étant une wd8013, mais l'IRQ et l'adresse de base de la mémoire partagée sont fausses.
Raison: La carte Ultra ressemble beaucoup à une wd8013, et si le pilote Ultra n'est pas présent dans le noyau, le pilote wd peut identifier l'Ultra comme étant une wd8013. Le test de détection de l'Ultra vient avant celui de la wd, donc ceci ne devrait normalement pas se produire. L'Ultra stocke l'IRQ et l'adresse de base dans son EEPROM de façon différente à celle d'une wd8013, d'où les valeurs erronées indiquées par le pilote.
Solution: Recompilez le noyau en n'intégrant que les pilotes dont vous avez besoin. Si vous avez un mélange de cartes wd et Ultra dans une machine, et que vous utilisez les modules, chargez le module ultra en premier.
Problème: La 3c503 prend l'IRQ N, mais celle-ci est requise par un autre périphérique qui a besoin de l'IRQ N (par exemple un pilote de CD-ROM, un modem, etc.). Est-ce que cela peut être réparé sans devoir le compiler dans le noyau?
Solution:
Le pilote 3c503 recherche une ligne d'IRQ libre dans
l'ordre {5, 9/2, 3, 4}, et il devrait prendre une ligne qui n'a pas
été utilisée. Le pilote effectue ce choix lorsque la carte est
configurée (ifconfig
).
Si vous utilisez un pilote en module, vous pouvez vous servir des paramètres du module afin de choisir diverses choses, y compris la valeur d'IRQ.
Ce qui suit sélectionne l'IRQ 9,
adresse de base 0x300, <une valeur ignorée>, et le
port if_port
numéro 1 (le transceiver externe).
io=0x300 irq=9 xcvr=1
Autrement, si le pilote est compilé dans le noyau, vous pouvez choisir les mêmes valeurs en passant des paramètres via LILO.
LILO: linux ether=9,0x300,0,1,eth0
Ce qui suit sélectionne l'IRQ 3, détecte l'adresse de base,
<une valeur ignorée>, et le port par défaut (if_port
)
numéro 0 (le transceiver interne).
LILO: linux ether=3,0,0,0,eth0
Problème:
3c503: configured interrupt X invalid, will use autoIRQ.
(3c503: l'interruption X configurée est invalide,
détection automatique de l'IRQ)
Raison:
La 3c503 ne peut utiliser que l'une des IRQ 5, 2/9, 3 ou 4
(ce sont les seules lignes d'IRQ qui sont connectées à la carte).
Si vous passez en argument au noyau une valeur d'IRQ qui n'est pas
dans cet ensemble, vous obtiendrez le message ci-dessus.
Normalement, il n'est pas nécessaire de spécifier une valeur
d'interruption pour la 3c503. Elle passera en détection automatique
lorsqu'elle sera configurée (par ifconfig
), et elle prendra
l'une des IRQ 5, 2/9, 3 ou 4.
Solution: Utilisez l'une des IRQ valides données ci-dessus, ou autorisez la détection automatique en ne précisant aucune ligne d'IRQ.
Problem: Le pilote 3c503 fourni n'utilise pas le port AUI (gros Ethernet). Comment faire pour le choisir au lieu du port Ethernet fin par défaut?
Solution:
Le port AUI peut être sélectionné au démarrage pour les pilotes
compilés dans le noyau, et lors de l'insertion du module pour les
pilotes modulaires.
La sélection est surchargée dans le bit de poids le plus faible de
la variable dev->rmem_start
qui n'est actuellement pas
utilisée, donc un paramètre de démarrage comme:
LILO: linux ether=0,0,0,1,eth0
devrait fonctionner pour les pilotes compilés dans le noyau.
Pour spécifier le port AUI lorsque vous chargez un module, ajoutez
simplement xcvr=1
à la ligne d'options du module avec vos
valeurs de port d'E/S et d'IRQ.
La raison habituelle de cet état de fait est que les gens utilisent un noyau qui ne contient pas le code pour leur carte à eux. Pour un noyau modulaire, cela signifie généralement que le chargement du module nécessaire n'a pas été demandé, ou qu'une adresse d'E/S a besoin d'être spécifié comme option du module
Si vous utilisez un noyau basé sur les modules, comme ceux
installés par la plupart des distributions Linux, essayez alors
d'utiliser l'utilitaire de configuration de la distribution pour
sélectionner le module destiné à votre carte. Pour les cartes ISA,
c'est une bonne idée que de déterminer l'adresse d'E/S de la carte
et de l'ajouter comme option (p. ex. io=0x340
) si l'utilitaire
de configuration vous le demande. S'il n'y a pas d'utilitaire de
configuration, vous devrez alors ajouter le nom exact du module (et
ses options) au fichier /etc/conf.modules
-- lisez
man modprobe
pour plus de détails.
Si vous utilisez un noyau précompilé qui provient d'une distribution Linux, vérifiez dans la documentation quel noyau vous avez installé, et s'il a été construit en incluant le code pour votre carte à vous. Si ce n'est pas le cas, vous pouvez soit essayer d'en obtenir un qui contient le code pour votre carte, soit construire votre propre noyau.
C'est en général une bonne chose que de construire votre propre noyau, ne contenant que les pilotes dont vous avez besoin, car cela diminue considérablement la taille du noyau (préservant d'autant votre précieuse mémoire vive pour les applications!) et cela réduit le nombre de procédure de détection de périphériques qui peuvent déranger le matériel un peu sensible. Construire un nouveau noyau n'est pas aussi compliqué que cela peut paraître. Vous devez juste répondre oui ou non à tout un tas de questions sur les pilotes que vous voulez, et le système fait le reste.
La seconde raison essentielle est qu'un autre périphérique utilise
une partie de l'espace d'adressage d'entrée-sortie dont votre carte
a besoin. La plupart des cartes ont une zone d'adressage qui mesure
16 ou 32 bits de largeur. Si votre carte est positionnée
en 0x300
et qu'elle prend 32 octets, alors le pilote demandera
la plage d'adresses 0x300-0x31f
. Si un autre pilote de
périphérique a enregistré ne serait-ce qu'un port d'entrée-sortie,
où que ce soit dans cet intervalle, la procédure de détection
n'aura pas lieu à cette adresse et le pilote continuera sans rien
dire à l'adresse suivante à tester. Donc, après le démarrage,
faites un cat /proc/ioports
et vérifiez que tout l'espace
d'adressage d'entrée-sortie que la carte demandera est bien
disponible.
Autre problème: votre carte est configurée pour une adresse
d'entrée-sortie qui n'est pas testée par défaut.
Il existe une liste
(voir section
adresses testées
) pour
chaque carte de ce document. Même si la configuration d'E/S de votre
carte n'est pas dans la liste des adresses testées, vous pouvez
l'indiquer au démarrage (pour les pilotes compilés dans le noyeau
en utilisant la commande ether=
comme il est décrit
dans
Passage des arguments Ethernet...
.
Les pilotes modulaires peuvent utiliser l'option io=
afin de
spécifier une adresse qui n'est pas testée par défaut.
ifconfig
indique la mauvaise adresse d'E/S pour la carte.Non, ce n'est pas vrai. C'est vous qui l'interprêtez de manière
erronée. Ce n'est pas une erreur, et les nombres indiqués sont
corrects. Ce qu'il se passe, c'est que certaines cartes à base
de 8390 (wd80x3, smc-ultra, etc.) sont telles que la puce 8390 se
trouve décalée par rapport au premier port d'E/S affecté.
Il s'agit de la valeur
stockée dans dev->base_addr
, qui est celle que ifconfig
indique. Si vous souhaitez voir l'intervalle complet d'adresses de
ports que votre carte utilise, vous devriez essayer
cat /proc/ioports
qui vous donnera le nombre que vous
attendez.
Les BIOS PCI les plus récents peuvent ne pas activer toutes les cartes PCI lors de l'allumage de la machine, spécialement si l'option `PNP OS' du BIOS est activée. Cette contre-fonctionnalité est destinée à supporter la prochaine version de Windows qui utilise encore des pilotes en mode réel. Vous pouvez soit inhiber cette option, soit essayer de mettre à jour votre pilote pour une version qui comprend le code capable d'activer une carte désactivée.
Ce problème se montre habituellement sous la forme d'un tas de
valeurs 0xffff
en lecture. Aucune carte à mémoire partagée de
quelque type que ce soit ne fonctionnera dans une machine PCI à
moins que vous n'ayez configuré correctement le BIOS PCI
(PCI ROM BIOS
CMOS SETUP/ ou quelque chose comme ça).
Vous devez le configurer pour permettre l'accès à la mémoire
partagée depuis le bus ISA pour la zone d'adresses que votre carte
essaie d'utiliser. Si vous n'arrivez pas à déterminer quels
paramètres sont concernés, interrogez votre revendeur ou votre
gourou informatique local. Dans un BIOS AMI (American Megatrends
Inc.), il existe en général une section ``Plug and Play'' où se
trouveront sans doute des paramètres ``ISA Shared Memory Size''
(taille de la mémoire partagée ISA) et ``ISA Shared Memory Base''
(adresse de base de la mémoire partagée ISA). Pour des cartes comme
la wd8013 et la SMC Ultra, changez la taille de sa valeur par
défaut (`Disabled', désactivé) à une valeur de 16 Ko, et changez
l'adresse de base en prenant l'adresse de base de mémoire
partagée qui correspond à votre carte.
Un problème dans le processeur NexGen fait que tous les utilisateurs de cartes basées sur la puce 8390 (wd80x3, 3c503, SMC Ultra/EtherEZ, ne2000, etc.) obtiennent ces messages d'erreur. Les versions du noyau 2.0 et supérieures n'ont pas ces problèmes.
Mettez votre noyau à jour.
Werner Almesberger s'est préoccupé de la disponibilité d'ATM pour Linux. Il a travaillé avec la carte ENI155p d'Efficient Networks ( Efficient Networks ) et la carte ZN1221 de Zeitnet ( Zeitnet ).
Werner dit que le pilote de la ENI155p est relativement stable, tandis que celui de la ZN1221 n'est actuellement pas terminé.
Consultez les dernières informations et les mises à jour à l'URL suivante:
Linux et ATM
Ou en est le support Ethernet Gigabit pour Linux?
Un pilote pour l'adaptateur Ethernet Gigabit G-NIC PCI de Packet Engines devrait être ajouté dans l'imminente version 2.0.34 du noyau. Pour plus de détails, d'information, et les mises à jour du pilote, consultez:
http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html
Qu'en est-il de FDDI sous Linux?
Cela fonctionne. Larry Stefani a écrit un pilote pour la version 2.0 du noyau pour les cartes DEFEA (FDDI EISA) et DEFPA (FDDI PCI) de DEC (Digital Equipment Corporation). Il a été inclus dans la version 2.0.24 du noyau. Néanmoins, ce sont les seules cartes qui fonctionnent sous Linux actuellement.
Est-ce que le mode Full Duplex me donnera 20 Mbit/s? Est-ce que Linux sait faire du Full Duplex?
Cameron Spitzer écrit ce qui suit à propos des cartes Full Duplex 10Base-T:
``Si vous connectez une carte Full Duplex à un hub (NDT: un switch) Full Duplex, et que votre système est suffisamment rapide et ne fait pas grand-chose d'autre, il pourra maintenir le lien occupé dans les deux directions.
Le Full Duplex 10Base-2 ou 10Base-5 (coaxial fin et gros coaxial) ne peut pas exister. Le mode Full Duplex fontionne en inhibant la détection des collisions dans l'adaptateur réseau. C'est pour cela que vous ne pouvez pas le faire avec un coax: le réseau ne fonctionnerait pas si c'était le cas.
Par contre, 10Base-T (l'interface RJ-45) utilise des (paires de) fils séparées pour l'émission et la réception, donc il est possible de travailler dans les deux sens en même temps. Le (hub) switch s'occupe du problème des collisions. La vitesse de signalisation reste à 10 Mbit/s.''
Donc, comme vous pouvez voir, vous ne serez encore capable que de recevoir ou de transmettre à 10 Mbit/s; n'attendez donc pas une multiplication par deux des performances. Quant à savoir si cela est possible ou non, cela dépend de la carte et peut-être du pilote. Certaines cartes pratiquent l'auto-négociation, d'autres auront besoin de l'aide du pilote, et d'autres auront besoin que l'utilisateur choisisse une option dans la configuration sur EEPROM de la carte. De toute façon, seul l'utilisateur sérieux/chargé notera la différence entre les deux modes.
En ce qui concerne les versions 2.0, seules les cartes 3C509, depca, de4x5 lance32, et tous les pilotes pour 8390 (wd, smc-ultra, ne, 3c503, etc.) ont été rendus `indépendants de l'architecture' de façon à pouvoir fonctionner sur les systèmes basés sur les processeurs Alpha de DEC.
Notes que les changements à faire ne sont pas aussi compliqués que ça. Vous n'avez besoin que de:
-multiplier toutes les valeurs relatives à des jiffies
par
HZ/100
pour prendre en compte la valeur différente de
HZ
utilisée par l'Alpha.
(c'est-à-dire que timeout=2;
devient
timeout=2*HZ/100;
)
-remplacer tout déréférencement de pointeur en mémoire d'E/S (640k à
1Mo) par les appels readb() writeb() readl() writel()
appropriés, comme le montre cet exemple:
- int *mem_base = (int *)dev->mem_start; - mem_base[0] = 0xba5eba5e; + unsigned long mem_base = dev->mem_start; + writel(0xba5eba5e, mem_base);
-remplacer tous les appels à memcpy()
qui ont des adresses
mémoire sur la plage d'E/S comme source ou comme destination par
un appel à memcpy_fromio()
ou à memcpy_toio()
selon le
cas.
Vous trouverez plus de détails sur la manière de gérer les accès
mémoire d'une façon indépendante de l'architecture dans le fichier
linux/Documentation/IO-mapping.txt
qui est présent dans les
noyaux récents.
Est-ce que je peux relier deux systèmes basés sur du 10BaseT (RJ45) sans utiliser de hub?
Vous pouvez relier facilement deux machines, mais pas plus que cela, sans boîtier supplémentaire. Consultez la section Paire torsadée qui explique comment faire.
Par contre, non, vous n'arriverez pas à bricoler un hub en croisant quelques fils et autres trucs du genre. Il est pratiquement impossible de générer correctement le signal de collision sans re-faire un hub.
J'obtiens un nombre impressionnant de messages
`SIOCSIFxxx: No such device
' au démarrage, suivis par un
`SIOCADDRT: Network is unreachable
'.
Qu'est-ce qui ne va pas?
Votre périphérique Ethernet n'a pas été détecté pendant le
démarrage / lors de l'insertion du module,
et lorsque ifconfig
et route
sont exécutés, ils
n'ont aucun périphérique avec lequel travailler. Utilisez
dmesg | more
pour consulter les messages du démarrage et
regardez s'il y a un (ou des) message(s) à propos de la détection de
carte Ethernet.
J'obtiens `SIOCSFFLAGS: Try again
' lorsque j'exécute
ifconfig
-- Euh..?
Un autre périphérique a pris l'IRQ que votre carte Ethernet essaie
d'utiliser, ce qui fait que la carte ne peut pas utiliser l'IRQ.
Vous n'avez pas nécessairement besoin de redémarrer pour résoudre ce
problème, car certains périphériques ne prennent les IRQ que
lorsqu'ils en ont besoin, et qu'ils les rendent quand ils ont fini.
C'est le cas par exemple des cartes son, des ports série, le
pilote du lecteur de disquette, etc. Vous pouvez taper
cat /proc/interrupts
pour voir quelles interruptions sont
actuellement en cours d'utilisation. La plupart des pilotes de
de carte Ethernet sous Linux ne prennent l'IRQ que lorsqu'ils sont
ouverts via `ifconfig
'. Si vous réussissez à faire en sorte que
l'autre périphérique `relâche' la ligne d'IRQ, alors vous serez
capable de réessayer (Try again en anglais) avec ifconfig
.
Lorsque j'utilise ifconfig
sans argument, il indique
Link UNPSEC
(au lieu de `Ethernet 10Mbs') et il dit aussi que
mon adresse physique est à zéro.
C'est parce que les gens utilisent une version du programme
`ifconfig' plus récente que leur version de noyau. Cette nouvelle
version de `ifconfig' est incapable de fournir ces informations
quand elle est utilisée en conjonction avec un noyau plus ancien.
Vous pouvez soit mettre votre noyau à jour, soit prendre une version
plus ancienne d'ifconfig
, ou simplement ignorer le problème.
Le noyau connaît votre adresse physique, donc le fait que
ifconfig
ne puisse pas la lire n'est pas vraiment important.
Vous pourrez aussi obtenir des informations étranges si le programme
ifconfig
que vous utilisez est beaucoup plus vieux que votre
noyau.
Quand j'exécute ifconfig
sans argument, il indique que j'ai un
nombre faramineux d'erreurs à la fois dans les paquets reçus et dans
les paquets transmis. Pourtant tout semble fonctionner correctement
-- Est-ce que je me trompe?
Regardez de nouveau. ifconfig
indique:
RX packets
gros nombre BLANC
errors 0
BLANC
dropped 0
BLANC
overrun 0
.
Même chose pour la colonne avec TX
.
Les grands nombres que vous voyez sont donc le nombre total de
paquets que votre machine a reçus et transmis.
Si vous trouvez encore que c'est source de confusion, essayez de
taper cat /proc/net/dev
à la place.
/dev/
pour cartes EthernetJ'ai /dev/eth0
qui est un lien vers /dev/
xxx.
Est-ce que c'est bon?
Contrairement à ce que vous avez entendu dire, les fichiers dans
/dev/*
ne sont pas utilisés. Vous pouvez détruire tous les
/dev/wd0, /dev/ne0
et ce qui y ressemble.
Dois-je désactiver les ``trailers'' quand je `ifconfig'ure ma carte Ethernet?
Vous ne pouvez pas désactiver les ``trailers'', et vous ne devriez pas en avoir envie. Les ``trailers'' sont une astuce de programmation pour éviter des copies de données dans les couches réseau. L'idée était d'utiliser un en-tête simpliste de taille fixe `H', de mettre les informations de l'entête de taille variable à la fin du paquet, et d'allouer tous les paquets `H' octets avant le début d'une page. Bien qu'il s'agissait d'une bonne idée, en pratique cela n'a pas très bien fonctionné.
Si quelqu'un suggère l'utilisation de `-trailers', notez bien que c'est l'équivalent du sang de chèvres sacrifiées. Cela ne résoudra pas le problème, mais si le problème se résoud tout seul, quelqu'un pourra invoquer des connaissances approfondies en magie.
Comment puis-je avoir accès directement au périphérique Ethernet sous Linux, sans avoir à passer par TCP/IP et ses copains?
int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
Ceci vous donne une socket qui peut recevoir tous les types de
protocoles. Utilisez l'appel recvfrom
sur cette socket, cela
remplira la structure sockaddr
avec le type de périphérique
dans le champ sa_family
et le nom du périphérique dans le
tableau sa_data
.
Je ne sais pas qui a inventé SOCK_PACKET
pour Linux (cela fait
une éternité qu'il est là), mais c'est du beau travail. Vous pouvez
l'utiliser pour envoyer des choses directement en utilisant l'appel
sendto
.
Bien entendu, vous devez être root pour pouvoir faire l'ensemble de ces opérations.
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