Auteur Sujet: Le meilleur routeur OpenWRT pour la fibre B&YOU Pure Plus 8/1 Gb (Lu 32262 fois)

rooot · « **Réponse #288 le:** 06 juillet 2026 à 17:50:44 »

on est concerné par ce bug avec le HW 1.1 ?
moi j'ai plus rien touché depuis la version du 16-05-2026 ou tout fonctionnait parfaitement. je suis sur le kernel d'avant 6.18.

typhoe · « **Réponse #289 le:** 06 juillet 2026 à 17:55:54 »

Moi sur les dernières versions, mes devices arrivent pas à obtenir une ip (pb dhcp sur les vlan ?) et je reviens à chaque fois sur une version du 18 juin qui marche.
FW 1.1 et ipv4 uniquement, l'ipv6 j'ai jamais réussi à configurer mon reseaux et mes vlan comme voulu avec.

rooot · « **Réponse #290 le:** 06 juillet 2026 à 19:31:23 »

Si tu veux ma version de Fanboy du 16/05/2026 :
https://www.swisstransfer.com/d/227bec68-4dae-4ed7-a50f-33fbcc76cfc5
ipv4 et ipv6 tout marche correctement chez moi, après je fais rien de compliqué non plus...

typhoe · « **Réponse #291 le:** 06 juillet 2026 à 20:16:25 »

Merci @rooot, je l'ai mise de coté au cas où, mais avec celle du 18 juin, je n'ai pas noté de pb pour moi non plus.

Oxynux · « **Réponse #292 le:** 09 juillet 2026 à 16:04:44 »

Pour savoir qui est réellement touché par le bug IPv6 + hardware offload/PPE du W1700K, il faudrait des tests comparables.

Conditions idéales :
- PC branché directement au port LAN 10G du W1700K
- carte réseau PC en 2.5G minimum, idéalement 5G/10G
- pas de Wi-Fi pour ce test
- même PC pour IPv4 et IPv6
- hardware flow offload activé
- idéalement règle fw4 normale IPv4+IPv6, pas le workaround IPv4-only

Test sur https://www.nperf.com/ :
1. Faire un test IPv6 sur le serveur :
[FR] Anycast-FR - 10 Gb/s - Bouygues Telecom, version IPv6
2. Refaire le même test en IPv4 sur la version IPv4 du même serveur.

Merci d’indiquer :
- révision W1700K : HW1.0 / HW1.1 / HW2.1
- build OpenWrt utilisé
- débit nPerf IPv4
- débit nPerf IPv6
- si l’IPv6 freeze, démarre puis tombe à zéro, ou reste stable

Commandes utiles sur le routeur :

Code: [Sélectionner]

uci show firewall | grep -E 'flow_offloading|flow_offloading_hw'

Ça sert à vérifier si le flow offload logiciel et le hardware offload sont activés.

Code: [Sélectionner]

nft -a list chain inet fw4 forward | grep 'flow .*@ft'

Ça sert à voir quelle règle fw4 est réellement active :
- meta l4proto { tcp, udp } flow add @ft = IPv4 + IPv6 peuvent partir en hardware offload
- meta nfproto ipv4 meta l4proto { tcp, udp } flow add @ft = workaround IPv4-only actif, IPv6 reste en software

En complément de nPerf, si possible faire un test curl depuis le même PC :

IPv6 :

Code: [Sélectionner]

curl -6 -L -o /dev/null -w "IPv6: %{speed_download} bytes/s, total=%{time_total}s\n" http://scaleway.testdebit.info/10G.iso

IPv4 :

Code: [Sélectionner]

curl -4 -L -o /dev/null -w "IPv4: %{speed_download} bytes/s, total=%{time_total}s\n" http://scaleway.testdebit.info/10G.iso

Sur Bouygues, on est normalement tous en WAN VLAN 100 avec DHCPv6-PD /60, mais si votre config diffère, précisez-le.

Sinon le protocole de debug plus détaillé est ici sur Github (si jamais vous pouvez poster les logs de son script pour aider Gilly) :
Le thread : https://github.com/orgs/w1700k/discussions/18#discussioncomment-17541723
Le script : https://github.com/Gilly1970/Gemtek-W1700K-6.18/blob/main/openwrt-patches/ppe-v6-diag.sh

hwti · « **Réponse #293 le:** **Aujourd'hui** à 01:25:12 »

Citation de: hwti le 06 juillet 2026 à 12:04:07

Sinon pour ce qui est de l'accélération, un dev a soumis les patchs upstream, et l'approche nf_call_iptables a été rejetée.
L'idée serait plus d'ajouter le support des bridges au code "flow offload" : il y a d'anciens patchs soumis mais non intégrés qui ont été évoqués, et le mainteneur netfilter a dit qu'il allait travailler sur le sujet.
Donc maintenant :
- les dernières builds de Fanboy ont une variante "no br-netfilter" du patch (retravaillé par IA), mais je ne suis pas sûr de l'intérêt
- il y a https://github.com/openwrt/openwrt/pull/24038, qui est basée sur les patchs soumis upstream évoqués

Les builds de Fanboy sont revenues à la version d'origine du patch (PR22533 retravaillée pour le kernel 6.18).
J'ai testé les patchs de la PR24038, et pour moi ça fonctionne, y compris l'auto-réflection sur les port forwards (le fait de pouvoir accéder à IP_PUBLIQUE:PORT y compris depuis la machine vers laquelle le port est redirigé) qui était cassée par le nf_call_iptables des patchs PR22533.