Auteur Sujet: Remplacement de la Livebox par un routeur Openwrt (Lu 364225 fois)

basilix · « **Réponse #1152 le:** 05 avril 2025 à 12:10:36 »

@simon :

Citer

odhcpc/odhcpd tentent d'émettre des requêtes DHCPv6 et des annonces RA respectivement. Ils ont besoin d'une adresse link-local fonctionnelle pour faire cela, et le temps que l'interface soit configurée, il n'y en a pas forcément ou elles ne sont pas encore utilisables (DAD).

En y réfléchissant, je pense que ce serait un dysfonctionnement majeur (si c'était le cas). Normalement, les interfaces devraient être déjà opérationnelles.
odhcp6c est invoqué à l'amorçage du système par le démon de gestion des interfaces réseaux netifd.

Citer

Netifd will be able to manage even complex interface configurations with a mix of bonding, vlans, bridges, etc. and handle the dependencies between interfaces properly - and of course all that without adding unnecessary bloat.

N.S. : Il faudrait que je consulte le journal de mon routeur une fois qu'il sera opérationnel pour voir.

simon · « **Réponse #1153 le:** 05 avril 2025 à 12:21:13 »

Peut-être une race condition, mais certainement pas un dysfonctionnement, et encore moins majeur.
Les démons vont re-essayer ~une seconde plus tard et les paquets passeront.

À mon sens netifd ne fait que démarrer les interfaces et configurer les adresses statiques, puis lance les services nécessaires (odhcpd, udhcpc, pppd, etc.).
Vu que c'est le kernel qui configure les adresses link-local et qu'il y a une étape de duplicate address detection (DAD) avant qu'elles ne soient utilisables, je mettrait un billet sur le fait que netifd n'attend pas que ces adresses link-local soient opérationnelles avant de lancer les démons... mais encore une fois, ca n'a aucun impact à part un ou deux log messages.

ochbob · « **Réponse #1154 le:** 05 avril 2025 à 14:13:21 »

Citation de: basilix le 05 avril 2025 à 10:31:07

@ochbob :

Non, cela ne fonctionnait pas avec ifdown. Il faut débrancher la Livebox et attendre... avant de brancher le routeur.

C'etait bien ça !
J'ai vraiment coupé tous les flux pendant 1 grosse heure (le routeur / ONT quoi) et c'est bon j'ai recup mon IPV6 au reboot.

basilix · « **Réponse #1155 le:** 05 avril 2025 à 14:46:26 »

@ochbob : Génial !

@simon : Tu as peut être raison. Mais je considère que c'est un bogue inacceptable en l'état (protocole non respecté, voir potentiellement aberrant).

[17:27]

Cela est imposé par le RFC 6204 (remplacé par le RFC 7084).

Citer

odhcpd is a daemon for serving and relaying IP management protocols to configure clients and downstream routers. It tries to follow the RFC 6204 requirements for IPv6 home routers.

odhcpd provides server services for DHCP, RA, stateless SLAAC and stateful DHCPv6, prefix delegation and can be used to relay RA, DHCPv6 and NDP between routed (non-bridged) interfaces in case no delegated prefixes are available.

W-2: The IPv6 CE router MUST generate a link-local address and finish Duplicate Address Detection according to [RFC4862] prior to sending any Router Solicitations on the interface. The source address used in the subsequent Router Solicitation MUST be the link-local address on the WAN interface.

gg40530 · « **Réponse #1156 le:** 06 avril 2025 à 12:15:00 »

Petite question, pour remplacer ma livebox par un banana px r3 et un ONT SFP, je casse la bridge wan et applique la config directement sur la patte wan SFP ? ou j'applique la config sur le bridge wan ? Merci

basilix · « **Réponse #1157 le:** 06 avril 2025 à 12:45:58 »

gg40530 :

On peut imaginer son pont comme un commutateur disposant de trois ports. Le serveur DHCP Orange, le module optique du routeur et le port WAN.

Il faut effacer le pont et définir sa configuration sur l'interface physique du module optique.

simon · « **Réponse #1158 le:** 06 avril 2025 à 15:08:34 »

Citation de: basilix le 05 avril 2025 à 14:46:26

Cela est imposé par le RFC 6204 (remplacé par le RFC 7084).

W-2: The IPv6 CE router MUST generate a link-local address and finish Duplicate Address Detection according to [RFC4862] prior to sending any Router Solicitations on the interface. The source address used in the subsequent Router Solicitation MUST be the link-local address on the WAN interface.

Et c'est ce qu'il fait, vu que les requêtes ne peuvent être envoyées (c.f. message d'erreur, et le code path que tu as cité).

basilix · « **Réponse #1159 le:** 06 avril 2025 à 19:48:18 »

@simon :

Ce n'est pas ce que j'ai compris. Il ne devrait envoyer aucune sollicitation de routeur lorsqu'il n'y a pas d'adresse locale au lien.
Sinon, cela n'aurait aucun sens. Il faut générer une LLA et contrôler son unicité avant d'envoyer le message. Si ce n'est pas le
cas alors il semblerait que ce soit un bogue. Il aurait fallu rédiger un rapport pour voir ce qu'il en est. Si ce n'est pas primordial,
je m'en passerais bien. Je ne suis pas sûr que les développeurs de OpenWrt soient enclins à modifier ce code. J'avais lu que
le mainteneur actuel n'était plus joignable publiquement à un moment donné. Ils font un travail incroyable et ils ont une vie à
côté. Je suis un peu déçu (pas mal, en fait) qu'il soit aussi difficile de s'adapter à leur code. C'est pas fait pour les débutants.
Du coup, moi, pôve débutant, je suis réticent. Pourquoi aller se casser la tête ?

simon · « **Réponse #1160 le:** 07 avril 2025 à 07:38:58 »

Citer

Failed to send RS (Address not available)
Failed to send SOLICIT message to ff02::1:2 (Address not available)

odhcp6c n'a pas réussi à envoyer de RS/solicit car l'adresse n'était pas opérationnelle : il n'a donc rien envoyé sur son interface ethernet.
Il a tenté ceci dit, mais le kernel ne l'a pas laissé faire (c'est le kernel qui a le dernier mot, et il vérifie l'état des adresses). Donc tout va bien, la spec est respectée.

Une seconde après, le DAD est terminé, l'adresse est utilisable et les RS et DHCP solicit suivants passent.

J'ai bien peur que tu cherches un bug là où il n'y en a pas :-)
Alors OK. odhcp6c pourrait vérifier la présence et l'état des adresses link-local avant de tenter d'émettre, mais bon... à part ce message d'erreur temporaire, le comportement reste correct.

Citation de: basilix le 06 avril 2025 à 19:48:18

Je ne suis pas sûr que les développeurs de OpenWrt soient enclins à modifier ce code. J'avais lu que
le mainteneur actuel n'était plus joignable publiquement à un moment donné. Ils font un travail incroyable et ils ont une vie à
côté. Je suis un peu déçu (pas mal, en fait) qu'il soit aussi difficile de s'adapter à leur code. C'est pas fait pour les débutants.
Du coup, moi, pôve débutant, je suis réticent. Pourquoi aller se casser la tête ?

J'ai déjà fait quelques patches par le passé qui ont été acceptés (dans 6relayd à en croire github, le prédécesseur d'odhcd). Ils sont même assez réactifs quand il y a un bug.
Mais vraiment, quitte à me répéter, là, il n'y a pas de bug et tout fonctionne bien.

Si vraiment tu veux en avoir le coeur net, il faudrait sniffer les trames qui sortent côté WAN : voit-on des RS ou requêtes DHCPv6 avant la fin du DAD (émission des neighbor solicitations avec :: comme adresse source, pour l'adresse link-local du routeur) ?

kgersen · « **Réponse #1161 le:** 07 avril 2025 à 08:52:23 »

oui c'est une pratique usuel qu'un service se plante si ses conditions opérationnelles ne sont pas remplies.
Cela évite un code trop compliqué qui prévoirait tous les cas possibles et cela permet de gérer le problème en dehors du code lui même.
Dans le cas présent, si la LL n'est pas dispo, combien de temps ou de tentatives la code devrait attendre ? Pour spécifier cela suivant son cas perso il faudrait des options en plus, etc bref de la complexité pour rien.

Usuellement c'est le gestionnaire de service (init.d/rc ou systemd) ou un script spécifique qui s'occupe de relancer un service en erreur ou d'établir une dépendance au démarrage. C'est fait pour cela, c'est la qu'on gère les délais et nombres de tentatives, etc

"C'est pas fait pour les débutants": non clairement. a lire le code qui n'a aucun commentaire et est assez abscons ce n'est pas fait pour les débutants. Certes openwrt date et les pratiques de l'époque étaient différente mais le code est quand assez 'horrible' et difficile a maintenir (c'est bien sur que mon avis, d'autres diront que c'est des génies qui ont "pondu" ce code).

OpenWrt de base a l'origine c'était pour des routeurs ayant peu de ressources mémoire et cpu. C'est moins necessaire de nos jours et l'ajout des nombreux paquets au fil du temps permet de palier aux déficiences du code de base.

basilix · « **Réponse #1162 le:** 07 avril 2025 à 08:53:09 »

@simon :

Ce que je dis est un peu monté en épingle. Néanmoins, la barre aurait pu être placé plus bas sous forme d'indications ou de la documentation.
OpenWrt est un projet de développement logiciel important. Avec les Copyrights (des APIs), on voit qu'il y a des contributeurs principaux. Donc,
mon avis est que c'est moins accessible. Cela est vrai dans l'ensemble. Leur documentation n'est intelligible qu'avec des connaissances en
réseautique.

simon · « **Réponse #1163 le:** 07 avril 2025 à 09:41:12 »

Citation de: kgersen le 07 avril 2025 à 08:52:23

oui c'est une pratique usuel qu'un service se plante si ses conditions opérationnelles ne sont pas remplies.
Cela évite un code trop compliqué qui prévoirait tous les cas possibles et cela permet de gérer le problème en dehors du code lui même.
Dans le cas présent, si la LL n'est pas dispo, combien de temps ou de tentatives la code devrait attendre ? Pour spécifier cela suivant son cas perso il faudrait des options en plus, etc bref de la complexité pour rien.

Il ne se plante pas, l'envoi du paquet échoue et provoque une erreur. Le même process recommence une seconde plus tard, tout se passe bien (le message n'est affiché qu'une fois d'après mes logs).

Citation de: kgersen le 07 avril 2025 à 08:52:23

OpenWrt de base a l'origine c'était pour des routeurs ayant peu de ressources mémoire et cpu. C'est moins necessaire de nos jours et l'ajout des nombreux paquets au fil du temps permet de palier aux déficiences du code de base.

Il y a encore pas mal de routeurs supportés qui n'ont que 8MB de flash (cas de mon TP-Link archer c7, qui me sert d'AP). L'image de base doit donc rentrer dans 8MB et laisser de la place pour des paquets supplémentaires et la conf, c'est assez étroit avec un kernel qui fait environ 3MB compressé.

Citation de: basilix le 07 avril 2025 à 08:53:09

Leur documentation n'est intelligible qu'avec des connaissances en réseautique.

On peut penser qu'en effet, pour coder des services réseaux, une base de connaissance et d'expérience solide en réseau est importante.