Forum Astuces.divers Rapport d'intervention chez Monsieur Tartampion

Posté par  . Licence CC By‑SA.
Étiquettes :
1
24
nov.
2015

Sommaire

Bonjour je suis technicien et je fais du dépannage sur du Desktop Ubuntu.

00:00:00:00:00:00

Un client m'a montré son Laptop. La ROM qui contient l'adresse MAC (l'adresse constructeur de la carte réseau) semble effacée ce qui rend le réseau non fonctionnel (adresse MAC = 00:00:00:00:00:00)

Bios

Règle d'or : on ne flashe pas le bios on flash les firmwares, au pire. Parce que ça prend du temps parce que c'est dangereux pour le matériel : on peut le briquer et puis parce que c'est peu/mal documenté.

Et puis dans le cas d'une adresse Mac c'est sensé se gérer en Software et là on se rapproche un peu trop du Hard !

Gnome3 - network-manager

Un coup d’œil rapide dans le gestionnaire de réseau m'indique un bug dans la gestion des profils et la présence d'une option de configuration de l'adresse mac me donne du courage. Mais pourtant je ne parviens pas à attribuer une adresse mac fonctionnelle.

Kernel - etherdevice.h

http://lxr.free-electrons.com/source/include/linux/etherdevice.h

static inline void eth_zero_addr(u8 *addr)
{
         eth_random_addr(u8 addr)
         memset(addr, 0x00, ETH_ALEN);
}

Au delà de toutes les techniques de résolution traditionnelles : bas -> haut ; haut <- bas l'idée que le Kernel ne pourrait pas accepter d'assigner une adresse MAC nulle me semble intéressante.

J'ai essayé d'attribuer l'adresse manuellement en commençant par recompiler un noyau avec un patch qui fait un random si on demande une adresse nulle. Ce choix me semblait meilleur et un bon compromis à mi-chemin entre la carte réseau supplémentaire et un script au démarrage.

Mais ça n'a pas fonctionné en effet il semble que les logiciels de configuration des pilotes ne fassent pas appel aux directives du noyau. ?! Je ne vois pas comment cela est possible mais je n'ai sans doute pas assez cherché.

SystemD

J'ai arrêté mon introspection quand je suis allé fouiller dans les sources de ifconfig et les scripts de démarrage parce que j'avais mal à la tête. Et je n'ai pas été voir du coté de systemd. Peut-être du coté de systemd.netdev et de l'espace utilisateur du kernel ?

Init

N'étant pas de taille à affronter Systemd pour le moment j'ai donc pour le moment résolu le problème avec un bête script de démarrage /etc/rc.local

Hibernate - SystemD

La mise en veille prolongée de la machine fait resurgir le problème réseau. J'ai vu a priori deux scripts qui pourraient gérer SystemD. suspend et resume https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks qui seraient donc des services à part entière mais j'ignore pour l'instant leurs interdépendances afin de les appeler donc j'ose pas trop y toucher en plus la documentation est en anglais.

S'il suffisait de faire un service (script) resume autonome ça serait vraiment trop simple.

Tout-ca-pour-dire-que-:

J'ai fait un raccourci dans le menu de gnome shell (/usr/share/Application/INTERNET.desktop dont je vous épargne les 10lignes de construction) qui pointe vers gksu /etc/rc.local

qui fait l'affaire par : 

#!/bin/sh -e
# on relance le pilote réseau Realtek
rmmod r8169
modprobe r8169
# on vite la table de routage
ip route flush table main
# on redémarre l'interface réseau avec
# une nouvelle adresse mac que l'on choisi
ifconfig eth0 down
ifconfig eth0 xxx.xxx.xxx.xxx hw ether xx:xx:xx:xx:xx:xx up
# on ajoute une passerelle pour aller
# sur internet
ip route add default via x.x.x.x
#nettoyage de configuration du resolver dns
rm /etc/resolv.conf && touch /etc/resolv.conf && echo "127.0.0.1" >> /etc/resolv.conf && echo "ip de la box" >> /etc/resolv.conf
exit 0

Mais je me demande si c'est légal et si ça ne risque pas de générer des collisions d'adresse en générant un conflit.

Sinon à quoi sert l'adresse MAC?

C'est peut-être pour sa qu'on m'a coupé le téléphone avant l'hiver (xxx mobile).

Existe il un annuaire d'adresse MAC chez certains constructeurs dans lequel je pourrai retrouver mon interface ?

En fait l'idée que je voulais formuler c'est que peut-être je ne suis pas seul au monde confronté à ce problème. Alors j'essaye d'en parler.

Hypothèse :

Admettons que nous soyons nombreux à avoir une Rom défaillante.

Que cela soit du à la lecture systématique de la ROM qui contient l'adresse mac qui par ce biais et l'utilisation de matériaux inadéquat serait devenu non-lisibles (RAZ) cela pourrait être une fatalité alors on serait face à un phénomène lié ainsi à l'obsolescence programmée des carte réseaux qui provoquerait une surcharge du réseau à cause de multiples conflit des adresses mac nulles pas nulles.

Alors il serait envisageable que le fournisseur soit face à une surcharge d'activité et se retrouve dans l'obligation de contrer le packet loss ainsi généré en éjectant purement et simplement les client victimes en fin de compte d'eux même puisque légalement responsables de leur infrastructure réseau.

Alors peut-être en sommes nous là et comme je n'en avais jamais entendu parlé je me suis dis que peut-être étions nous nombreux dans ce cas et que je pouvais peut-être poster cette hypothèse qui expliquerait pourquoi on a coupé la ligne avant l'hiver car je n'oserai pas envisager une raison pécuniaire je trouverai cela d'une immondice, remarque ils ont bien coupé l’électricité à mon voisin l'hiver dernier mais cela c'est une autre histoire.

  • # Hein ?

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    J'ai pas tout compris. J'ai l'impression que tu as cherché méga compliqué pour juste spoofer une adresse mac.
    C'est bizarre qu'elle soit à 00,t'as pas lancé un live usb pour voir ?
    Il y a des plages attribués par constructeur mais je doute d'un annuaire plus précis.
    Pour finir, c'est possible, juste par hasard d'avoir deux adresses mac identique sur un même réseau, juste peu probable et y a pas de quoi crier au complot.

    • [^] # Re: Hein ?

      Posté par  . Évalué à -3.

      C'est pas si compliqué en fait quand on peu y regarder de plus près. Effectivement c'est bien de "spoofer" une adresse mac qu'il s'agit mais je ne savais pas que cela s'appelait comme ca merci de me l'apprendre.

      J'ai pu préciser mes recherches et j'ai trouvé des trucs en plus sur systemD et le "spoof" je vais essaayé demain, et je reesayerai le live mais si je me souviens bien ca n'avait pas marché.

      • [^] # Re: Hein ?

        Posté par  . Évalué à 2.

        courage mon ptit non, tu l'auras ce saluad.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2. Dernière modification le 24 novembre 2015 à 08:08.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Hein ?

        Posté par  (site web personnel) . Évalué à 3.

        Il n'y a qu'a comparer les adresses MAC de deux ou n tablettes zt180e pour se convaincre qu'en certains pays on 'est pas trop regardant sur la duplicité des adresses MAC

        • [^] # Re: Hein ?

          Posté par  . Évalué à 2.

          Dell ayant également eu ce genre de problème, le pays en question c'est la Chine ou les USA ? :-)

      • [^] # Re: Hein ?

        Posté par  . Évalué à -4.

        Pour le matériel je n'ai pas de pièces de rechanges si le matériel est abimé physiquement…

        Et oui c'est peut-être lourd d'aller taper dans tous les scripts immaginables alors que le bios pourrait arranger ca.

        Mais… Flasher un bios c'est délicat. J'ai vraiment envit de le faire mais ca fait flipper les gens autour de moi quand j'en parle…

        Surtout si c'est pour passer sur une version dont je ne sais rien de l'issu du flash et du risque que la machine rende l'ame à cause d'un mauvais flash.

        Vraiment un simple patch Kernel Linux je trouvais ca vraiment propre, en plus c'était l'occasion de tester la nouvelle version qui va bientot sortir ! mais non fail c'est dommage.

        • [^] # Re: Hein ?

          Posté par  . Évalué à 2.

          Surtout si c'est pour passer sur une version dont je ne sais rien de l'issu du flash et du risque que la machine rende l'ame à cause d'un mauvais flash.

          en meme temps flasher le bios, avec le fichier du constructeur et le logiciel du construteur, y a quand meme peu de risque.
          souvent meme, sur les machines un peu recente tu flash le bios à partir de lui meme, donc impossible de te tromper

    • [^] # Re: Hein ?

      Posté par  . Évalué à 1.

      Un truc tout bête mais souvent les adresse mac sont écrites sur une étiquette du laptop… Pas toujours, mais ça vaut le coup de bien regarder.

  • # plus simple

    Posté par  . Évalué à 4.

    flasher le bios aurait été plus simple, et plus perenne (resistance aux mises à jour, au changement d'OS)

    sinon dans ton cas, ton script attribue d'office l'adresse IP en plus de l'adresse MAC, c'est bien mais ca limite l'usage toujours à la meme place (à la maison de l'utilisateur.

    ne pourrait-il pas etre simplifié pour juste se contenter de relancer la carte reseau et lui attribuer l'adresse MAC, eet laisser au gestionnaire de reseau le choix d'utiliser le dhcp, une config fixe, etc

    #!/bin/sh -e
# on relance le pilote réseau Realtek
rmmod r8169
modprobe r8169
# on vite la table de routage
ip route flush table main
# on redémarre l'interface réseau avec
# une nouvelle adresse mac que l'on choisi
ifconfig eth0 down
ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx up
exit 0

    • [^] # Re: plus simple

      Posté par  . Évalué à -4.

      abaoui. -_-
      Bon quand j'ai écrit le script j'ai un peu pagayé et j'ai du faire passer pleins de batteries de tests fonctionnels théorique etc etc donc j'ai été radical sur la configuration du réseau parsque rien n'allait comme je voulais.

      J'ai vu des trucs irrationnels du genre la route de passerelle qui se dédouble toute seule quoi qu'on y fasse. Et ca je cherche toujours à comprendre… Mais ca marche !? Je me demande par où passent les packet!!!

      Y a deux routes identiques. les paquets prennent deux fois la passerelle ou se divisent enfin je sais pas je vous embrouille la désolé…

      Du coup je vais me détendre et essayer cette propal, merci.

  • # Adresse MAC : Les bases

    Posté par  (site web personnel) . Évalué à 4.

    Pour répondre à la question "Sinon à quoi sert l'adresse MAC?" :

    L'adresse MAC est un numéro unique qui est définie par le constructeur de la carte réseau. C'est assez bizarre que ce soit lié au BIOS de ta machine, j'en doute, par contre il n'est pas étonnant que le BIOS te montre cette information.

    La partie gauche de l'adresse MAC identifie le constructeur de la carte réseau, tandis que la partie droite identifie de manière unique la carte. C'est définie en usine, en programmant une zone de mémoire du contrôleur.

    Pour une communication IP, cette adresse MAC est utilisée de cette manière :
    - la machine A (IP_A) veut envoyer un paquet à la machine B (IP_B)
    - Si A et B ne sont pas dans le même sous réseau, définit par le masque de sous-réseau, alors A va envoyer un message à la passerelle réseau en lui disant "débrouilles-toi pour envoyer ce paquet à IP_B"
    - Si A et B sont dans le même sous-réseau :
    - A envoie un message 'ARP' qui demande "qui a l'adresse IP IP_B". Le paquet Ethernet ARP contient un broadcast en temps qu'adresse de destination
    - B va répondre "Je suis l'adresse IP_B. Mon adresse MAC est x.x.x.x.x.x
    - A peut alors remplir un paquet ethernet, qui contient l'adresse MAC de B
    - La carte réseau de B écoute tous les messages qui passent sur le réseau. Mais lorsqu'elle en voit un qui contient son adresse MAC, elle l'intercepte, et la fait remonter à l'OS

    Résumé :
    - l'adresse MAC est utilisé par le hardware, afin d'identifier si un paquet est destiné à la machine
    - en IPv4, cette adresse MAC NE sert QUE pour la connexion locale (sans utiliser la passerelle), entre deux machines du même réseau IP
    - en IPv6 c'est aussi le cas. Cependant, les adresses IPv6 contiennent généralement aussi l'adresse MAC (partie droite de l'adresse IP), afin de rendre les adresses IP plus "uniques". Effet collatéral : Cela réduit l'anonymat des machines (l'adresse MAC est supposé être unique), mais cela peut se contourner (le kernel Linux peut gérer une adresse IPv6 différente pour chaque transaction IP (du SYN jusqu'au FIN).

    • [^] # Re: Adresse MAC : Les bases

      Posté par  . Évalué à -4.

      Merci pour cette explication exaustive.

      • en IPv4, cette adresse MAC NE sert QUE pour la connexion locale (sans utiliser la passerelle), entre deux machines du même réseau IP

      Et donc on pourrait filtrer les adresse macs (en IPV4 et IPV6) au niveau de notre box si celles-ci ne sont pas utiles pour alléger la quantité de données qui passe peut-être ?

      Pareil IPV6 est codé sur 128bits IPV4 sur 32bits et IPV6 propose des passerelles IPV6-IPV4.

      Il pourrait être intéressant d'avoir le choix de passer de l'un à l'autre si on veut par exemple compenser l'effet joul (tout en utilisant les adresses mac au besoin qui sont codées sur 64bits ?

      Celà dit peut être que mon propos est désilusoir s'il l'on considère la proportion des datas ainsi adressées.

      • [^] # Re: Adresse MAC : Les bases

        Posté par  . Évalué à 2.

        Et donc on pourrait filtrer les adresse macs (en IPV4 et IPV6) au niveau de notre box si celles-ci ne sont pas utiles pour alléger la quantité de données qui passe peut-être ?

        C'est déjà le cas, l'@MAC ne passe pas les routeurs.

  • # systemd un jeu d'enfant

    Posté par  . Évalué à 0.

    Sur deux commandes et deux cfg on éxécute notre script à la sortie de veille du système:

    Définition d'un signal émis par l'OS lors de la sortie de veille
    # vi /etc/systemd/logind.conf

    HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend

    On crée un nouveau service/démon

    # touch /etc/systemd/system/root-resume.service

    [Unit]
Description=On éxécute le service lorsque ces signaux sont émis
After=suspend.target
After=hibernate.target
After=hybrid-sleep.target

[Service]
Type=oneshot
ExecStart=/etc/rc.local

[Install]
WantedBy=suspend.target
WantedBy=hibernate.target
WantedBy=hybrid.sleep.target
    # systemctl enable root-resume

    Le service une fois activé lance notre script au réveil du système ! Ainsi le réseau est toujours configuré et il n'y a aucun problème.

    • [^] # Re: systemd un jeu d'enfant

      Posté par  . Évalué à 0.

      … et comme c'était trop simple allons un peu plus loin grâce avec ce deuxième élément de résolution qui m'a été proposé par quelqu'un.

      On oublie les signaux.
      On oublie la mise en veille qui plante le réseau.

      On va utiliser un paramètre de systemd.
      Il y a une option dans un fichier tout simplement.

      # touch /etc/systemd/network/00-default.link

      [Link]
NamePolicy=kernel database onboard slot pathName
MACAddressPolicy=random

      Et je pense que c'est tellement simple qu'il n'y a rien à dire de plus, man systemd.link pour les options peut-être ?

  • # BIOS + pilote

    Posté par  . Évalué à 3.

    Une mise à jour du BIOS/UEFI c'est vraiment pas compliqué. Durant ces 15 dernières années j'ai flashé un nombre de BIOS que je ne peux plus calculer, via les utilitaires Windows, DOS avec disquette, FreeDOS, flashrom sur Linux, via le BIOS même, via le UEFI même, bref aucun soucis… ça se passe bien. La seule couille qui pourrait arriver en fait c'est un panne électrique pendant les quelques secondes qui se passent. Ça serait juste pas de chance.

    De plus, s'il y a un bug au niveau du BIOS qui amène ton problème d'@MAC, la correction propre est de fixer le BIOS, pas des scripts dans l'OS.

    En plus de ça, les mise à jours apportent parfois des améliorations intéressantes à faire, même sans bug particulier connu par l'utilisateur.

    Ceci dit, je doute que ton soucis vienne du BIOS mais plutôt du pilote Linux qui n'est pas le bon. Je crois que j'avais eu ça (@MAC 00:00:00:00:00:00) sur une CentOS 6 avec une carte mère assez récente qui avait un chipset Realtek trop récent. Sur une distribution plus récente l'@MAC était bien reconnue.

    Quelle version d'Ubuntu tu utilises ?
    Et c'est quoi le chipset réseau ? (lspci -nnk)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.