La Fibre
Datacenter et équipements réseaux => Routeurs => 
OpenWrt => Discussion démarrée par: basilix le 13 juin 2024 à 11:24:19
-
Je cherche à spécifier les paramètres par défaut du micrologiciel. Une réinitialisation produira une connexion Internet directement opérationnelle.
Et je crois que j'ai trouvé le bon moyen pour y parvenir.
La clé est d'intégrer les paramètres du FAI lors de la génération de l'image. Une solution semble être d'adapter le script /bin/configure_generate et
élaborer un script /etc/board.d/03_box dont le rôle est de sélectionner le FAI (similaire à /etc/board.d/02_network selon le modèle) pour ajouter
les nouveaux paramètres relatifs à la connexion FAI au fichier /etc/board.json.
En conséquence, configure_generate aura accès directement aux informations permettant de définir les choses de façon logique. Au vu du résultat,
se baser essentiellement sur uci-defaults pour y parvenir rendrait les choses inextricables.
-
Bonjour Basilix,
Je crois comprendre que tu veux faire un partage d'expérience, pourrais-tu être plus précis sur la solution trouvée ? Un exemple de fichier ?
Au vu du résultat, se baser essentiellement sur uci-defaults pour y parvenir rendrait les choses inextricables.
Peux-tu préciser le caractère inextricable de la chose ?
-
@ppn_sd :
Cela va me prendre un certain temps. Le principe est basique mais il faut voir si cela s'ajuste convenablement en terme d'espacement.
C'est inextricable avec uci-defaults car on ne peut pas extraire facilement les informations dans la configuration. Les valeurs sont
enregistrées sous forme de variables d'environnement. Les fichiers /etc/config/.. sont interprétés comme des scripts par le Shell.
config interface 'lan'
option device 'br-lan'
config et option sont en fait interprétées comme des fonctions par le Shell.
CONFIG_lan_TYPE='interface'
CONFIG_lan_device='br-lan'
C'est de cette manière que les fonctions Shell config_foreach et config_get accèdent aux informations. Ce n'est pas vraiment
exploitable avec uci-defaults. On ne peut pas non plus parcourir simplement différents niveaux de la configuration avec uci.
Dans l'ensemble, c'est dur d'agir sur la structure de donnée que représente la configuration avec des structures de contrôle classique.
C'est la raison probable pour laquelle les données sont analysées dans le format JSON par l'intermédiaire de l'interface Shell
jshn.sh (https://openwrt.org/docs/guide-developer/jshn) dans les scripts de configuration du micrologiciel.
-
On code en dur les paramètres FAI avec des fonctions Shell, dans le fichier /etc/board.json. On re-calque ensuite les paramètres de ce fichier lors du processus de configuration du micrologiciel.
Les appels de fonctions Shell ainsi que le processus de configuration du micrologiciel devraient offrir une abstraction suffisante en exploitant la structure existante. On intègre les informations comme
des données transmises aux fonctions. Les fonctions ne font ensuite que refléter le processus de configuration du micrologiciel.
-
Salut,
Pas sur de bien comprendre le besoin.
Vous parlez de image-builder pour construire l'image ?
Pour ma part, je me limite à une image avec les bon paquets + l'addresse du lan et du router.
Ca se paramètre dans files\etc\uci-defaults du dossier image builder.
Donc, la plupart du temps, upgrade avec conservation des paramètres.
Et en cas de cata ou de transfert sur un autre autre réseau, remise à zero avec donc un fonctionnel limité mais simple. Et rechargement de la config spécifique, depuis le backup de config sauvegardée séparément.
Intégrer toute la config dans l'image est séduisant, mais c'est casse gueule. Si marche pas, vous aurez bcp plus de mal à reprendre la main sur le routeur.
-
On peut transférer ses fichiers de configuration avec le constructeur d'image (a.k.a. Image Builder). L'inconvénient c'est qu'on charge toute sa configuration en bloc sans aucune modularité.
L'avantage d'intégrer les paramètres sous formes de données dans du code structuré est la granularité et la compacité. Vu que les données sont intégrées nativement au code on peut en
faire partiellement abstraction (on formalise en quelque sorte un modèle). Mais cela est plutôt pertinent quand la configuration du routeur est complexe à réaliser pour l'administrateur. Je
pense qu'on peut ainsi ajouter et retirer des composants au cours d'expérimentations simplement sans tout casser et rendre les choses plus accessibles. Par contre, il faut sûrement se
maintenir à niveau (être en phase) avec le développement de OpenWrt pour garantir que cela fonctionne. Je cherche à élaborer quelque chose de simple mais efficace et complexifier
la configuration de mon routeur progressivement (faire des tests d'intégration de fonctionnalités).
-
Actuellement, la quantité de données à intégrer ne me paraît pas démesurée. J'ai juste ajouté box et livebox manuellement au fichier /etc/board.json pour me représenter les choses.
{
"model": {
"id": "bananapi,bpi-r3",
"name": "Bananapi BPI-R3",
},
"box": {
"id": "livebox,livebox_5",
"name": "Livebox 5",
"macaddr": "00:11:22:33:44:55",
},
"network": {
"lan": {
"ports": [
"lan1",
"lan2",
"lan3",
"lan4",
"sfp2",
"wan"
],
"protocol": "static"
},
"wan": {
"device": "eth1",
"protocol": "dhcp",
"macaddr": "00:11:22:33:44:55",
}
},
"livebox": {
"ipv4": {
"clientid": "01001122334455",
"reqopts": "1 3 6 15 28 51 58 59 90 119 120 125",
"vendorid": "FSVDSL_livebox.Internet.softathome.Livebox5",
"90": "<authentication>",
},
"ipv6": {
"clientid": "00030001001122334455",
"reqopts": "11 17 23 24",
"11": "<authentication>",
"userclass": "FSVDSL_livebox.Internet.softathome.Livebox5",
"vendorclass": "arcadyan",
},
"vlan": {
"vid": "832",
"cos": "6:6",
}
}
"system": {
"compat_version": "1.2"
},
"wlan": {
"phy0": {
"path": "platform/soc/18000000.wifi",
"info": {
"antenna_rx": 15,
"antenna_tx": 15,
"bands": {
"2G": {
"ht": true,
"he": true,
"max_width": 40,
"modes": [
"NOHT",
"HT20",
"HE20",
"HT40",
"HE40"
]
}
}
}
},
"phy1": {
"path": "platform/soc/18000000.wifi+1",
"info": {
"antenna_rx": 15,
"antenna_tx": 15,
"bands": {
"5G": {
"ht": true,
"vht": true,
"he": true,
"max_width": 160,
"modes": [
"NOHT",
"HT20",
"VHT20",
"HE20",
"HT40",
"VHT40",
"VHT80",
"HE80",
"VHT160",
"HE160"
]
}
}
}
}
}
}
Idéalement, il faudrait créer un paquet logiciel OpenWrt correspondant à un FAI comme cela est fait pour chaque SBC (ordinateur monocarte).
-
On pourrait aussi faire un "uci show" pour exporter toute sa config, d'en récuperer ce qui nous interesse et de le coller sur le firmware selector. En faisant précéder chaque ligne par un "uci set"
https://firmware-selector.openwrt.org/?version=23.05.3&target=mediatek%2Ffilogic&id=bananapi_bpi-r3
Donc on mettrait ça dans la section : Script à exécuter au premier démarrage (uci-defaults)
(https://i.imgur.com/CUu0k9q.png)
un petit "uci show network" permetrait déjà de récupérer tout sa config réseau.
-
@rooot :
La méthode serait fastidieuse car elle est relative à une configuration. Il faudrait comparer les modifications à chaque reprise.
Le code dans uci-defaults serait fragmentaire et peu lisible (sous une forme incomplète ou hétéroclite).
Je préfère ma proposition car on peut intégrer un paquet et automatiser de façon transparente.
-
Le fichier board.json est transformé en commandes uci à la fin.
Il faudrait comparer les modifications à chaque reprise.
Dans tous les cas, c'est pareil pour le board.json. Il faut bien le mettre à jour quelque part pour s'en servir à la prochaine mise à jour non ?
J'utilise un script pour mettre à jour openwrt et j'effectue un simple contrôle des sommes de fichiers entre /etc et files/etc pour voir si des modifications sont passées à l'as.
-
@ppn_sd :
Le fichier /etc/board.json apporte les données pour générer l'image du micrologiciel. Tandis que la méthode avancée par @rooot change les fichiers de configuration ad hoc.
Les paramètres afférents dans /etc/board.json peuvent être intégrés de manière logique lors de la génération de l'image (à ce moment seulement). Ce sont des fichiers
composant l'image de base (inclus par défaut). La configuration peut être générée automatiquement au premier amorçage du système grâce au script Shell /bin/config_generate.
Ce n'est pas équivalent car on peut potentiellement adapter systématiquement le processus à différents FAI de façon quasi transparente pour l'utilisateur.
-
Note : Le fichier /etc/board.json peut lui-même être généré automatiquement. C'est ce que je souhaite faire en élaborant entre autre les scripts
/etc/board.d/03_box et /lib/functions/box-defaults.sh.
-
@ppn_sd :
Le fichier /etc/board.json apporte les données pour générer l'image du micrologiciel. Tandis que la méthode avancée par @rooot change les fichiers de configuration ad hoc.
Le script config_generate parse le fichier board.json et lance les commandes uci avec les paramètres trouvés. Il n'y a pas de différence, in fine. Ou alors j'ai loupé une subtilité ?
Les paramètres afférents dans /etc/board.json peuvent être intégrés de manière logique lors de la génération de l'image (à ce moment seulement). Ce sont des fichiers composant l'image de base (inclus par défaut). La configuration peut être générée automatiquement au premier amorçage du système grâce au script Shell /bin/config_generate.
Les fichiers dans uci-default sont également intégrés dans l'image.
Je ne vois pas le problème d'utiliser board.json mais je ne saisis pas les avantages que tu essaies de souligner.
Ce n'est pas équivalent car on peut potentiellement adapter systématiquement le processus à différents FAI de façon quasi transparente pour l'utilisateur.
Tu es toujours plus ou moins lié à des noms de board ou d'interfaces selon le matériel.
-
@ppn_sd :
Il faut reconstituer la structure de donnée lorsqu'on initialise la configuration avec uci-defaults. Ce qui n'est pas vraiment prévu.
En accédant aux données dans /bin/config_generate on peut changer ou adapter la structure de la configuration dans le code.
Cela fonctionne sur le même principe que la sélection du board. Des fichiers spécifiques sont incorporés dans l'image. Par
exemple, /etc/board.d/03_box serait une instanciation de configuration définie pour un FAI.
-
personnellement l'unique (et gros) avantage de construire une image perso est d'y ajouter wiregard et zerotier pour les routeurs en 8/4M ram/flash.
sinon, ca tient pas :D
(et évidemment, une compilo par appareil)
-
Idem pour de vieux AP où j'en suis à quelques Ko près. Même pas opkg d'installé.
-
L'intérêt à construire son image n'est pas toujours aussi pertinent. Tout dépend de la difficulté à configurer son routeur.
Je m'aperçois qu'il aurait aussi fallu changer l'interface pour intégrer véritablement mes scripts dans OpenWrt. Sinon,
cela reviendrait à ce que chaque utilisateur adapte lui-même le script /bin/config_generate. De base, pour que
cela soit opérationnel il faudrait seulement intégrer du code complémentaire dans /bin/config_generate.
Ce serait possible mais ce n'est pas sûr que cela convienne au projet OpenWrt. Cela aurait évité de devoir étudier la
configuration de chaque FAI pour pouvoir se connecter. Mais je ne suis pas certain que ce soit une bonne idée que
tout le monde ait accès aussi facilement : ce serait un peu comme conduire sans permis.
-
J'ai complété la première étape [1]. Le code reste lisible car il est relativement simple. Par contre, ce n'est pas tellement propre. Il faudrait que je le rende plus homogène et vérifier
ses propriétés (générique, fiable, extensible). C'est pas encore bon. Et je ne sais pas si je le publierais.
[1] Intégrer les paramètres de connexion FAI dans le fichier /etc/board.json.
-
Je n'ai pas absolument abouti, lors de la deuxième étape, mais le résultat est probant [1]. Durant ce test, je n'ai eu à ajouter qu'une seule fonction dans /etc/config_generate.
On peut spécifier des options qui ne sont potentiellement pas définies très simplement. uci ne les ajoutera pas car la valeur associée sera inexistante (ou vide). Cette caractéristique
permet de produire du code générique (qui n'est pas spécifique à un FAI mais correspondant aux options DHCP ; c'est-à-dire sans avoir à analyser les options disponibles).
[1] Intégrer automatiquement les options DHCP(v6) dans le fichier /etc/config/network.
-
J'ai écrit plusieurs lignes pour implémenter le VLAN sur l'interface WAN. Mais cela n'a pas fonctionné, et surtout, il y a une fonction qui existait déjà auparavant.
(Faire fausse route.)
Je croyais à tord que la fonction generate_bridge_vlan faisait référence aux commutateurs ne supportant pas l'architecture DSA. Tout est nouveau. Je
croyais que je devais définir un VLAN logiciel sur l'interface WAN. J'ai lu sur le Wiki OpenWrt que les nouveaux commutateurs étaient contrôlé par un pilote
DSA bien que le commutateur ne soit associé qu'à un seul contrôleur Ethernet. Sur le BPI-R3, le port wan (eth0) est placé dans le pont br-wan avec le port
SFP (eth1). Dans le tutoriel Orange de @ubune sur OpenWrt, on définit un VLAN logiciel mais sur une seule interface laquelle n'est pas de type bridge (pont).
Hyperliens
Is there a VLAN-capable hardware switch integrated in your device? (https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#is_there_a_vlan-capable_hardware_switch_integrated_in_your_device)
Multiple networks using VLANs (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#multiple_networks_using_vlans)
-
J'obtiens la configuration suivante. Pour ce faire, j'ai activé le paramètre vlan. La fonction ucidef_set_bridge_device m'a parue nécessaire. C'est l'unique fonction dans la bibliothèque « uci-defaults.sh » qui
crée l'entrée « bridge » dans le fichier /etc/board.json. Cette entrée permet d'activer l'invocation de la fonction generate_bridge_vlan du script /bin/config_generate.
config device 'switch0'
option name 'switch0'
option type 'bridge'
config bridge-vlan 'lan_vlan'
option device 'switch0'
option vlan '1'
option ports 'lan1 lan2 lan3 lan4 sfp2'
config interface 'lan'
option device 'switch0.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config bridge-vlan 'wan_vlan'
option device 'switch0'
option vlan '832'
option ports 'eth1 wan'
config device
option name 'switch0.832'
option macaddr '11:22:33:44:55:66'
config interface 'wan'
option device 'switch0.832'
option proto 'dhcp'
config interface 'wan6'
option device 'switch0.832'
option proto 'dhcpv6'
Le VLAN 832 (FAI Orange) est bien défini sur l'interface WAN (wan et wan6). Tristement, je n'arrive pas à spécifier la CoS comme pour une interface L2 de type « vlan 802.1q ». Je suis un peu perdu.
[14:30] J'ai trouvé un lien sur le sujet dans le forum OpenWrt (https://forum.openwrt.org/t/single-tagged-dsa-port-functional-difference-between-bridge-vlan-and-802-1q-device/139011) mais cela ne m'aide pas beaucoup.
-
C'est compliqué !
Il semblerait que le paramètre bridge (/etc/board.d/03_box) produise un effet de bord avec le paramètre macaddr (/etc/board.d/02_network). Les deux ne sont apparemment pas compatibles.
config device
option name 'switch0.832'
option macaddr '11:22:33:44:55:66'
Ci-dessus, on peut s'apercevoir qu'un nouveau périphérique réseau Ethernet a été créé.
[ -n "$bridge" ] && {
[ -z "$ports" ] && ports="$device"
if [ -z "$vlan" ]; then
bridge_vlan_id=$((bridge_vlan_id + 1))
vlan=$bridge_vlan_id
fi
generate_bridge_vlan $1 $bridge "$ports" $vlan
device=$bridge.$vlan
type=""
}
if [ -n "$macaddr" ]; then
uci -q batch <<-EOF
add network device
set network.@device[-1].name='$device'
set network.@device[-1].macaddr='$macaddr'
EOF
fi
En y regardant de plus près, on peut s'apercevoir que c'est l'assignation de la valeur $bridge.vlan à la variable device qui produit un bogue. L'idée est d'obtenir
notre VLAN $vlan en créant automatiquement le périphérique Ethernet virtuel « 802.1q » lorsqu'on spécifie un nom d'interface composé d'un point suivi d'un nombre.
Le problème étant que ce nom switch.832 ne désigne plus implicitement le VLAN 832 car il a été repris auparavant pour créer un périphérique Ethernet virtuel
usuel (sans VLAN).
config interface 'wan'
option device 'switch0.832'
option proto 'dhcp'
An equivalent configuration in implicit notation is shown below. Note that the device sections are missing and the VLAN ID and parent interface is derived from the ifname option value in dot-notation.
config interface 'lan'
option type 'bridge'
option ifname 'eth0.106'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
config interface 'wan'
option ifname 'eth0.204'
option proto 'dhcp'
Source : https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#creating_driver-level_vlans
Note : ifname semble avoir été déprécié et remplacé par device.
-
Je constate que cela modifie la configuration initiale.
Avant, c'était comme si il y avait deux ponts séparés : br-wan et br-lan. Maintenant, cela donne deux ponts bridge-vlan mais sur le même commutateur virtuel switch0 (type « pont »).
Qu'est-ce que cela change ? Est-ce important ?
-
Le sujet est exposé dans la documentation de OpenWrt (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial). Apparamment, l'auteur a un doute à ce propos : « This item needs careful vetting... ».
J'ai aussi trouvé une réponse sur le forum OpenWrt.
Les "réseaux pontés multiples" peuvent transmettre des trames marquées VLAN telles quelles (le filtrage VLAN est désactivé), alors que les "réseaux VLAN multiples sur un seul pont" ne le peuvent pas.
Source : https://forum.openwrt.org/t/dsa-multiple-bridges-vs-multiple-vlans-on-a-single-bridge/111331
-
Je pense avoir compris.
Les VLAN sont activés sur les commutateurs (ou ponts) (c'est le concept original). De plus, toutes les cartes réseaux ne supportent pas la technologie VLAN.
En outre, l'architecture DSA permet de caractériser les ports d'un commutateur comme différents périphériques réseaux. Sur mon BPI R3, mon commutateur
est relié à une carte Ethernet. Le SFP n°1 est relié à une autre carte Ethernet. Le pont br-lan permet de relier différents ports du commutateur alors que
le pont br-wan permet de relier le port « wan » du commutateur à celui du SFP n°1 « eth1 » qui n'est pas « relié » à l'origine au commutateur (il y a deux
cartes réseaux).
Il semblerait donc qu'il soit souhaitable de créer deux ponts. Pour créer un VLAN 832 sur l'interface WAN (VLAN FAI) il faudrait seulement activer le filtrage
VLAN sur le pont br-wan. En d'autres termes, il faudrait utiliser la fonction generate_bridge_vlan directement dans le script /bin/config_generate
sans définir le paramètre bridge dans /etc/board.json (ne pas invoquer la fonction ucidef_set_bridge_device dans le script /etc/board.d/03_box).
-
J'ai réussi ce que je voulais entreprendre et je suis plutôt satisfait du résultat. Il y a encore pas mal de choses à revoir ou à tester mais cela fonctionne dans l'ensemble.
Il n'y a pas beaucoup de lignes à ajouter dans le script Shell /bin/config_generate. En testant rigoureusement, il y aurait éventuellement moyen de soumettre
mon code au projet OpenWrt. Il faudrait que j'étudie les autres façons pour comparer. Il aurait fallu que je trouve un moyen de rentrer une adresse MAC fixée lors de
l'amorçage avec Uboot [1]. L'autre partie du code devrait être placée dans un paquet que l'on peut intégrer à OpenWrt (dans l'image ou via le gestionnaire de paquets).
Ce code est une retranscription des paramètres de connectivité spécifiques à Orange. Mais j'ai d'autres chats à fouetter !
[1] Dans un fichier pour ne pas changer d'adresse MAC en cas de réinitialisation usine.
-
Finalement, j'ai trouvé comment procéder pour définir l'adresse MAC de mon BPI R3 (carte de développement).
C'est une variable d'environnement U-boot qui va initialiser l'adresse MAC au premier amorçage de la machine.
La variable d'environnement porte un nom correspondant à l'expression régulière eth[0-9]*addr. Aucune
variable d'environnement ayant ce nom n'est définie sur le BPI R3 car c'est une carte de développement. On
peut définir une variable d'environnement U-boot en ligne de commande avec U-boot (durant l'amorçage) ou
avec un utilitaire en ligne de commande disponible sur OpenWrt. Cette variable doit porter une adresse MAC
mais l'assignation n'est que temporaire (mémorisée dans la RAM). On peut l'enregistrer dans une mémoire
non temporaire mais on ne peut lui assigner une valeur qu'une seule fois.
ethaddr
Ethernet address. If CONFIG_REGEX=y, also eth*addr (where * is an integer).
These variables can be set only once (usually during manufacturing of the board). U-Boot refuses to delete or overwrite these variables once they have been set, unless CONFIG_ENV_OVERWRITE is enabled in the board configuration.
Source : https://docs.u-boot.org/en/latest/usage/environment.html
On peut spécifier des variables d'environnement dans un fichier de configuration U-boot.
L'information qu'il me fallait se trouvait dans l'option CONFIG_DEFAULT_ENV_FILE. Elle est définie dans un correctif
BPI R3 (uboot-mediatek/patches/430-add-bpi-r3.patch). Sa valeur est bananapi_bpi-r3_sdmmc_env. C'est dans
ce fichier qu'on peut ajouter la définition d'une variable d'environnement U-boot ethaddr. Il faut donc faire un
correctif pour modifier ce fichier. À tout hasard, je recherche dans le correctif la chaîne de caractère _env. Bingo !
La configuration bananapi_bpi-r3_sdmmc_env est créée à partir de zéro. Il suffit de modifier le correctif
lui-même grâce au mécanisme de correctif intégré à Buildroot « Quilt ». (https://openwrt.org/docs/guide-developer/toolchain/use-patches-with-buildsystem#edit_an_existing_patch)
-
Avez-vous créé un autre utilisateur pour substituer le super-utilisateur « root » ?
-
Il y a une fonction add_group_and_user définie dans /lib/functions.sh.
local rusers="$(sed -ne 's/^Require-User: *//p' $root/usr/lib/opkg/info/${pkgname}.control 2>/dev/null)"
Cela fait référence à un chemin d'accès à un fichier dans un paquet OpenWrt. Dommage ! On ne peut pas l'utiliser littéralement dans uci-defaults.
J'ai l'impression que l'utilisateur peut être amené à remplir malgré lui un rôle de développeur dans sa quête du graal (routeur pré-configuré, personnalisé
et durci).
-
Salut !
Avez-vous déjà installé un autre thème ?
Ce matin, j'ai vu qu'il existe un thème non-officiel « Argon (https://github.com/jerrykuku/luci-theme-argon) ». Il y a aussi un fil de discussion (https://forum.openwrt.org/t/theme-argon-main-thread/122457/1) sur le forum OpenWrt.
-
Ce matin, j'ai vu qu'il existe un thème non-officiel « Argon (https://github.com/jerrykuku/luci-theme-argon) ». Il y a aussi un fil de discussion (https://forum.openwrt.org/t/theme-argon-main-thread/122457/1) sur le forum OpenWrt.
Salut,
J'ai installé le theme Argon par le passé, mais il manquait certains menus notamment ceux ajoutés par certains modules ( ex wifishedule ).
Donc plutot sympa, mais pas complétement stable ou fiable. Possible que ca vienne aussi du navigateur utilisé chez moi.
Je suis revenu à la version vanilla.
-
@dr191:
D'accord ! Je préfère un thème actuel et adaptable ou alors bien supporté. Le thème original est quelque peu monotone à mon goût.
Pour créer une nouvelle interface, OUI (https://zhaojh329.github.io/oui/) me semble intéressant. Je suis parano. donc il faut impérativement que je jette un coup d’œil
aux sources avant d'installer quoi que ce soit.
-
On peut définir certains réglages dans le fichier /etc/board.json. :)
Correctifs : [PATCH 00/11] allow loading default credentials from flash (https://lists.openwrt.org/pipermail/openwrt-devel/2024-September/043195.html)
Fichier : /rom/etc/uci-defaults/50-root-passwd
. /usr/share/libubox/jshn.sh
json_init
json_load "$(cat /etc/board.json)"
if json_is_a credentials object; then
json_select credentials
json_get_vars root_password_hash root_password_hash
if [ -n "$root_password_hash" ]; then
sed -i "s|^root:[^:]*|root:$root_password_hash|g" /etc/shadow
fi
json_get_vars root_password_plain root_password_plain
if [ -n "$root_password_plain" ]; then
(echo "$root_password_plain"; sleep 1; echo "$root_password_plain") | passwd root
fi
json_select ..
fi
[18:47]
Le sélecteur de micrologiciel (https://firmware-selector.openwrt.org/) produit un code similaire (c.f. la roue dentée « Script à exécuter au premier démarrage (uci-defaults) »).
# Beware! This script will be in /rom/etc/uci-defaults/ as part of the image.
# Uncomment lines to apply:
#
# wlan_name="OpenWrt"
# wlan_password="12345678"
#
# root_password=""
# lan_ip_address="192.168.1.1"
#
# pppoe_username=""
# pppoe_password=""
# log potential errors
exec >/tmp/setup.log 2>&1
if [ -n "$root_password" ]; then
(echo "$root_password"; sleep 1; echo "$root_password") | passwd > /dev/null
fi
# Configure LAN
# More options: https://openwrt.org/docs/guide-user/base-system/basic-networking
if [ -n "$lan_ip_address" ]; then
uci set network.lan.ipaddr="$lan_ip_address"
uci commit network
fi
# Configure WLAN
# More options: https://openwrt.org/docs/guide-user/network/wifi/basic#wi-fi_interfaces
if [ -n "$wlan_name" -a -n "$wlan_password" -a ${#wlan_password} -ge 8 ]; then
uci set wireless.@wifi-device[0].disabled='0'
uci set wireless.@wifi-iface[0].disabled='0'
uci set wireless.@wifi-iface[0].encryption='psk2'
uci set wireless.@wifi-iface[0].ssid="$wlan_name"
uci set wireless.@wifi-iface[0].key="$wlan_password"
uci commit wireless
fi
# Configure PPPoE
# More options: https://openwrt.org/docs/guide-user/network/wan/wan_interface_protocols#protocol_pppoe_ppp_over_ethernet
if [ -n "$pppoe_username" -a "$pppoe_password" ]; then
uci set network.wan.proto=pppoe
uci set network.wan.username="$pppoe_username"
uci set network.wan.password="$pppoe_password"
uci commit network
fi
echo "All done!"