@unipo :

Recopier la configuration est efficace, mais ce n'est pas la méthode recommandée. Il aurait idéalement fallu aller un cran plus loin.
Car cela inclut les erreurs éventuelles et redéfinit également certaines valeurs par défaut.

You could use meta l4proto to match on the transport protocol (ie. TCP, UDP, ICMPv6,...), this is walking down the headers until the real transport protocol is found.

If you specifically want to match on the ICMPv6 type, then nftables creates an implicit meta l4proto dependency that is not shown, therefore, there is no need for being verbose in your notation, ie.

Code: [Sélectionner]

% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
works fine to accept all ICMPv6 traffic regardless any possible extension headers.

Hyperlink: Matching IPv6 headers

Exemple d'erreur dans la configuration

nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6

nft add rule inet fw4 mangle_postrouting oifname "eth0.832" meta l4proto ipv6-icmp counter meta priority set 0:6


Code: [Sélectionner]

l4proto <protocol>

Protocol numbers assigned by IANA

Bonjour,

Je poste un nouveau sujet plutôt que de remonter le fil "Firmware LB7W7" pour décrire un problème précis, mesuré, et voir qui est dans le même cas. Je résume d'abord les faits, ensuite l'hypothèse.

Matériel et contexte

• Livebox 7 "W7" (Sagemcom F@st 5698), firmware SGW7-fr-G03.R08.C03_00, XGS-PON.
• Lien optique parfait : Rx -18,5 dBm, 0 erreur, ONT en O5, identique avant et après les incidents.
• Wi-Fi maison assuré par un mesh Netgear Orbi (RBR350 + 2 RBS350) en mode point d'accès, backhaul Wi-Fi, branché sur un port Ethernet de la box. Wi-Fi de la Livebox inutilisé.
• La box a déjà été échangée deux fois par Orange (deux Livebox 7 neuves) : problème strictement identique. Le RAZ usine ne change rien non plus.

Symptômes

• Redémarrage spontané toutes les 2 h 20 à 2 h 30 environ, jour et nuit. L'historique interne de la box donne à chaque fois BootReason = "Oops" (plantage noyau), sans arrêt propre. Compteur de boots passé de 47 à 66 en quelques jours.
• Variante pire : la box "gèle" au lieu de rebooter. DNS, interface web et API morts, mais le routage IP continue (0 ping perdu vers l'extérieur). Parfois elle finit par rebooter seule après 10-20 min, parfois il faut la débrancher (55 min de gel constaté).

Ce que j'ai mesuré
J'interroge l'API interne de la box (celle du webui) toutes les 10 s depuis un PC : mémoire libre, uptime, événements, DNS.

• Fuite mémoire linéaire : la mémoire libre passe de ~1 200 Mo après boot à moins de 40 Mo, à 5-10 Mo/min selon les moments. À ~40 Mo le DNS de la box meurt, puis l'API, puis Oops et reboot. Période = 1 200 Mo / pente = les 2 h 30 observées. C'est reproductible cycle après cycle, une nuit entière.
• La fuite n'a lieu que quand les appareils du foyer sont présents (téléphones Apple sur le mesh). Maison vide 46 h : mémoire stable à 1 240 Mo, zéro plantage. Retour des habitants : plantage 2 h 15 plus tard.
• Tempête d'événements de topologie : le canal d'événements de la box débite ~2 000 événements/min en permanence. Ce sont tous du même type : la box s'enregistre elle-même comme "fille" de l'un des deux satellites Orbi, puis de l'autre, plusieurs fois par seconde (add/delete de son propre lien amont). CPU de la box à 45-60 % au repos.

Ce que montre l'API sur le mesh

• Les trois nœuds Orbi sont découverts par la box via IEEE 1905.1 (EasyMesh), tagués "ieee1905 almac", pas via DHCP.
• La box n'est pas un simple observateur : elle est un agent 1905 actif, avec sa propre adresse d'agent (02:00:00:xx:xx:xx). Le routeur Orbi la liste dans sa table de voisins 1905 au même titre que ses satellites (lien Ethernet, drapeau pont 802.1).
• Il n'existe aucun réglage, ni dans l'interface ni dans l'API (même en cherchant les objets cachés), pour désactiver ce contrôleur EasyMesh. Couper le Wi-Fi de la box ne change rien : l'agent 1905 est accroché au pont LAN, pas aux radios.

Pourquoi c'est conçu comme ça (et pourquoi c'est un problème)
La Livebox est faite pour qu'un client branche un "Répéteur Wi-Fi 6" Orange sans rien configurer. Le contrôleur EasyMesh tourne donc en permanence, sans interrupteur, et l'interface prévoit même le cas "Wi-Fi de la box éteint, répéteurs allumés". Le présupposé est que tout agent 1905 vu sur le câble est un répéteur Orange. La box ne filtre ni par constructeur ni par certification. Avec un mesh tiers certifié EasyMesh (Orbi, mais aussi Deco, certains Cudy, etc.), on se retrouve avec deux contrôleurs sur le même réseau, et la box se laisse déclarer voisine par les satellites d'un mesh qui n'est pas le sien, en boucle.

Ce que je ne prétends pas
La tempête de topologie a le même débit avec ou sans fuite (elle tourne aussi pendant les 46 h de calme). Elle n'est donc pas, à elle seule, la cause de la fuite. Mon hypothèse est que la fuite est dans le même composant (gestion topologie / appareils) et qu'elle est déclenchée par le va-et-vient des clients Apple entre les nœuds du mesh, tel que rapporté par le 1905. Je vais le tester en supprimant physiquement les trames 1905 (point d'accès sans EasyMesh, puis switch manageable avec ACL sur l'EtherType 0x893A entre box et Orbi). Je posterai le résultat ici.

Mes questions

• Qui a une Livebox 7 (ou 6) avec un mesh tiers (Orbi, Deco, eero, Google, Cudy...) et des reboots "Oops" ou des gels à intervalle régulier ? Et à l'inverse, qui a un mesh tiers et zéro problème ? Le modèle et le mode (routeur ou point d'accès) m'intéressent.
• Quelqu'un connaît-il un moyen de désactiver le contrôleur EasyMesh / 1905 de la Livebox 7 ?
• Un retour d'Orange ou de Sagemcom sur ce firmware ? J'ai un dossier complet (courbes mémoire, historique de boots, table de voisins 1905) prêt à être transmis à l'expert Orange, je peux le partager... mais le sav niveau 1 a escaladé chez orange... j'attend sque orange me contacte ... à voir si ils ne ferton, en attendant ma box plante environ toutes les 2 à 3 heures...

Merci d'avance.

Hello,
De mon coté, je suis toujours sur un firmware de debug, des problèmes sur le HW 2.1 d’accélération materiel d'IPV6, resolu dans ce firmware, je sais pas si sa a été mergé, j'ose pas bouger de firmware a nouveau, surtout que je suis pas a la maison avant fin octobre

la deuxième image c'est si tu as un appareil en aval qui demande une délégation de préfixe à la LB pour pouvoir fournir des adresses à d'autres appareils.

Normalement, tu seras contacté pour passer en PON. C'est automatique, mais je n'ai pas su savoir le délai moyen. Il y a quelqu'un sur Bagnolet qui était dans le même cas et qui a eu un rendez-vous pour ça.