Gluon: TL-WR1043NDv4 : MAC incorrect sur les appareils dotés d'un micrologiciel plus récent

Créé le 11 sept. 2017  ·  5Commentaires  ·  Source: freifunk-gluon/gluon

si vous obtenez un TP-Link TL-WR1043ND avec la version stock du firmware 170401/2017-04-01 ou si vous mettez à jour un ancien vers cette version - alors la LEDE ou le gluon flashé ne trouve plus l'adresse MAC et utilise quelque chose comme "0000100000".

@NeoRaider a créé un correctif ( https://paste.debian.net/plain/985485 ) qui résout le problème.
J'ai testé cela et cela fonctionne comme prévu.

ce ticket est destiné à suivre l'état d'intégration dans toutes les branches en amont et locales ainsi qu'à servir d'élément d'information pour les personnes rencontrant le même problème.

bug hardware upstream issue

Commentaire le plus utile

Le rétroportage était assez simple, je l'ai donc poussé vers la v2016.2.x également.

Tous les 5 commentaires

même problème sur 2016.2.7
grafik

btw : comme solution rapide pour les nœuds affectés, vous pouvez attribuer un nouvel ID manuellement :

export NEWMAC=00:60:2f$(dd bs=1 count=3 if=/dev/random 2>/dev/null |hexdump -v -e '/1 ":%02x"'); echo $NEWMAC>/lib/gluon/core/sysconfig/primary_mac; export NEWKEY=$(fastd --generate-key|grep Secret|cut -d" " -f 2)
uci set fastd.mesh_vpn.secret=$NEWKEY; uci set network.client.macaddr=$NEWMAC; uci set network.bat0.macaddr=$NEWMAC; uci commit; echo NEWMAC  $NEWMAC; echo NEWFASTDKEY $NEWKEY
reboot;


ouais, n'a rien à voir avec la version gluon, j'ai déjà testé gluon v2016.2.x, gluon v2017.1.x, gluon master et lede-17.01 et lede-master -- toutes ces branches ont besoin du correctif.

Avons-nous "l'espoir" d'avoir un correctif dans la version v2016.2.x ?
Sinon (puisqu'il s'agit peut-être d'un EOLed), je créerais un script de correction rapide à exécuter après l'installation afin de randomiser le MAC.

Le rétroportage était assez simple, je l'ai donc poussé vers la v2016.2.x également.

Cette page vous a été utile?
0 / 5 - 0 notes