busybox, bridge_tools, ifupdown : comportement bizarre lors de la configuration d'un bridge
2 réponses
Yann Cohen
Bonjour,
je travaille actuellement sur une carte avec un linux embarqué dont la
distribution est "pétrie" par yocto avec en tête de gondole "busybox".
Je souhaite configurer les deux interfaces IP de la cible en switch,
soit en bridge.
Une fois bridge_utils et les options qui vont bien dans le noyau
ajoutés à la distrib, j'ai réussi à monter le bridge à la main en
utilisant les commandes suivantes :
ip link set up dev eth0
ip link set up dev eth1
brctl addbr br0
brctl addif br0 eth0 eth1
ip link set up dev br0
J'ai constaté que le ifupdown "embraqué" dans busybox ne semble pas
reconnaitre les options de type "bridge_xxx" dans le
fichier /etc/network/interfaces, donc la configuration minimale d'un
bridge tel que je le fais dans une debian ne fonctionne pas :
iface br0 inet static
address 172.17.3.2
netmask 255.255.255.0
gateway 172.173.3.1
bridge_ports eth0 eth1
Pour contourner le problème, j'ai utilisé un script if-pre-up qui lance
les commandes décrites précedenement si $IFACE vaut "br0".
L'enchaînement des commandes fonctionne bien et à la fin du boot
ifconfig indique que l'interface est montée, Oh joie !
mais que de courte durée car le trafic ne passe pas d'une interface à
l'autre !
En refaisant "à la main" le parcours je me suis rendu compte que si
j'enchaîne les commandes de configuration dans un script, les
communications "ne traversent pas" le switch...
Mais si je commence la configuration en lançant les commandes une à une
avec une attente entre elles (ne serait-ce que le temps de les taper
avec deux doigts) le switch fonctionne correctement.
Partant de ce constat, j'ai joué à l'automaticien de base en ajoutant
des tempo... Ce qui donne le script suivant :
ip link set up dev eth0
sleep 3
ip link set up dev eth1
sleep 3
brctl addbr br0
sleep 3
brctl addif br0 eth0 eth1
sleep 3
ip link set up dev br0
Je pense que cette solution est un contournement mais n'est pas "la
solution", cependant je n'arrive pas à identifier ce que j'ai raté dans
la configuration.
Une autre piste, je n'ai pas réussi à identifier la liste des options
dans interfaces que reconnaît busybox, une recherche sur les sources de
motif comme "bridge_" n'a rien donné ce qui me conforte dans le fait que
ces options ne sont pas gérées. Ai-je raté un truc ?
Et comment faire pour avoir une version de ifupdown qui traite les
commandes étendues dans /etc/network/interfaces comme sous debian ?
Cordialement.
--
Yann Cohen <yann@ianco.org>
ianco
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/1439374067.17505.30.camel@ianco.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Yann Cohen a écrit :
J'ai constaté que le ifupdown "embraqué" dans busybox ne semble pas reconnaitre les options de type "bridge_xxx" dans le fichier /etc/network/interfaces, donc la configuration minimale d'un bridge tel que je le fais dans une debian ne fonctionne pas : iface br0 inet static address 172.17.3.2 netmask 255.255.255.0 gateway 172.173.3.1 bridge_ports eth0 eth1
A ma connaissance les options bridge_* ou bridge-* ne sont pas gérées directement par ifup/ifdown mais par des scripts placés dans /etc/network/if-* par le paquet bridge-utils.
Pour l'autre problème, pas d'idée.
mais que de courte durée car le trafic ne passe pas d'une interface à l'autre !
Vérifie l'état du pont dans les logs du noyau, notamment si les deux ports passent bien dans l'état "forwarding".
Yann Cohen a écrit :
J'ai constaté que le ifupdown "embraqué" dans busybox ne semble pas
reconnaitre les options de type "bridge_xxx" dans le
fichier /etc/network/interfaces, donc la configuration minimale d'un
bridge tel que je le fais dans une debian ne fonctionne pas :
iface br0 inet static
address 172.17.3.2
netmask 255.255.255.0
gateway 172.173.3.1
bridge_ports eth0 eth1
A ma connaissance les options bridge_* ou bridge-* ne sont pas gérées
directement par ifup/ifdown mais par des scripts placés dans
/etc/network/if-* par le paquet bridge-utils.
Pour l'autre problème, pas d'idée.
mais que de courte durée car le trafic ne passe pas d'une interface à
l'autre !
Vérifie l'état du pont dans les logs du noyau, notamment si les deux
ports passent bien dans l'état "forwarding".
J'ai constaté que le ifupdown "embraqué" dans busybox ne semble pas reconnaitre les options de type "bridge_xxx" dans le fichier /etc/network/interfaces, donc la configuration minimale d'un bridge tel que je le fais dans une debian ne fonctionne pas : iface br0 inet static address 172.17.3.2 netmask 255.255.255.0 gateway 172.173.3.1 bridge_ports eth0 eth1
A ma connaissance les options bridge_* ou bridge-* ne sont pas gérées directement par ifup/ifdown mais par des scripts placés dans /etc/network/if-* par le paquet bridge-utils.
Pour l'autre problème, pas d'idée.
mais que de courte durée car le trafic ne passe pas d'une interface à l'autre !
Vérifie l'état du pont dans les logs du noyau, notamment si les deux ports passent bien dans l'état "forwarding".
Yann Cohen
Le mercredi 12 août 2015 à 14:00 +0200, Pascal Hambourg a écrit :
Yann Cohen a écrit : > > J'ai constaté que le ifupdown "embraqué" dans busybox ne semble pas > reconnaitre les options de type "bridge_xxx" dans le > fichier /etc/network/interfaces, donc la configuration minimale d'un > bridge tel que je le fais dans une debian ne fonctionne pas : > iface br0 inet static > address 172.17.3.2 > netmask 255.255.255.0 > gateway 172.173.3.1 > bridge_ports eth0 eth1
A ma connaissance les options bridge_* ou bridge-* ne sont pas gérées directement par ifup/ifdown mais par des scripts placés dans /etc/network/if-* par le paquet bridge-utils.
Merci !
J'ai récupéré les scripts de debian et je les ai un peu adapté à la distrib local : modification du path des executables, ajout de sleep pour attendre le démarrage du bridge.
Avec cela j'arrive à avoir un bridge fonctionnel au boot. Mais dès que je débranche un câble plus rien ni dans un sens ni dans l'autre. les traces sur la console montrent que les ports voient bien la déconnexion et la reconnexion. mais le ping ne reprend pas ensuite...
:~# ping 172.17.3.1 PING 172.17.3.1 (172.17.3.1): 56 data bytes 64 bytes from 172.17.3.1: seq=0 ttld time=1.562 ms 64 bytes from 172.17.3.1: seq=1 ttld time=1.055 ms 64 bytes from 172.17.3.1: seq=2 ttld time=0.934 ms 64 bytes from 172.17.3.1: seq=3 ttld time=1.078 ms 64 bytes from 172.17.3.1: seq=4 ttld time=1.079 ms 64 bytes from 172.17.3.1: seq=5 ttld time=1.106 ms br0: port 2(eth1) entered disabled state PHY: imx25-fec-1:00 - Link is Down br0: port 1(eth0) entered disabled state br0: port 2(eth1) entered listening state br0: port 2(eth1) entered listening state PHY: imx25-fec-1:00 - Link is Up - 100/Full br0: port 1(eth0) entered listening state br0: port 1(eth0) entered listening state br0: port 2(eth1) entered learning state br0: port 1(eth0) entered learning state br0: topology change detected, propagating br0: port 2(eth1) entered forwarding state br0: topology change detected, propagating br0: port 1(eth0) entered forwarding state
^C
Pour l'autre problème, pas d'idée.
> mais que de courte durée car le trafic ne passe pas d'une interface à > l'autre !
Vérifie l'état du pont dans les logs du noyau, notamment si les deux ports passent bien dans l'état "forwarding".
Le mercredi 12 août 2015 à 14:00 +0200, Pascal Hambourg a écrit :
Yann Cohen a écrit :
>
> J'ai constaté que le ifupdown "embraqué" dans busybox ne semble pas
> reconnaitre les options de type "bridge_xxx" dans le
> fichier /etc/network/interfaces, donc la configuration minimale d'un
> bridge tel que je le fais dans une debian ne fonctionne pas :
> iface br0 inet static
> address 172.17.3.2
> netmask 255.255.255.0
> gateway 172.173.3.1
> bridge_ports eth0 eth1
A ma connaissance les options bridge_* ou bridge-* ne sont pas gérées
directement par ifup/ifdown mais par des scripts placés dans
/etc/network/if-* par le paquet bridge-utils.
Merci !
J'ai récupéré les scripts de debian et je les ai un peu adapté à la
distrib local :
modification du path des executables,
ajout de sleep pour attendre le démarrage du bridge.
Avec cela j'arrive à avoir un bridge fonctionnel au boot.
Mais dès que je débranche un câble plus rien ni dans un sens ni dans
l'autre.
les traces sur la console montrent que les ports voient bien la
déconnexion et la reconnexion.
mais le ping ne reprend pas ensuite...
root@sts-pilote:~# ping 172.17.3.1
PING 172.17.3.1 (172.17.3.1): 56 data bytes
64 bytes from 172.17.3.1: seq=0 ttld time=1.562 ms
64 bytes from 172.17.3.1: seq=1 ttld time=1.055 ms
64 bytes from 172.17.3.1: seq=2 ttld time=0.934 ms
64 bytes from 172.17.3.1: seq=3 ttld time=1.078 ms
64 bytes from 172.17.3.1: seq=4 ttld time=1.079 ms
64 bytes from 172.17.3.1: seq=5 ttld time=1.106 ms
br0: port 2(eth1) entered disabled state
PHY: imx25-fec-1:00 - Link is Down
br0: port 1(eth0) entered disabled state
br0: port 2(eth1) entered listening state
br0: port 2(eth1) entered listening state
PHY: imx25-fec-1:00 - Link is Up - 100/Full
br0: port 1(eth0) entered listening state
br0: port 1(eth0) entered listening state
br0: port 2(eth1) entered learning state
br0: port 1(eth0) entered learning state
br0: topology change detected, propagating
br0: port 2(eth1) entered forwarding state
br0: topology change detected, propagating
br0: port 1(eth0) entered forwarding state
^C
Pour l'autre problème, pas d'idée.
> mais que de courte durée car le trafic ne passe pas d'une interface à
> l'autre !
Vérifie l'état du pont dans les logs du noyau, notamment si les deux
ports passent bien dans l'état "forwarding".
Le mercredi 12 août 2015 à 14:00 +0200, Pascal Hambourg a écrit :
Yann Cohen a écrit : > > J'ai constaté que le ifupdown "embraqué" dans busybox ne semble pas > reconnaitre les options de type "bridge_xxx" dans le > fichier /etc/network/interfaces, donc la configuration minimale d'un > bridge tel que je le fais dans une debian ne fonctionne pas : > iface br0 inet static > address 172.17.3.2 > netmask 255.255.255.0 > gateway 172.173.3.1 > bridge_ports eth0 eth1
A ma connaissance les options bridge_* ou bridge-* ne sont pas gérées directement par ifup/ifdown mais par des scripts placés dans /etc/network/if-* par le paquet bridge-utils.
Merci !
J'ai récupéré les scripts de debian et je les ai un peu adapté à la distrib local : modification du path des executables, ajout de sleep pour attendre le démarrage du bridge.
Avec cela j'arrive à avoir un bridge fonctionnel au boot. Mais dès que je débranche un câble plus rien ni dans un sens ni dans l'autre. les traces sur la console montrent que les ports voient bien la déconnexion et la reconnexion. mais le ping ne reprend pas ensuite...
:~# ping 172.17.3.1 PING 172.17.3.1 (172.17.3.1): 56 data bytes 64 bytes from 172.17.3.1: seq=0 ttld time=1.562 ms 64 bytes from 172.17.3.1: seq=1 ttld time=1.055 ms 64 bytes from 172.17.3.1: seq=2 ttld time=0.934 ms 64 bytes from 172.17.3.1: seq=3 ttld time=1.078 ms 64 bytes from 172.17.3.1: seq=4 ttld time=1.079 ms 64 bytes from 172.17.3.1: seq=5 ttld time=1.106 ms br0: port 2(eth1) entered disabled state PHY: imx25-fec-1:00 - Link is Down br0: port 1(eth0) entered disabled state br0: port 2(eth1) entered listening state br0: port 2(eth1) entered listening state PHY: imx25-fec-1:00 - Link is Up - 100/Full br0: port 1(eth0) entered listening state br0: port 1(eth0) entered listening state br0: port 2(eth1) entered learning state br0: port 1(eth0) entered learning state br0: topology change detected, propagating br0: port 2(eth1) entered forwarding state br0: topology change detected, propagating br0: port 1(eth0) entered forwarding state
^C
Pour l'autre problème, pas d'idée.
> mais que de courte durée car le trafic ne passe pas d'une interface à > l'autre !
Vérifie l'état du pont dans les logs du noyau, notamment si les deux ports passent bien dans l'état "forwarding".
