Bonjour (et bonne année)

Je suis sous linux debian noyau 2.6
J'ai trois cartes réseau :

> lscpi | grep Ethernet
0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
0000:01:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
0000:02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated
Fast Ethernet Controller [Tornado] (rev 40)

J'en utilise deux : eth0 (la nforce2) pour mon réseau local et
eth1(Realtek) en dhcp :
> cat /etc/network/interfaces
auto eth0
iface eth0 inet static
address 172.16.0.1
netmask 255.255.255.0
network 172.16.0.0
broadcast 172.16.255.255
gateway 172.16.0.1
auto eth1
iface eth1 inet dhcp

Je souhaiterais utiliser la troisième pour un autre réseau local,
quelque chose du type :

auto eth2
iface eth2 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.255.255
gateway 192.168.0.1

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

> dmesg | grep eth

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

de plus j'ai les messages d'erreurs suivants :
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



Si j'essaie de mettre eth4 à la place de eth2 dans le fichier
interfaces, un message m'indique qu'aucune interface réseau eth4 n'existe.

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

mais ça ne change rien...eth2 semble toujours réservé au firewire.

Comment faire donc pour qu'eth2 puisse être associé à ma troisième
interface réseau ? Ou tout du moins comment pouvoir utiliser cette
troisième carte réseau ?

Merci.

--
Serge Sauton

\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,

Nicolas George a écrit :
>
>>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

Nicolas George a écrit :
> 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 miimon=100
options bond1 -o bonding1 arp_interval=200 arp_ip_target=10.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 32du 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.

Le 01-01-2007, à propos de
Re: eth0 eth1 eth2...comment est-ce attribué ?,
Nicolas George écrivait dans fr.comp.os.linux.configuration :
> 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.

Ouaips... Sauf quand chez Sun, toutes les adresses MAC de toutes les
interfaces Ethernet d'un serveur sont identiques. Sur une U80, j'ai
la hme sur la carte mère et huit hme (sur deux cartes quad), toutes
avec la même adresse MAC.

> 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.

Surtout lorsqu'on se retrouve aves des eth1_rename et autres
joyeusetés...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

> Surtout lorsqu'on se retrouve aves des eth1_rename et autres
> joyeusetés...

justement, j'ai une "joyeuseté" de ce type :

~ cat /etc/udev/rules.d/z25_persistent-net.rules
#realtek
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:08:54:06:36:23",
NAME="eth_pc-enfant"

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

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

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

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



et ceci :

~ ls /sys/class/net
eth2_rename/ eth3/ eth4/ eth_freebox/ eth_pc-enfant/ lo/ sit0/


donc "eth2_rename" à la place de "eth_libre".
Est-ce lié au problème que tu signalais Nicolas à propos du driver 3com
qui n'affiche pas la chaîne "eth" ?

Comment peut-on arranger ceci ?

Merci encore.

--
Serge Sauton

JKB a écrit :
>
> Ouaips... Sauf quand chez Sun, toutes les adresses MAC de toutes les
> interfaces Ethernet d'un serveur sont identiques. Sur une U80, j'ai
> la hme sur la carte mère et huit hme (sur deux cartes quad), toutes
> avec la même adresse MAC.

A première vue, je trouve que ce n'est pas une si mauvaise idée. Je ne
vois pas de bonne raison de relier plusieurs interfaces indépendantes et
actives simultanément d'une machine à un même réseau ethernet. Et ça
simplifie l'association d'interfaces en bonding ou en bridge : on n'a
plus besoin de se demander l'adresse MAC de quelle interface sera
adoptée pour l'ensemble. :-) (J'ai des mauvais souvenirs où le groupe
prenait l'adresse MAC de la dernière interface associée et donc
changeait à chaque nouvelle association, pas très pratique...)

In article <endiqr$18if$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

> JKB a écrit :
> >
> > Ouaips... Sauf quand chez Sun, toutes les adresses MAC de toutes les
> > interfaces Ethernet d'un serveur sont identiques. Sur une U80, j'ai
> > la hme sur la carte mère et huit hme (sur deux cartes quad), toutes
> > avec la même adresse MAC.
>
> A première vue, je trouve que ce n'est pas une si mauvaise idée. Je ne
> vois pas de bonne raison de relier plusieurs interfaces indépendantes et
> actives simultanément d'une machine à un même réseau ethernet.

c'est l'excuse officielle de SUN

patpro

--
http://www.patpro.net/

patpro ~ Patrick Proniewski a écrit :
>>
>>A première vue, je trouve que ce n'est pas une si mauvaise idée. Je ne
>>vois pas de bonne raison de relier plusieurs interfaces indépendantes et
>>actives simultanément d'une machine à un même réseau ethernet.
>
> c'est l'excuse officielle de SUN

Serait-ce une mauvaise excuse, et si oui, pourquoi ?

Serge Sauton wrote in message <459a4056$0$319$426a74cc@news.free.fr>:
> donc "eth2_rename" à la place de "eth_libre".

C'est bizarre. Tu n'as aucune autre règle udev qui parle du nommage des
interfaces réseau?

> Est-ce lié au problème que tu signalais Nicolas à propos du driver 3com
> qui n'affiche pas la chaîne "eth" ?

Non, non, ce n'est pas du tout un problème, juste une illustration du fait
que dmesg n'est pas une source fiable pour avoir une liste du matériel
détecté, surtout d'une manière facilement consultable.

In article <endjq2$18po$2@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

> patpro ~ Patrick Proniewski a écrit :
> >>
> >>A première vue, je trouve que ce n'est pas une si mauvaise idée. Je ne
> >>vois pas de bonne raison de relier plusieurs interfaces indépendantes et
> >>actives simultanément d'une machine à un même réseau ethernet.
> >
> > c'est l'excuse officielle de SUN
>
> Serait-ce une mauvaise excuse, et si oui, pourquoi ?

c'est une bonne excuse. Et puis c'est pas la mort, une adresse MAC ça
peut se modifier de manière logicielle.

patpro

--
http://www.patpro.net/

Nicolas George a écrit :
>> donc "eth2_rename" à la place de "eth_libre".
>
> C'est bizarre. Tu n'as aucune autre règle udev qui parle du nommage des
> interfaces réseau ?

~ 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@ z50_run.rules@
025_libsane.rules@ z55_hotplug.rules@
025_logitechmouse.rules@ z60_alsa-utils.rules@
035_kino.rules@
z60_xserver-xorg-input-wacom.rules@
udev.rules@ z75_cd-aliases-generator.rules@
z20_persistent-input.rules@ z99_hal.rules@
z20_persistent.rules@


j'ai fait une recherche de la chaîne "eth" dans chaun des fichiers et je
n'ai rien trouvé de plus...

~ for nom in /etc/udev/rules.d/* ; do; cat $nom | grep "eth" ;done
SUBSYSTEM=="aoe", KERNEL=="discover", NAME="etherd/%k"
SUBSYSTEM=="aoe", KERNEL=="err", NAME="etherd/%k"
SUBSYSTEM=="aoe", KERNEL=="interfaces", NAME="etherd/%k"
SUBSYSTEM=="aoe", KERNEL=="revalidate", NAME="etherd/%k"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:08:54:06:36:23",
NAME="eth_pc-enfant"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:e0:18:f7:71:0c",
NAME="eth_freebox"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:26:54:09::f8:75",
NAME="eth_libre"
SUBSYSTEM=="net", DRIVERS=="?*",
ATTRS{address}=="00:e0:18:00:00:11:32:42", NAME="eth3"
SUBSYSTEM=="net", DRIVERS=="?*",
ATTRS{address}=="00:00:00:00:00:03:11:53", NAME="eth4"


où faut-il chercher ailleurs ?

Merci.

--
Serge Sauton

Serge Sauton wrote in message <459a68ea$0$295$426a34cc@news.free.fr>:
> ATTRS{address}=="00:e0:18:00:00:11:32:42", NAME="eth3"
> SUBSYSTEM=="net", DRIVERS=="?*",
> ATTRS{address}=="00:00:00:00:00:03:11:53", NAME="eth4"

Essaie de mettre un nom complètement différent à ceux-là. D'ailleurs, les
appeler ethX est complètement grotesque de la part du noyau.

Nicolas George a écrit :
> Essaie de mettre un nom complètement différent à ceux-là. D'ailleurs, les
> appeler ethX est complètement grotesque de la part du noyau.

ben oui...

~ cat /etc/udev/rules.d/

#realtek
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:08:54:06:36:23",
NAME="eth_pc-enfant"

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

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

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

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


~ ls /sys/class/net
eth1/ eth_freebox/ eth_pc-enfant/ firewire1/ firewire2/ lo/ sit0/

c'est vraiment bizarre...non ?

Merci.

--
Serge Sauton

Serge Sauton a écrit :
>
> #3com
> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:26:54:09::f8:75",
^^
C'est normal, ça ?

patpro ~ Patrick Proniewski a écrit :
>
> une adresse MAC ça peut se modifier de manière logicielle.

Je ne sais pas si c'est vrai pour tous les adaptateurs ethernet, mais
j'ai cru comprendre que ça ne modifie pas vraiment l'adresse MAC au
niveau matériel : en fait l'interface est passée en mode promiscuous et
l'adresse MAC destination de chaque paquet reçu est filtrée par
logiciel. Donc ça entraîne une surcharge de traitement pour le système,
certes modérée dans un réseau commuté. D'autre part, il faut bien avoir
des adresses MAC dont on est sûr qu'elles ne risquent pas d'appartenir à
d'autres équipements branchés sur le même réseau ethernet.

Pascal Hambourg a écrit :
> Serge Sauton a écrit :
>>
>> #3com
>> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:26:54:09::f8:75",
> ^^
> C'est normal, ça ?

Oups ! Vraiment désolé !
Evidemment, ça va beaucoup mieux après correction.

Merci encore à tous pour votre aide précieuse.

--
Serge Sauton

In article <endtga$1clh$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

> patpro ~ Patrick Proniewski a écrit :
> >
> > une adresse MAC ça peut se modifier de manière logicielle.
>
> Je ne sais pas si c'est vrai pour tous les adaptateurs ethernet, mais
> j'ai cru comprendre que ça ne modifie pas vraiment l'adresse MAC au
> niveau matériel :

non, bien sûr, sauf cas très particuliers.

> en fait l'interface est passée en mode promiscuous et
> l'adresse MAC destination de chaque paquet reçu est filtrée par
> logiciel. Donc ça entraîne une surcharge de traitement pour le système,
> certes modérée dans un réseau commuté.

alors ça, ça m'étonne, si t'as de la doc là dessus, je suis preneur.

patpro

--
http://www.patpro.net/