La version d’origine est plus claire. Continuer à faire abstraction de la pile de protocoles IPv6 en 2025 n’est pas une bonne idée. Les gens ayant des connaissances sur les réseaux informatiques mais ne connaissant pas IPv6 devraient parcourir le MOOC « Objectif IPv6 » de l’Institut Mines-Télécom, au moins, pour avoir des notions et se faire une idée (voir les prérequis). IPv6 deviendra incontournable.
Voici quelques remarques sur la forme.
uci -q batch <<EOF
set network.lan.proto='dhcp'
EOF
Le serveur DHCP du routeur peut configurer l’interface de gestion du point d’accès.
uci -q batch <<EOF
set.wireless.wifi_device[0].country='YourCountryCode'
set.wireless.wifi_device[1].country='YourCountryCode'
set wireless.wifi_iface[0].ssid='YourSSID'
set.wireless.wifi_iface[1].ssid='YourSSID'
set wireless.wifi_iface[0].key='YourSecurePassphrase'
set.wireless.wifi_iface[1].key='YourSecurePassphrase'
EOF
Exploiter uci batch serait plus efficace que de recopier intégralement des sections. On perçoit mieux les paramètres à modifier et on peut l’appliquer instantanément à sa configuration via la ligne de commande.
uci -q batch <<EOF
set network.wan.disabled='1'
set network.wan6.disabled='1'
EOF
Il est préférable de désactiver l’interface WAN plutôt que de la supprimer de la configuration. On pourrait ainsi potentiellement la réactiver pour mettre à jour le point d’accès.
De même, selon l’article, il est préférable de désactiver le serveur DHCP du point d’accès.
uci -q batch <<EOF
set dhcp.lan.ignore='1'
EOF
À noter que l’équivalent en ligne de commande de l’opération LuCI correspondante serait :
service dnsmasq stop
service dnsmasq disable
On aurait également pu créer une image personnalisée ne contenant aucun serveur DHCP (c.f. sélecteur de micrologiciel). Dans ce cas, il aurait fallu configurer soi-même l’interface « locale au lien » du point d’accès.
Merci pour l’ensemble des remarques, j’apprécie la démonstration par l’usage du binaire uci. Néanmoins :
Qui a parlé de “faire abstraction du protocole IPv…” ? pas moi, surtout pas !
Les trames DHCP sont fournies par le routeur principal, que ce soit pour IPv4/v6. Le répéteur ne fait que les transmettre aux différents périphériques concernés. (et soit, soit qu’ils soient connectés physiquement sur l’un des ports physiques, soit par le biais du Wifi). (Et concernant mon réseau @home, les deux protocoles fonctionnent très bien, sans soucis). Quoiqu’il en soit, l’usage de ceux-ci n’est pas le tenant de cet article, soit de transformer son routeur OpenWRT en répéteur wifi.
Concernant le fait de désactiver WAN, soit. C’est perdre l’utilisation d’un port physique…
Personnellement, je préfère le “ré-emploi”.
Sinon, concernant la désactivation du serveur DHCP du répéteur, l’usage de l’option ignore n’est pas l’équivalent du fait d’arrêter et de désactiver le service. Autrement l’option n’aurait aucun sens, et n’aurait pas été créée.
La documentation officielle à laquelle je fais référence dans l’article dit clairement qu’il n’est pas recommandé ni nécessaire de désactiver le service dnsmasq (DHCP), il sera de toute façon réactiver lors du prochain sysupgrade. La seule manière de garantir le fait qu’il ne soit pas “fonctionnel” est l’usage de l’option idoine.
Voilà (dans l’immédiat).
PS : Je vais “réfléchir” à actualiser ledit article avec l’à-propos de la commande uci. Encore une fois, merci pour ces remarques.
Merci également pour ce retour ! J’aime bien découvrir des articles pratico-techniques : savoirs-faire, connaissances, apprentissage, transmission, goût d’entreprendre.
J’ai perçu un traitement légèrement différent pour IPv6 par rapport à IPv4 et cela m’a un peu embrouillé l’esprit.
Modifiez le fichier /etc/config/dhcp pour ajouter l’option suivante option ignore ‘1’ dans la section config dhcp ‘lan’ ; supprimez aussi toutes les options relatives à IPv6 !
Je croyais qu’il suffisait de changer la valeur de l’option ignore pour désactiver totalement les serveurs DHCPv4/v6. Ce qui n’est pas forcément le cas. La documentation laisse penser qu’il faille aussi changer les valeurs des autres options. En cherchant rapidement, je ne suis pas parvenu à déterminer si dnsmasq supportait cette option. En somme, je n’ai pas vérifié.
On peut également placer la sous-commande commit dans le document en ligne (here-document).
uci -q batch <<EOF
set network.lan.dns='192.168.1.1'
set network.lan.ipaddr='192.168.1.3'
set network.lan.netmask='255.255.255.0'
set network.lan.gateway='192.168.1.1'
set network.lan.proto='static'
commit
EOF
Autre optimisation possible : remplacer <<EOF par <<-EOF. Les lignes suivantes sont indentées avec une tabulation (c.f. dash).
La version d’origine est plus claire. Continuer à faire abstraction de la pile de protocoles IPv6 en 2025 n’est pas une bonne idée. Les gens ayant des connaissances sur les réseaux informatiques mais ne connaissant pas IPv6 devraient parcourir le MOOC « Objectif IPv6 » de l’Institut Mines-Télécom, au moins, pour avoir des notions et se faire une idée (voir les prérequis). IPv6 deviendra incontournable.
Voici quelques remarques sur la forme.
Le serveur DHCP du routeur peut configurer l’interface de gestion du point d’accès.
Exploiter uci batch serait plus efficace que de recopier intégralement des sections. On perçoit mieux les paramètres à modifier et on peut l’appliquer instantanément à sa configuration via la ligne de commande.
Il est préférable de désactiver l’interface WAN plutôt que de la supprimer de la configuration. On pourrait ainsi potentiellement la réactiver pour mettre à jour le point d’accès.
De même, selon l’article, il est préférable de désactiver le serveur DHCP du point d’accès.
À noter que l’équivalent en ligne de commande de l’opération LuCI correspondante serait :
On aurait également pu créer une image personnalisée ne contenant aucun serveur DHCP (c.f. sélecteur de micrologiciel). Dans ce cas, il aurait fallu configurer soi-même l’interface « locale au lien » du point d’accès.
Bonjour,
Merci pour l’ensemble des remarques, j’apprécie la démonstration par l’usage du binaire
uci. Néanmoins :Qui a parlé de “faire abstraction du protocole IPv…” ? pas moi, surtout pas ! Les trames DHCP sont fournies par le routeur principal, que ce soit pour IPv4/v6. Le répéteur ne fait que les transmettre aux différents périphériques concernés. (et soit, soit qu’ils soient connectés physiquement sur l’un des ports physiques, soit par le biais du Wifi). (Et concernant mon réseau @home, les deux protocoles fonctionnent très bien, sans soucis). Quoiqu’il en soit, l’usage de ceux-ci n’est pas le tenant de cet article, soit de transformer son routeur OpenWRT en répéteur wifi.
Concernant le fait de désactiver WAN, soit. C’est perdre l’utilisation d’un port physique… Personnellement, je préfère le “ré-emploi”.
Sinon, concernant la désactivation du serveur DHCP du répéteur, l’usage de l’option
ignoren’est pas l’équivalent du fait d’arrêter et de désactiver le service. Autrement l’option n’aurait aucun sens, et n’aurait pas été créée. La documentation officielle à laquelle je fais référence dans l’article dit clairement qu’il n’est pas recommandé ni nécessaire de désactiver le service dnsmasq (DHCP), il sera de toute façon réactiver lors du prochainsysupgrade. La seule manière de garantir le fait qu’il ne soit pas “fonctionnel” est l’usage de l’option idoine.Voilà (dans l’immédiat).
PS : Je vais “réfléchir” à actualiser ledit article avec l’à-propos de la commande
uci. Encore une fois, merci pour ces remarques.Merci également pour ce retour ! J’aime bien découvrir des articles pratico-techniques : savoirs-faire, connaissances, apprentissage, transmission, goût d’entreprendre.
J’ai perçu un traitement légèrement différent pour IPv6 par rapport à IPv4 et cela m’a un peu embrouillé l’esprit.
Je croyais qu’il suffisait de changer la valeur de l’option ignore pour désactiver totalement les serveurs DHCPv4/v6. Ce qui n’est pas forcément le cas. La documentation laisse penser qu’il faille aussi changer les valeurs des autres options. En cherchant rapidement, je ne suis pas parvenu à déterminer si dnsmasq supportait cette option. En somme, je n’ai pas vérifié.
Article modifié en cours d’upload ! (avec une petite mention spécifique dans une section finale nommée “Remerciement”)
On peut également placer la sous-commande commit dans le document en ligne (here-document).
Autre optimisation possible : remplacer
<<EOFpar<<-EOF. Les lignes suivantes sont indentées avec une tabulation (c.f. dash).:-)