Pastilles de contact electrique

 Trucs et astuces techniques  Commentaires fermés sur Pastilles de contact electrique
Avr 222013
 

L’ouverture en charge de contacts électriques est généralement accompagnée d’arcs électriques donnant naissance à des contraintes importantes au niveau des dits contacts. Des solutions consistent à ajouter au niveau de la surface ou zone de contact des matériaux composites sous la forme de pastilles de différentes épaisseurs et de différents matériaux.

Les pastilles de contact sont destinées à supporter des courants crêtes entre 200 et 600 ampères par millimètre carré de pastille.
Ces matériaux subissent en service des sollicitations extrêmes, avec des vitesses de montée en température pouvant être en surface de l’ordre de 1000°C par milliseconde, des densités de puissance supérieures à 10kW/mm2 ainsi que des températures transitoires généralement supérieures à 2500 K. Ils sont le siège de phénomènes mécaniques, hydrodynamiques, électromagnétiques violents et complexes. Ils doivent de plus être en mesure de supporter plusieurs millions de cycles sans pour autant se souder dans les conditions de forts courants.

La pastille est constituée d’un alliage de matériau conducteur à base d’argent et de cuivre, d’une fraction de particules réfractaires telles que du carbure de tungstène, du tungstène ou du nitrure de titane et d’une fraction de fibres de carbone.

Elles sont réalisées de manière usuelle par frittage d’une poudre composée d’un alliage à base d’argent de cuivre de tungstène et de nickel. Ces matériaux de contact présentent une conductibilité électrique élevée, une résistance suffisante à l’oxydation et de bonnes propriétés en ce qui concerne la résistance de contact. Cependant, ces alliages métalliques montrent une tendance indésirable à la soudure et ils ont tendance à provoquer l’adhérence des surfaces ou/et une migration de matière entre les éléments de contact.

De nombreuses solutions consistent à ajouter à la poudre d’alliage un matériau conducteur tel que du graphite. De tels matériaux sont couramment utilisés pour réaliser les pastilles de contact des disjoncteurs. Le graphite présent dans la matrice métallique permet de réduire le risque de soudure des contacts. Toutefois, la présence du graphite entraîne une érosion mécanique accrue de la pastille. Du carbone, sous forme de fibres peut être aussi apporté à la poudre d’alliage, mais l’amélioration de la résistance à l’érosion est acquise au prix d’une altération du comportement du contact à la soudure. Un compromis acceptable est de mélanger des particules de graphite à des fibres de carbone, avant incorporer ce mélange à la poudre métallique.

(Informations extraites du brevet EP1655749 B1)

En conclusion, les pastilles de contact qu’il y a dans les relais, interrupteurs et disjoncteurs sont d’une nature tout a fait spéciale et étudiée. On ne peut pas « bricoler » un équivalent pour réparer un contact altéré ou usé.

Un document vraiment très intéressant :
http://tel.archives-ouvertes.fr/docs/00/15/28/73/PDF/Bonhomme.pdf
(ou une copie si le lien précédent est mort)

Avr 022013
 

Voici un schéma ultra-simple pour réaliser un oscillateur avec 2 transistors.

osc_transistors_001

T1=T2=BC337 ou BC547 ou autre transistor NPN ordinaire comme le 2N2222
R1 et R4 et doivent être petits devant R2 et R3 mais suffisamment grands pour ne pas bruler les jonctions des transistors.
R2 et R3 doivent au moins être double de R1 et R4 pour ne pas écraser l’effet de commutation de capacités.

La fréquence du circuit est donné par la combinaison de deux temporisations : 1 pour chaque état

Tempo1 = R2 * C1 * ln(2)
Tempo2 = R3 * C2 * ln(2)
F = 1 / (Tempo1+Tempo2) = 1/( ln(2) * ( R2*C1 + R3*C2 ) )

Principe de Fonctionnement :

Prenons comme hypothèse qu’a un certain moment, C1 est déchargé (Uab=0) et que C2 est chargé à de façon a ce que Udc=+Vcc.
(Nous verrons dans un second temps comment on en arrive à cet état.)

Dans cet état, T2 est saturé par le courant traversant R1 et chargeant C1.
Cela fait que le point D est à sensiblement 0V (T2 est passant) et donc que le point C est donc a environ -Vcc via C2.
Il s’ensuit que T1 est bloqué (tension de base négative).
C2 se décharge progressivement via R3.

Le courant traversant R1 charge rapidement C1 en alimentant T2 jusqu’a ce que Uab atteigne Vcc. A ce moment là, le courant diminue et T2 tends à se bloquer.
Pendant ce temps, C2 se décharge (plus lentement) via R3
Quand la tension Udc s’annule, C1 a déjà atteint Vcc depuis quelques temps. Un courant commence à apparaitre sur la base de T1.
T1 devient passant ce qui entraine la baisse du potentiel A à une valeur proche de 0V et par là même celui de B à une valeur négative proche de -Vcc.
Cela finit immédiatement de bloquer T2.

Nous somme là dans l’état inverse de l’état initial.
Selon un raisonnement symétrique, C2 se recharge rapidement via R4 tandis que C1 se décharge plus lentement via R2.
Quand la tension Uab s’annule, C2 a déjà atteint Vcc depuis quelques temps. Un courant commence à apparaitre sur la base de T2.
T2 devient passant ce qui entraine la baisse du potentiel D à une valeur proche de 0V et par là même celui de C à une valeur négative proche de -Vcc qui bloque immédiatement T1.

Nous sommes revenu à l’état initial.
La boucle peut recommencer.

Maintenant comment en arrive-ton à cet état initial ?
La réponse est simple : à la mise sous tension les deux condensateurs sont déchargés et il existe un courant de charge via R1 et R4 qui rend passant les 2 transistors, lesquels devraient normalement abaisser les potentiels A et D ce qui forme une réaction négative. Cependant, dans ce circuit symétrique, il y aura toujours un déséquilibre entre les deux branches (capacité des condensateurs jamais identique et surtout écart de gain des transistors qui est naturellement assez important. Un des deux transistors va donc davantage bloquer l’autre et le cycle s’amorce.
Note : Il existe certainement des valeurs de de C et R pour lesquelles le circuit reste en équilibre stable, en particulier pour les fréquences élevées.

Générateur de tonalité

En général on veut un rapport cyclique de 1/2 ce qui fait qu’on prends C1 = C2 et R2 =R3

On a donc F = 1 / (2*Tempo) = 1/( 2 * ln(2) * R2*C1 )

Pour augmenter la fréquence on a donc le choix entre diminuer R2 ou C1 ou les deux.
Cependant R2 doit rester nettement supérieure à R1 laquelle ne doit pas être trop faible pour éviter de bruler les transistors.
Pour les basses fréquences, éviter de monter R2 trop au delà de 100k ohm car les fuites des condensateurs ne seraient plus négligeables.
C1 va de plusieurs milliers de microfarads à quelques nanofarads mais si on veut une fréquence assez stable, il vaut mieux éviter de descendre en dessous de 10nF.
Le montage est facilement perturbé par (ses propres) rayonnements électromagnétiques. On aura intérêt à minimiser au maximum les longueurs de fils entre les composants.

Nov 172012
 

Ce matin, mon écran Samsung 2233RZ s’est éteint.
J’ai abord cru a un problème de carte graphique, puis à un problème de câble mais en éclairant l’écran avec une lampe puissante, l’image apparaissait sur la dalle.
Le rétroéclairage ne fonctionnait plus que faiblement et seulement pendant environ 1 seconde et après l’allumage (mise en sécurité).

Après démontage de l’écran, (difficile à cause de saloperies de clips en plastiques dont la plupart se sont cassés (bravo samsung, les vis sont trop chères ? ou est-ce une intention délibérée de rendre le truc non-réparrable ?) Je constate que l’écran est en 3 parties: La dalle, une carte ‘logique’ et une carte d’alim qui comprends l’inverter du rétroéclairage.

Première inspection : Le PCB est un peu marron par endroits, ce qui prouve que même si ça n’est pas forcément la cause de mon problème, la machine est mal conçue et il y a des point trop chauds.
Étonnement, les condensateurs (marqués max 120°C) sont en parfait état (apparent) alors que la bakélite brunit à des températures plus élevées. Par précaution, je les change. mais le problème n’est pas résolu. La secondes pièce suspecte est la puce de mosfets au dos de la carte. Cependant, je remarque qu’une seule des deux lampes à cathode froide fonctionne alors que le transformateur n’a qu’un seul enroulement primaire et 2 secondaires.
J’ai inversé le branchement des deux lampes, visiblement, ce n’est pas un défaut de la lampe.

J’ai donc supposé un composant claqué (problème d’isolement) dans les sécurités et la boucle de feedback.
J’ai donc déconnecté les composants reliant la HT à la boucle de feedback (varistors 3kV et 6kV). Sans aucune amélioration.

Faute de meilleure piste j’ai donc fini par dessouder le transformateur.
Sur les premiers tests, il semblait marcher : pas de fil coupé : 0.3 Ohm pour le primaire et environ 1 kOhm pour les enroulement secondaires.

Je l’ai donc testé en mettant de petites lampes au néon sur les secondaire et en envoyant quelques pulses au primaire. Les deux lampes marchaient. Ne comprenant pas, j’ai ressorti une vieille cold-cathode que j’avais récupérée dans un vieil écran et la surprise. L’enroulement suspect ne produit qu’une très légère luminescence à l’extrémité alors que l’autre enroulement fait flasher tout le tube. C’est donc bien le transformateur HT qui a un enroulement de mort. J’imagine qu’il y a un défaut d’isolement dans le transfo qui réduit sa tension de sortie à quelques centaines de volts plutôt que quelques milliers. C’est quand même étrange que cet enroulement ne soit pas franchement coupé ou en court-circuit (résistance ohmique similaire à l’autre) mais révèle un défaut à l’usage.
Je ne saisis pas non plus comment une pièce pareille peut lâcher après 2 années de fonctionnement mais apparemment il y en a pas mal en vente sur ebay, donc ça doit arriver relativement souvent.

La pièce est commandée. (fournisseur chinois)
3 semaines plus tard, pièce reçu.
10 minutes plus tard, ça fonctionne.

Le boiter plastique a été un peu dur à refermer. je m’en suis sorti avec un peu de colle car une partie de clips en plastique avaient été cassé au moment de l’ouverture.
Cet écran est reparti pour quelques temps.

Recallage d’horloge pour VM Xen

 Trucs et astuces techniques  Commentaires fermés sur Recallage d’horloge pour VM Xen
Oct 182012
 

Pour ceux qui font de la virtualisation avec Xen, il existe un bug assez pénible qui fait « shifter » le timestamp d’environ 3000000000 de nanoscondes (soit environ 50minutes) de temps en temps.
Ca semble dépendent d’un hardware (uniquement sur des machines ayant plusieurs CPU physiques avec des TSC indépendants avec des VM utilisant plus de VCPU qu’il n’y a de coeurs en tout et sous forte charge pour que le temps « stolen » accumulé de chaque VM soit non-négligeable. Je ne constate ce défaut qu’environ 1 fois tous les 15 jours. J’imagine que la chose est due à un débordement quelque part dans la façon dont l’hyperviseur gère la clocksource mais je n’ai pas trouvé de solution sur le net et je n’ai pas les compétences requises pour isoler et résoudre ce problème moi-même.

Voici donc un petit bout de code source pour faire un petit démon qui évite tout changement brutal du timestamps. Ca n’est pas une vraie solution car lorsque le problème se produit, l’heure système est effectivement fausse pendant une ou deux milisecondes. Mais vu la rareté des « shifts » et la brièveté du défaut, dans les faits cette erreur est très généralement sans aucune conséquences.

#include <stdio.h>
#include <sys/time.h>
#include <unistd.h>
#include <errno.h>
#include <stdlib.h>

const int delay_us = 1000;
const double threshold = 1.0;
const bool debug = true;
FILE* debugstream = stderr;

void fprint_timestamp(FILE* stream, struct timeval * tv)
{   fprintf(stream, "%010d.%06d", (signed int)(tv->tv_sec) , (signed int)(tv->tv_usec) );
}

double tv2dbl(struct timeval * tv)
{   double sec=0;
    sec=tv->tv_usec;
    sec/=1000000;
    sec+=tv->tv_sec;
    return sec;
}

double tvDiff(struct timeval * a , struct timeval * b )
{   return tv2dbl(a) - tv2dbl(b);
}

void debug_shift(FILE* stream, struct timeval * curtime, struct timeval *oldtime )
{   fprintf(stream, "Le timestamp a augmenté de %lf ", tvDiff(curtime, oldtime) );
    fprintf(stream, "secondes depuis la derniere verification.\n" );
}

void settime(struct timeval * t)
{   if ( settimeofday(t, NULL) == -1 )
    {   fprintf(stderr, "Erreur : Impossible de régler l'heure. (êtes vous root?)\n");
        exit(1);
    }
}

void timehasshifted(struct timeval * curtime, struct timeval *oldtime )
{    
    if ( tvDiff(curtime, oldtime) <= threshold && tvDiff(curtime, oldtime) >= -threshold )
    {   if (debug) debug_shift(debugstream, curtime, oldtime);
        return;
    }
    debug_shift(stdout, curtime, oldtime);
    fprintf(stdout, "Remise du timestamp ");
    fprint_timestamp(stdout, curtime);
    fprintf(stdout, " à l'ancienne valeur de ");
    fprint_timestamp(stdout, oldtime);
    fprintf(stdout, "\n");
    settime(oldtime);
    *curtime=*oldtime;
    fprintf(stdout, "Timestamp remis à ");
    fprint_timestamp(stdout, oldtime);
    fprintf(stdout, "\n");
}

int main(void)
{
    struct timeval oldtime;
    struct timeval curtime;
    gettimeofday(&oldtime, NULL);
    while (true)
    {   
        usleep(delay_us);
        gettimeofday(&curtime, NULL);
        timehasshifted(&curtime, &oldtime);
        oldtime = curtime;
    }
}

Gestion de l’horloge Linux

 Trucs et astuces techniques  Commentaires fermés sur Gestion de l’horloge Linux
Sep 272012
 

Il y a deux horloges principales dans un système Linux :

L’horloge machine : Il s’agit de l’horloge utilisant un quartz dédié (généralement identique à ceux d’une montre bracelet) Cette horloge fonctionne d’une manière indépendante des programmes et même lorsque la machine est éteinte. elle a une précision de l’ordre de la seconde.
A divers endroits cette horloge est communément appelée l’horloge machine (« hardware clock »), l’heure temps réelle (« real time clock »), le RTC, l’horloge BIOS ou l’horloge CMOS.

L’horloge système : C’est l’horloge gérée par le noyau Linux et contrôlée par un timer. (Attention, Linux peut utiliser plusieurs clocksource différentes selon la configuration)
L’heure système est le nombre de secondes écoulées depuis Epoch (le 1er janvier 1970 00:00:00 UTC)
L’heure système est initialisée avec la valeur de l’horloge machine au démarrage de Linux, l’horloge machine n’est ensuite plus utilisée.
Le timestamp unix a la structure suivante :
struct timeval {
time_t tv_sec; /* secondes */
suseconds_t tv_usec; /* microsecondes */
};

On peut remarquer que le timestamp est toujours UTC. C’est seulement au moment de l’affichage que l’on calcule la date et l’heure locale en tenant compte de la timezone (fuseau horaire plus ajustement heure d’été/d’hiver). Attention la timezone est une variable d’environnement et un ensemble de règles du paquet tzdata. Il existe une structure timezone historique qui est obsolète

struct timezone {
int tz_minuteswest; /* minutes à l'ouest de Greenwich */
int tz_dsttime; /* type de changement horaire */
};

l’argument tz doit en général être NULL. Le champ tz_dsttime n’a jamais été utilisé sous Linux, il n’a jamais été géré, et ne le sera jamais par la libc ou glibc.

la fonction gettimeofday() retourne le timestamp.

Historiquement le timestamp est 32bits () mais sur debian squeeze 64 bits
sizeof time_t = 8
sizeof suseconds_t = 8

Ce sont donc « déjà » des entiers 64 bits signés.

Pour corriger la dérive de l’horloge, il existe une fonction adjtime() qui ajuste graduellement l’horloge système en l’accélérant ou la ralentissant à un rythme constant de 0.5ms/s.
int adjtime(const struct timeval *delta, struct timeval *olddelta);
si delta est NULL olddelta est peuplé avec le temps à ajuster restant.

La commande ntpdate utilise adjtime() si l’écart entre l’horloge locale et l’horloge de référence est inférieur à +-128 ms. Cela permet de recaler l’horloge tout en gardant un timestamp monotone. (qui ne reviens jamais en arrière et sans saut dans le futur) Au delà, comme il faudrait plus de 5 minutes pour recaler l’horloge , celle ci est réglée de façon abrupte.
Tout nouvel appel à adjtime avec un décalage non NULL conserve le décalage déjà effectué mais fait perdre le décalage restant à faire.
L’utilisation de ntpdate pendant la période d’ajustement induit de légères erreurs de mesure du delta à cause du fait que l’horloge est déjà en cours d’accélération ou de ralentissement. Il vaut donc mieux attendre que adjtime ait fini avant de faire à nouveau appel à ntpdate.

Enfin il exite une fonction permettant de modifier de façon permanente la derive de l’horloge soft.
by adjusting the rate at which the system time is advanced with each timer interrupt, using adjtimex(8).

Comment virer APIPA

 Trucs et astuces techniques  Commentaires fermés sur Comment virer APIPA
Août 312012
 

Parmi les trucs automatiques crétin-friendly de l’informatique, il y a un truc qui m’insupporte, ce sont les adresses IP automatiques APIPA décrites ici http://tools.ietf.org/html/rfc3927 .

Les systèmes d’exploitation n’ont que 2 modes : Automatique et manuel.
Alors que de mon point de vue il y a 2 mode automatique :
Le mode « neu-neu » sans rien du tout et le mode « normal » avec un DHCP.

Autant je peux comprendre l’existence d’un mode autonome pour les lan à 3 machines maxi, Autant je trouve que c’est une une vraie plaie pour les réseaux « normaux » parce que

  • Ca ne sert à rien dans un réseau qui se rattache à internet, c’est à dire un bon 90% à mon avis.
  • Ca fait croire que ça marche alors que ça ne marche pas. Si par exemple le DHCP est injoignable, ça remplace une adresse qui marche par une adresse pourrie plutôt que de dire qu’il y a un problème de configuration réseau.
  • C’est persistant. Quand on a pris une adresse pourrie, on essaye surtout pas de voir si le DHCP est revenu, on garde l’adresse merdeuse.

Voici donc comment désactiver APIPA sous windows

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{000000ID-00DE-VOTRE-0000-000CARTE0RZO}
IPAutoconfigurationEnabled = 0

Voyage Linux

 Trucs et astuces techniques  Commentaires fermés sur Voyage Linux
Sep 032011
 

La microdistribution « Voyage Linux » est géniale pour utiliser avec des cartes Alix. (Voir chez le fabricant http://pcengines.ch/alix.htm )
Cependant le site officiel http://linux.voyage.hk/
et régulièrement down (ou rame comme c’est pas permis).

Je garde une copie de la dernière mouture disponible ici : http://files.www.pcdwarf.net/voyage-0.7.5.tar.bz2
(Oui je duplique du contenu. Et oui, je ne suis pas un miroir officiel. Et alors ? D’ailleurs, Contactez pour pour le mot de passe si vous voulez la prendre ici.)

Maintenant, voici les petites info indispensable pour avoir un système de base utilisable sans arrachage de cheveux.
1°) ce qui devrait être la première ligne du support du site officiel : après extraction, le script d’install est siitué dans
voyage-0.7.5/usr/local/sbin/voyage.update

2°) la liste des trucs sympa à faire en fin d’install.
– booter sue la carte alix reliée en réseau filaire via eth0 et la CF nouvellement installée

– Se logger en root (password voyage)


remountrw
sed -i 's/hk/fr/' /etc/apt/sources.list
apt-get update
apt-get remove --purge vim-tiny --assume-yes --force-yes
apt-get install vim --assume-yes --force-yes
sed -i 's/^# alias/alias/ ; s/^# export/export/ ; s/^# eval/eval/' /root/.bashrc
sed -i 's/^.*syntax on/syntax on/' /etc/vim/vimrc
apt-get install htop gcc g++ make binutils htop tree iftop pipebench dialog whiptail mutt nmap --assume-yes --force-yes
apt-get install freebsd-manpages manpages-fr manpages-fr-dev aespipe cowsay rsync locales --assume-yes --force-yes
remountro
remountrw

Et tout ce que vous trouverez indispensable.

Le besoin de hasard en cryptographie

 Trucs et astuces techniques  Commentaires fermés sur Le besoin de hasard en cryptographie
Août 182011
 

Les ordinateurs sont totalement déterministes.
En dépit du fonctionnement souvent incohérent des programmes informatiques mal conçus, le matériel informatique est souvent cohérent et fiable.
La cryptographie nécessite pour être efficace de disposer de nombres à peu près aléatoires mais surtout très difficilement prévisibles, ce qui est loin d’être évident sur un système déterministe.
Les programmeurs ont conçu de nombreuses méthodes pour que les ordinateurs génèrent des nombres apparemment aléatoires.
Ces algorithmes sont regroupés sous le nom générique de générateurs de nombres pseudo-aléatoires (PRNG).
Les générateurs de nombres pseudo-aléatoires suffisent pour des applications simples, comme la création d’événements « aléatoires » dans des jeux vidéo. Le générateur de congruence linéaire (GCL), est un exemple classique de ce type d’algorithme.
Pourtant, rien n’est vraiment imprévisible dans les calculs effectués, et là réside le problème : un attaquant peut facilement utiliser sa propre copie du générateur pour
connaître tous les résultats que notre PRNG créera.
Même si notre PRNG part d’un état initial inconnu de l’attaquant, il est souvent possible de déduire des propriétés importantes de cette valeur initiale en observant les sorties produites puis d’utiliser ces informations pour régler son propre PRNG. Une méthode générale pour reconstruire et prédire tous les polynômes des générateurs de congruence a été établie dans les années 1990. Ce problème crée un trou béant dans la sécurité des algorithmes de cryptage.

La seule méthode qu’un ordinateur peut employer pour produire des données quasiment imprévisibles consiste à rassembler autant d’informations non prévisibles que possible à partir de ‘environnement physique et de les utiliser comme valeurs à transférer à tous les programmes qui nécessitent une bonne part de hasard. C’est pourquoi on récupère des événements vraisemblablement peu prévisibles comme les I/O clavier/souris, réseau et disques.

Le problème est que dans des conditions particulières, ces événements vraisemblablement peu prévisibles le sont en fait assez (prévisibles).

De nos jours, un certain nombre de plates-formes matérielles implémentent des générateurs de nombres aléatoires physiques, appelés vrais générateurs de nombres aléatoires (TRNG, de l’anglais True Random Number Generators). Ils font appel à certaines caractéristiques physiques d’un composant qui changent en raison d’un bruit thermique comme par exemple le courant dans un résistor. Cette solution simple à base de semi-conducteur est assez fiable.
Une des techniques les plus sure mais des plus tordues à mettre en œuvre est la mesure de la décroissance radioactive d’un isotope instable. Ces périphériques offrent un moyen plus fiable de générer des données vraiment imprévisibles par rapport à la collecte d’informations dont on ne fait simplement qu’espérer qu’elles soient difficiles à prédire.

Routage et bridging pour HVM Xen sur Dedibox.

 Trucs et astuces techniques  Commentaires fermés sur Routage et bridging pour HVM Xen sur Dedibox.
Mai 222011
 

SVP lisez le post Routage et bridging pour PVM Xen sur Dedibox. avant de lire celui-ci.

ATTENTION !
lisez tout avant de manipuler, il y a moyen de perdre la main sur la machine hôte assez facilement.

Les HVM diffèrent un peu des machines PVM. En particulier dans la déclaration du bridging.
Pour faire le bridging, les PVM utilisent une interface vif qui est bridgée sur peth0.
Dans le cas des HVM, une interface vif est bien crée mais elle me semble inutilisée. Une autre interface tap est également crée et est elle aussi bridgée sur peth0
cependant à la diférence des vif qui sont créées avec une mac fe:ff:ff:ff:ff:ff les interfaces tap sont créées avec des mac randomisées.
Cela serait sans la moindre importance si le noyau Linux n’avait l’idée stupide d’affecter à un bridge la mac la plus basse de toutes les interfaces connectées au bridge en question.
Donc, si la mac randomisée pour votre tap est plus petite que celle de votre eth0 (la mac de mon eth0 commence par BC pas de chance) vous perdrez la main sur votre machine hôte (en plus, vous diffusez un mac illégale, alors soyez heureux si online.net ne vous blackliste pas pour tentative de spoofing. )

La solution : Modifier le script de création de l’interface virtuelle pour mettre la mac de la tap à fe:ff:ff:ff:ff:ff ( fe au début pour éviter le ff partout qui est l’adresse de broadcast. Personnellement, j’aurais plutôt mis le fe à la fin mais comme j’ai vu partout comme ça, je suppose qu’il y a une bonne raison…. ou pas…. enfin, bon ça marche comme ça tant qu’il n’existe pas de cartes réseau dont la mac commence en ff, y’a de la marge…)
Pour cela, éditez le script /etc/xen/scripts/qemu-ifup et modifier le comme suit

#!/bin/sh

echo -c 'config qemu network with xen bridge for '
echo $*

#patch pcdwarf 
echo "La configuration actuelle de $1 est "
ip link show $1
echo "Passage de la mac de $1 a fe:ff:ff:ff:ff:ff"
ip link set $1 addr fe:ff:ff:ff:ff:ff
echo "La configuration actuelle de $1 est maintenant"
ip link show $1

echo "activation de $1"
ifconfig $1 0.0.0.0 up

echo "Ajout de $1 au bridge $2"
brctl addif $2 $1

#elements facultatifs pour faire du routage
#echo "Activation du proxy ARP pour $1" 
#echo 1 >/proc/sys/net/ipv4/conf/$1/proxy_arp


Les éléments facultatifs pour le routage serviront a faciliter le routage des machines windows mais ne doivent pas être activés sans en comprendre toutes les implications.

La suite un peu plus tard…. 🙂