eth0 eth1 eth2...comment est-ce attribué ?

begin{digression}
Les nom en ethi sont attribués avec i croissant à chaque nouvelle interface
réseau créée. En particulier, il suffirait de changer l'ordre de chargement
des modules pour changer les noms de tes interfaces. Ce n'est donc pas très
robuste, il serait plus propre de s'arranger pour qu'à leur création, elles
soient renommées en un nom canonique. Je crois que ça se fait avec nameif.
end{digression}

Si tu n'as pas de ethi associé à ta troisième carte, a priori, c'est que le
module qui lui correspond n'est pas chargé. Si il est chargé, c'est qu'il ne
la reconnait pas, et là, il y a un problème.

Serge Sauton wrote in message <45994899$0$320$426a34cc@news.free.fr>:

Subject: eth0 eth1 eth2...comment est-ce attribué ?

Dans l'ordre où les cartes sont détectées. Du coup, compter dessus pour une
configuration robuste n'est vraiment pas une bonne idée. Il faut utiliser un
critère persistant, comme l'adresse MAC, pour attribuer des noms fiables.
Par exemple, chez moi, j'ai ceci :

ssecem ~ $ cat /etc/udev/rules.d/0net.rules
# Integrated
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*",
SYSFS{address}=="00:18:f3:04:74:ce", NAME="eth0"

# 3Com
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*",
SYSFS{address}=="00:04:76:9b:2a:b2", NAME="eth1"

Les configurations par défaut d'udev ont parfois une règle qui crée des
règles persistantes pour les nouvelles cartes réseau, mais bof.

Et ça ne fonctionne pas...en fait, j'ai l'impression que "eth2" est
"réservé" par le module eth1394 pour mes ports firewire :

Ce n'est pas réservé, c'est utilisé pour, mais ça n'a rien d'irréversible.

dmesg | grep eth

Regarde plutôt dans /sys/class/net, en particulier les fichiers vendor et
device du répertoire lié par device, qui doivent correspondre à la sortie de
lspci -n.

forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
eth0: forcedeth.c: subsystem: 01043:80a7 bound to 0000:00:04.0
eth1: RealTek RTL8139 at 0x9000, 00:08:54:06:36:23, IRQ 209
eth1: Identified 8139 chip type 'RTL-8100B/8139D'
eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
eth1394: eth3: IEEE-1394 IPv4 over 1394 Ethernet (fw-host1)
eth1: link up, 10Mbps, full-duplex, lpa 0x4061
eth0: no IPv6 routers present
eth1: no IPv6 routers present

On dirait que la 3Com n'est pas détectée, mais ce n'est pas complètement
probant.

de plus j'ai les messages d'erreurs suivants :
sit0: unknown hardware address type 776
<snip>

De la part de qui ?

J'ai aussi essayé de charger le module associé en créant un fichier
/tc/modprobe.d/reseau :
alias eth2 3c59x

Non, ça c'est tout vieux et ça ne sert plus. Et surtout c'est complètement
confusogène, ça n'a jamais servi à associer un nom/numéro d'interface à un
driver.

Essaie de charger explicitement
le module avec modprobe : si ta carte est alors reconnue, il va falloir
comprendre pourquoi le module n'est pas chargé automatiquement ; si elle ne
l'est pas, il faut trouver pourquoi.

Merci pour cette réponse détaillée.

ssecem ~ $ cat /etc/udev/rules.d/0net.rules
# Integrated
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*",
SYSFS{address}=="00:18:f3:04:74:ce", NAME="eth0"

# 3Com
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*",
SYSFS{address}=="00:04:76:9b:2a:b2", NAME="eth1"

c'est interessant ça...je vais essayer de me lance...

Regarde plutôt dans /sys/class/net, en particulier les fichiers vendor et
device du répertoire lié par device, qui doivent correspondre à la sortie de
lspci -n.

alors là, il y a un truc bizarre...

~ ls /sys/class/net/
eth0/ eth1/ eth2/ eth2_rename_ren/ eth3/ lo/ sit0/

et en regardant vers quoi pointe les liens "devices@" de chaque
répertoire, je vois que eth2 correspond au port firewire et c'est
eth2_rename_ren qui correspond à ma troisième interface réseau.

~ ls /sys/class/net/eth2_rename_ren/device -ail
/sys/class/net/eth2_rename_ren/device ->
../../../devices/pci0000:00/0000:00:0c.0/0000:02:01.0/

~ lspci

0000:02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated
Fast Ethernet Controller [Tornado] (rev 40)

On dirait que la 3Com n'est pas détectée, mais ce n'est pas complètement
probant.

pourtant le module 3c59x est bien chargé.
en plus, avant que j'ajoute la carte réseau pci Realtek, la 3com était
bien reconnue et fonctionnait bien...

sit0: unknown hardware address type 776
<snip>

De la part de qui ?

je sais pas...c'est au boot... :-(


Merci.

--
Serge Sauton

Serge Sauton wrote in message <4599622e$0$290$426a34cc@news.free.fr>:

alors là, il y a un truc bizarre...

~ ls /sys/class/net/
eth0/ eth1/ eth2/ eth2_rename_ren/ eth3/ lo/ sit0/

Ça, c'est _exactement_ ce que j'avais avec les tentatives automatiques de
noms d'interfaces persistantes d'udev. Dans /etc/udev.d/rules.d/, tu as
probablement un fichier avec « persistent-net-generator » dans le nom. Je
conseille vivement de le virer ; et d'autre part, un « persistent-net » qui
a été créé par le précédent, qu'il faudrait éditer pour donner des noms plus
sains à tout.

pourtant le module 3c59x est bien chargé.
en plus, avant que j'ajoute la carte réseau pci Realtek, la 3com était
bien reconnue et fonctionnait bien...

En fait, je viens de vérifier, le problème est que le driver 3Com n'affiche
pas la chaîne « eth », du coup ton « dmesg | grep eth » ne voit rien.

je sais pas...c'est au boot... :-(

Ce serait quand même intéressant de le déterminer, en regardant plus
précisément avant et après quoi ça apparaît.

Salut,

Subject: eth0 eth1 eth2...comment est-ce attribué ?

Dans l'ordre où les cartes sont détectées. Du coup, compter dessus pour une
configuration robuste n'est vraiment pas une bonne idée. Il faut utiliser un
critère persistant, comme l'adresse MAC, pour attribuer des noms fiables.

L'ennui avec l'adresse MAC, c'est quand on doit remplacer une carte en
panne par une autre de même modèle mais qui aura forcément une adresse
MAC différente (à moins de la reprogrammer). Un autre critère persistant
peut être la localisation sur le bus PCI (la suite de chiffres
qu'affiche lspci) combinée aux Vendor ID/Device ID PCI.

[...]

de plus j'ai les messages d'erreurs suivants :
sit0: unknown hardware address type 776

<snip>

De la part de qui ?

Du client DHCP dhclient, il me semble. J'ai le même concernant sit0.

J'ai aussi essayé de charger le module associé en créant un fichier
/tc/modprobe.d/reseau :
alias eth2 3c59x

Non, ça c'est tout vieux et ça ne sert plus. Et surtout c'est complètement
confusogène, ça n'a jamais servi à associer un nom/numéro d'interface à un
driver.

En effet. L'intérêt des alias de modules peut être d'associer des alias
à plusieurs jeux d'options différentes pour un même module et/ou de
charger plusieurs fois un même module (utile pour le bonding par
exemple), mais *en aucun cas* de définir le nom d'une interface. Ce
n'est pas fiable.

Pascal Hambourg wrote in message <enc1io$n74$1@biggoron.nerim.net>:

L'ennui avec l'adresse MAC, c'est quand on doit remplacer une carte en
panne par une autre de même modèle mais qui aura forcément une adresse
MAC différente (à moins de la reprogrammer). Un autre critère persistant
peut être la localisation sur le bus PCI (la suite de chiffres
qu'affiche lspci) combinée aux Vendor ID/Device ID PCI.

Pour changer une carte réseau, il faut de toutes façons rebooter la machine.
Alors éditer une règle udev en plus ou en moins... Quelle que soit la
manière dont on cherche à caractériser la carte, on trouvera toujours un
scénario qui la met en échec.

Du client DHCP dhclient, il me semble. J'ai le même concernant sit0.

Mais de quoi il se mêle ? Qui lui demande de toucher à sit0 ?

En effet. L'intérêt des alias de modules peut être d'associer des alias
à plusieurs jeux d'options différentes pour un même module et/ou de
charger plusieurs fois un même module (utile pour le bonding par
exemple),

Charger plusieurs fois le même module, j'ai de gros doutes, mais bon.

Dans /etc/udev.d/rules.d/, tu as
probablement un fichier avec « persistent-net-generator » dans le nom.

~ ls /etc/udev
alsa-utils.rules links.conf
cd-aliases-generator.rules logitechmouse.rules
compat-full.rules permissions.rules
compat.rules persistent-input.rules
devfs.rules persistent-net-generator.rules
hal.rules persistent.rules
hotplugd.rules rules.d/
hotplug.rules run.rules
kino.rules udev.conf
libgphoto2_generic_ptp_support.rules udev.rules
libgphoto2.rules xserver-xorg-input-wacom.rules
libsane.rules


~ ls /etc/udev/rules.d
020_libgphoto2_generic-ptp_support.rules@ z25_persistent-cd.rules
020_permissions.rules@ z25_persistent-net.rules
025_libgphoto2.rules@
z45_persistent-net-generator.rules@
025_libsane.rules@ z50_run.rules@
025_logitechmouse.rules@ z55_hotplug.rules@
035_kino.rules@ z60_alsa-utils.rules@
udev.rules@
z60_xserver-xorg-input-wacom.rules@
z20_persistent-input.rules@ z75_cd-aliases-generator.rules@
z20_persistent.rules@ z99_hal.rules@

Je conseille vivement de le virer

donc, je détruis "persistent-net-generator.rules" ou le lien symbolique
z45_persistent-net-generator.rules@ ?

et d'autre part, un « persistent-net » qui
a été créé par le précédent, qu'il faudrait éditer pour donner des noms plus
sains à tout.

il y a "persistent.rules" et "persistent-input.rules" dans /etc/udev.
Mais dans aucun, n'apparaît une règle pour "eth*" me semble-t-il.
Par contre, dans /etc/udev/rules.d, il y a z25_persistent-net.rules...

~ more z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:e0:18:f7:71:0c",
NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:26:54:09:f8:75",
NAME="eth1"

SUBSYSTEM=="net", DRIVERS=="?*",
ATTRS{address}=="00:e0:18:00:00:11:32:42", NAME="eth2"

SUBSYSTEM=="net", DRIVERS=="?*",
ATTRS{address}=="00:00:00:00:00:03:11:53", NAME="eth3"

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:08:54:06:36:23",
NAME="eth1"

Est-ce bien ce fichier que je dois modifier à mon goût ?

Ce serait quand même intéressant de le déterminer, en regardant plus
précisément avant et après quoi ça apparaît.

en fait, lorsque je lance le réseau :

~ /etc/init.d/networking restart
Setting up IP spoofing protection: rp_filter.
Reconfiguring network interfaces...ifup: interface lo already configured
Internet Software Consortium DHCP Client 2.0pl5
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.

Please contribute if you find this software useful.
For info, please visit http://www.isc.org/dhcp-contrib.html

sit0: unknown hardware address type 776
eth3: unknown hardware address type 24
eth2: unknown hardware address type 24
sit0: unknown hardware address type 776
eth3: unknown hardware address type 24
eth2: unknown hardware address type 24
Listening on LPF/eth1/00:08:54:06:36:23
Sending on LPF/eth1/00:08:54:06:36:23
Sending on Socket/fallback/fallback-net
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 81.56.179.254
...


Merci beaucoup.

--
Serge Sauton

Pascal Hambourg wrote in message <enc1io$n74$1@biggoron.nerim.net>:

L'ennui avec l'adresse MAC, c'est quand on doit remplacer une carte en
panne par une autre de même modèle mais qui aura forcément une adresse
MAC différente (à moins de la reprogrammer). Un autre critère persistant
peut être la localisation sur le bus PCI (la suite de chiffres
qu'affiche lspci) combinée aux Vendor ID/Device ID PCI.

Pour changer une carte réseau, il faut de toutes façons rebooter la machine.
Alors éditer une règle udev en plus ou en moins... Quelle que soit la
manière dont on cherche à caractériser la carte, on trouvera toujours un
scénario qui la met en échec.

En effet, si on se base seulement sur :
- l'adresse MAC -> reconnaît la carte si on la change de slot mais pas
une carte de remplacement ;
- la localisation sur le bus -> reconnaît n'importe quelle carte dans le
même slot mais pas si on la déplace dans un autre slot ;
- les identifiants Vendor et Devide ID -> reconnaît la carte dans
n'importe quel slot ou une carte de remplacement, mais problème si
plusieurs cartes du même modèle présentes.

Bref, il faut choisir en fonction de la situation la plus fréquente.

Du client DHCP dhclient, il me semble. J'ai le même concernant sit0.

Mais de quoi il se mêle ? Qui lui demande de toucher à sit0 ?

Bonne question, d'autant plus qu'il est invoqué avec une autre interface
bien déterminée. Je suppose qu'il contient un bout de code qui examine
toutes les interfaces réseau connues.

En effet. L'intérêt des alias de modules peut être d'associer des alias
à plusieurs jeux d'options différentes pour un même module et/ou de
charger plusieurs fois un même module (utile pour le bonding par
exemple),

Charger plusieurs fois le même module, j'ai de gros doutes, mais bon.

Et pourtant, c'est explicitement mentionné dans le fichier bonding.txt
qui se trouve dans la documentation du noyau
(Documentation/networking/bonding.txt) au paragraphe traitant de la
création de plusieurs interfaces bonding avec des paramètres différents.

========================[début citation]==============================
Configuring Multiple Bonds
=========================
If several bonding interfaces are required, either specify the max_bonds
parameter (described above), or load the driver multiple times. Using
the max_bonds parameter is less complicated, but has the limitation that
all bonding instances created will have the same options. Loading the
driver multiple times allows each instance of the driver to have differing
options.

For example, to configure two bonding interfaces, one with mii link
monitoring performed every 100 milliseconds, and one with ARP link
monitoring performed every 200 milliseconds, the /etc/conf.modules should
resemble the following:

alias bond0 bonding
alias bond1 bonding

options bond0 miimon0
options bond1 -o bonding1 arp_interval 0 arp_ip_target.0.0.1

=========================[fin citation]=============================== (Note : l'option -o sert à charger le module sous un autre nom.)

Il y a aussi un truc qui pour moi tient de la sorcellerie, c'est la
création d'interfaces "dummy" avec un noyau 2.4. Les commandes suivantes

ifconfig dummy0
ifconfig dummy1

suffisent à créer ces interfaces alors que /etc/modules.conf ne contient
aucun alias ni option pour ces noms. Le plus fort, c'est que lsmod
rapporte :

dummy1 924 0 (autoclean) (unused)
dummy0 924 0 (autoclean) (unused)

Donc quelque chose a implicitement chargé le module dummy en lui donnant
le nom de l'interface. Et on peut encore charger le module dummy sous
son vrai nom, qui crée une interface dummy2. Ce mécanisme ne fonctionne
plus avec un noyau 2.6.

Pascal Hambourg wrote in message <enc80v$pg1$1@biggoron.nerim.net>:

Bref, il faut choisir en fonction de la situation la plus fréquente.

En l'occurrence, je dirais que l'optimal, c'est d'utiliser l'adresse MAC,
simplement parce que persistent-net-generator a déjà créé le squelette de
fichier de config adapté, ce qui veut dire qu'il n'y a quasiment rien à
faire, alors que pour toute autre méthode, il faudra chercher dans la doc
d'udev comment ça marche.

Et tant qu'on n'administre qu'une machine, ou quelques unes, et qu'on ne
change de carte réseau que tous les 32 du mois, ce n'est vraiment pas un
problème de devoir éditer la règle à chaque fois.

Donc quelque chose a implicitement chargé le module dummy en lui donnant
le nom de l'interface. Et on peut encore charger le module dummy sous
son vrai nom, qui crée une interface dummy2. Ce mécanisme ne fonctionne
plus avec un noyau 2.6.

Bleuargh. Je ne veux pas savoir comment ça marche.

Serge Sauton wrote in message <45999ea3$0$292$426a74cc@news.free.fr>:

donc, je détruis "persistent-net-generator.rules" ou le lien symbolique
z45_persistent-net-generator.rules@ ?

Juste le lien, ça suffit.

Par contre, dans /etc/udev/rules.d, il y a z25_persistent-net.rules...

Est-ce bien ce fichier que je dois modifier à mon goût ?

Oui, c'est ça. Tu as tout qui est presque écrit. Tu peux d'ailleurs choisir
autre chose que des noms en ethX, ça vaut peut-être même mieux, dans
certains cas.

en fait, lorsque je lance le réseau :
<snip>

Cf. le message de Pascal. Ce n'est pas grave.