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

basilix · « **Réponse #972 le:** 27 mai 2024 à 11:44:25 »

@Emilic : Je ne pense pas que cela soit incorrect (c.f. nftables Scripting).

Emilic · « **Réponse #973 le:** 27 mai 2024 à 14:46:04 »

Citation de: basilix le 27 mai 2024 à 11:44:25

@Emilic : Je ne pense pas que cela soit incorrect (c.f. nftables Scripting).

Merci, peut etre c'est mon 90 qui mrde....
Je recommence de 0, peut etre j'ai eu un erreur de frappe dans la config...

Fibroberto · « **Réponse #974 le:** 28 mai 2024 à 21:39:28 »

Hello à tous

Petite question. J'ai une config openwrt qui marche très bien depuis plusieurs années à la fois en IPv4 et IPv6. Depuis quelques mois (disons 3 mois), j'ai de temps en temps une coupure, à la fois en IPv4 et en IPv6, qui arrive rarement (disons une fois par mois), mais qui est pénible parce que je change d'IP quasiment à chaque fois. En faisant un redémarrage du réseau ça repart (avec une nouvelle IPv4 et un nouveau préfix IPv6).
Le coupure se produit la nuit ou en journée. Dans les logs j'ai rien de bien utile à part ça qui revient en boucle :
daemon.warn odhcpd[1221]: No default route present, overriding ra_lifetime!
Je me demande si c'est normal, si ça arrive à tout le monde suite à des manips réseau d'orange, ou si j'ai une subtilité pas bonne dans ma config. Comme je change d'IP (surtout le préfix IPv6) à chaque fois ça m'oblige à remodifier du DNS, et les sites des banques sont lourds quand tu te connectes avec une nouvelle IP qu'ils ne connaissent pas.

Merci !

basilix · « **Réponse #975 le:** 29 mai 2024 à 11:08:03 »

@Fibroberto : Il faudrait être un peu plus explicite (c'est trop vague).

Redémarrage manuel ou automatique ?
Coupure de courant ou arrêt inattendu d'une session DHCP ?

Code: [Sélectionner]

daemon.warn odhcpd[1221]: No default route present, overriding ra_lifetime!
Il y a peut-être des informations utiles sur la page Wiki « DHCP client scripts » ou sur la page « Hotplug ».

Voire éventuellement sur le fil de discussion « Loosing IPv6 upstream after 30 minutes » (forum OpenWrt).

Citation de: Fibroberto

Cela m'oblige à modifier les enregistrements DNS à chaque fois.

Aah. Moi, je prévois de les actualiser par DHCP. D'ailleurs, je ne sais pas si c'est très sécurisé.

fatpat · « **Réponse #976 le:** 29 mai 2024 à 11:15:52 »

Citation de: Fibroberto le 28 mai 2024 à 21:39:28

daemon.warn odhcpd[1221]: No default route present, overriding ra_lifetime!

j'ai ce message aussi sur un network restart. c'est transitoire. C'est le serveur dhcp (donc côté LAN) qui n'a plus de route par défaut (normal vu qu'il y a restart en cours). Donc pas d'inquiétude à ce niveau là.

si tu as des pertes de connexions, ça doit certainement être lié aux options des clients DHCP v4 et v6 côté wan. Si ça fonctionnait très bien avant c'est possible qu'il y ait eu des migrations sur les équipements côté opérateur qui rende les vérifications protocolaires plus strictes.

partage ta version d'openwrt ainsi que tes confs /etc/config/* relatives à la connexion WAN. Si jamais on voit un truc

Fibroberto · « **Réponse #977 le:** 29 mai 2024 à 11:41:11 »

En fait mon soucis ne vient pas je pense d'une vérification protocolaire (j'avais mis à jour à l'époque). Tout marche correctement pendant plusieurs semaines (renew DHCP & co, ipv4/ipv6), mais de temps en temps, genre 3 fois depuis peut-être les 3 derniers mois je perds la connexion. Le routeur tourne toujours (pas de coupure de courant il est sur onduleur), les status wan4 et wan6 disent que c'est toujours connecté (avec mon "ancienne" ipv4/préfix), par contre plus rien ne passe (les pings ne passent plus). Dans les logs j'ai pas grand chose comme info à part le warning d'odhcpd.
Si je fais un /etc/init.d/network restart je retrouve la connexion mais j'ai changé d'IPv4/Préfix 2 fois sur les 3 dernieres fois.

J'ai vu sur le post de la conformité protocolaire cette partie :

Citer

De l'importance des tests de vie :
La cnx de la LB peut être interrompue sur plusieurs segments entre la LB et le BNG.
Si vous ne testez pas la cnx montante, vous allez vous retrouver hors séquence et donc vous faire blaster régulièrement.

Je n'ai effectivement aucun test que la connexion est toujours up, mais j'avoue que je n'ai pas compris la suite

Ceci étant ces problèmes sont "récents" (moins de 3 mois), j'arrivais avant à avoir une connexion stable sur plusieurs mois. Je me demandais si j'étais le seul à avoir ce problème.

basilix · « **Réponse #978 le:** 29 mai 2024 à 11:42:24 »

@fatpat :

Cela doit être géré automatiquement par les processus (voir RFC 8415).

Citer

If the client uses a delegated prefix to configure addresses on interfaces on itself or other nodes behind it, the preferred and valid lifetimes of those addresses MUST be no longer than the remaining preferred and valid lifetimes, respectively, for the delegated prefix at any time. In particular, if the delegated prefix or a prefix derived from it is advertised for stateless address autoconfiguration [RFC4862], the advertised preferred and valid lifetimes MUST NOT exceed the corresponding remaining lifetimes of the delegated prefix.

Cela fait partie intégrante du processus de « renouvellement » d'adresse.

basilix · « **Réponse #979 le:** 30 mai 2024 à 08:16:23 »

@fibroberto @fatpat :

J'ai cherché dans les sources Shell (trop complexe). Faire une capture réseau et observer les transactions DHCP de la Livebox me semble le plus direct.
Je trouve que rechercher n'importe où n'est pas vraiment efficace. Il manque de la documentation pour exposer le fonctionnement du système. À suivre.

Fibroberto · « **Réponse #980 le:** 31 mai 2024 à 08:25:15 »

Oui je pense que la vraie solution serait de regarder ce que fait exactement la livebox dans ce cas (et probablement régulièrement pour le test de vie), mais bon compliqué à mettre en place. En attendant je vais me résoudre à soit accepter de perdre la connexion tous les 36 du mois, soit mettre en place un ping dans un cron qui restart le réseau si pas de réponse (mais bon je trouve ça moche

.

Emilic · « **Réponse #981 le:** 31 mai 2024 à 13:04:25 »

Bon, Ca marche !!

BPI-r4 avec Openwrt snapshot 24.xx les networks settings partage ici.
Il faut juste ajouter les packages Luci (pour avoir une jolie interphase, et uci) et ip-full pour gerer les configs...

Je ne suis pas sur que j'ai optimise parce que mon premier test me donne une vitesse pas terrible terrible... mais j'envoi cette message depuis l'internet de mon BPI-r4 avec le SFP shosh.

Edit.. .c'est bon je suis au 100% de ma vitesse sosh... 300mb/s, j'avais oublie que j'avais un vpn active dans mon pc... ^^

basilix · « **Réponse #982 le:** 02 juin 2024 à 19:13:35 »

@Fibroberto :

Je me suis trompé à propos du client DHCP.

Dans le fichier dhcp.sh, à la ligne de commande invoquant udhcpc, il y figure l'argument -s dhcp.script définit par OpenWrt.

Code: (/lib/netifd/proto/dhcp.sh) [Sélectionner]

proto_run_command "$config" udhcpc \
        -p /var/run/udhcpc-$iface.pid \
        -s /lib/netifd/dhcp.script \
        -f -t 0 -i "$iface" \
        ${ipaddr:+-r ${ipaddr/\/*/}} \
        ${hostname:+-x "hostname:$hostname"} \
        ${vendorid:+-V "$vendorid"} \
        $clientid $defaultreqopts $broadcast $norelease $dhcpopts

Le fichier dhcp.sh définit le gestionnaire de protocole DHCP lancé dans l'environnement par netifd à son démarrage. Il semblerait que ce soit une abstraction
du paramétrage (qui est défini dans la configuration UCI) lors du lancement du client DHCP. Le fichier dhcp.script permet d'exploiter les paramètres renvoyés
par le client DHCP et d'initialiser la connexion réseau (c.f. README.udhcp).

Conclusion : il se pourrait qu'il faille simplement actualiser la route avec l'un des scripts proposés sur le Wiki.

Jojolejobar · « **Réponse #983 le:** 06 juin 2024 à 15:45:51 »

@Emilic bonjour,

Je vois que tu as un BPI-R4. J’en ai un aussi je suis arriver à le configurer avec un GPON de chez FS.com. J’ai désormais internet sans livebox en IPv4 et IPv6. Merci à ceux qui on participé au tuto

Par contre j’ai un problème j’ai des performances nulles (en upload uniquement lan->r4, en download tout va bien) sur le LAN vers le BPI-R4, environ 100Mbit/s alors que si je désactive l’auto négociation ou si je reset mon R4 je me retrouve bien avec le 1Gbit/s.

Du coup je me demandais si t’avais le problème ou si quelqu’un l’avait eu ?