Voilà quelques temps que je n'était pas revenu sur ce thread.

Je profite d'avoir passé mes appareils sous la  23.05.0 et modifié mon install pour vous faire par de ma dernière trouvaille (tldr en fin de post):

Pour commencer, offre orange 500/500 (moins cher, suffisant margres mon utilisation intensive, et surtout c'etait le seul moyen que j'avait à l'epoque d'avoir un ONT de la part d'orange.)

Setup de base
ONT orange => Raspberry  Pi4 => Edgerouter X SFP => Tout mon bordel.

Setup voulut
ONT GPON-ONU-34-20BI de chez FS.com => Edgerouter X SFP => toujours le même bordel

La raison étant de sortir le Pi 4, l'ERX-SFP  étant largement suffisant pour le moment (peu de bufferbloat avec hardware offloading et il me sature 500/500) et me sortir la dernière pièce d'équipement d'orange (mis à part le décodeur)

Déplacement de config/vlans/firewall sans soucis, ONT GPON-ONU-34-20BI reconnu par l'ER-XSFP (mes recherches m'ont permit de trouvé que depuis un merge d'openwrt il n'y a plus besoins de hacker (pont de soudure) les modules SFP pour bypasser l'auto négociation).

Le problème m'ayant fait perdre le plus de temps a été de récupérer les VLANs sur l'ONT:
Je lui avait rentré le numéro de série de l'ONT d'orange ainsi que le hardwareversion. Il s'autentifiait bien auprès de l'OLT mais j'avais aucune VLAN d'orange (832/835/840/etc...).
Passé deux heures d'acharnement et proche de l'abandon j'ai tenté de rentrer un  hardwareversion de l'ONT d'une livebox5 trouvé sur le net et PAF ça fonctionne!

Il va falloir m'expliquer comment l'ONT s'identifie auprès de l'OLT avec d'une part un numéro de série d'un ONT Huawei et de l'autre une harwareversion d'un ONT Sagemcom n'étant même pas le mien...

Dans les logs je vois que l'ER-X-SFP donne 1W au module qui apparemment nécessite 2.2W d'après FS.com, mais il à l'air de fonctionné correctement.

tldr: Module ONT GPON-ONU-34-20BI de chez FS.com dans Edgerouter X SFP en openwrt 23.05.0: ça fonctionne!

Encore un gros merci à Ubune et à vous tous dont vos posts m'on bien aidé !

Bonjour à tous,
Pour partager mon expérience. Cette nuit mon routeur OpenWRT a perdu plusieurs fois sa connexion. Ce matin,  après un reboot, l'accès internet fonctionnait via ipv4 pendant 5 min environ puis stoppait jusqu'au prochain reboot.
J'ai rebranché ma livebox (v4) sur l'ONT et elle a fait plusieurs mises à jour successives. Cela faisait probablement plus d'un an qu'elle n'avait pas été branchée. J'ai ensuite rebranché le routeur OpenWRT directement sur l'ONT et depuis la connexion semble stable. Peut-etre une façon pour Orange de forcer une mise à jour sur les livebox ?

Bonjour !

La configuration du pare-feu en IPv6 pour l'échange de messages DHCPv6 me paraît problématique.

config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'wan6'
list src_ip 'fc00::/6'
list dest_ip 'fc00::/6'

On peut comparer avec l'exemple de configuration du Wiki OpenWrt.

config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option name 'Allow DHCPv6 replies'
        option family 'ipv6'
        option src_port '547'

La documentation n'est pas toujours très claire. On constate qu'on peut utiliser la notation CIDR en IPv4 dans l'option src_ip pour spécifier à la place un préfixe.
On a aussi la fonctionnalité « ensemble IP » (ipset).

Quoiqu'il en soit, la configuration dans ce tutoriel me semble erronée. Je n'ai pas vu mentionné quelque part l'option list src_ip ou list dest_ip dans la documentation.

De même, le filtrage par adresse IP source / destination ne me paraît pas cohérent avec le RFC 8415.

Clients and servers exchange DHCP messages using UDP (see [RFC768] and BCP 145 [RFC8085]). The client uses a link-local address or
addresses determined through other mechanisms for transmitting and receiving DHCP messages.

A DHCP client sends most messages using a reserved, link-scoped multicast destination address so that the client need not be
configured with the address or addresses of DHCP servers.

Dans le tutoriel de cyayon « Use | Bring Your Own Router Orange ISP », on retrouve également le préfixe fe00::/7 pour définir la COS6 (pour ICMPv6).

fe00::/7 == fe80::/10 + ff02::/16

fc00::/6 == fc00::/7 (ULA) + fe00::/7

Mais le type d'adresses IPv6 (ULA, lien-local, multicast) n'est plus vraiment dissocié par rapport au préfixe.

Hello,

J'ai remarqué que j'avais un souci au bout de 7 jours exactement.

Mon bail IPv6 est released mais n'est pas renouvelé sur l'interface et j'ai des erreurs qui apparaissent dans les logs.

Redémarrer l'interface ne résout pas le problème, il faut que je reboot le routeur.
Je n'ai pas essayé d'autre choses plus "fines" entre les deux, comme redémarrer certains services.

Voilà le log au moment où ça se passe :

Fri Feb 23 07:41:53 2024 daemon.notice netifd: wan4 (3438): udhcpc: sending renew to server 80.xxxxxxxx
Fri Feb 23 07:41:53 2024 daemon.notice netifd: wan4 (3438): udhcpc: lease of 86.xxxxxx obtained from 80.xxxxxx, lease time 604800
Fri Feb 23 07:41:56 2024 daemon.notice ttyd[5976]: [2024/02/23 07:41:56:7822] N: rops_handle_POLLIN_netlink: DELADDR
Fri Feb 23 07:41:56 2024 daemon.info avahi-daemon[3939]: Withdrawing address record for 2a01:xxxxxxxxxx::bad on br-lan.
Fri Feb 23 07:41:57 2024 daemon.warn odhcpd[1718]: A default route is present but there is no public prefix on lan thus we don't announce a default route by overriding ra_lifetime!
x 11
Fri Feb 23 07:42:36 2024 daemon.notice netifd: Interface 'wan6' has lost the connection
Fri Feb 23 07:42:36 2024 user.notice root: stopping ntpclient
Fri Feb 23 07:42:37 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:43:49 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:43:59 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:44:00 2024 daemon.err nlbwmon[8867]: Netlink receive failure: Out of memory
Fri Feb 23 07:44:00 2024 daemon.err nlbwmon[8867]: Unable to dump conntrack: No buffer space available
Fri Feb 23 07:45:00 2024 cron.err crond[1779]: USER root pid 12329 cmd /etc/checknftrules.sh
Fri Feb 23 07:47:49 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Fri Feb 23 07:47:50 2024 daemon.warn odhcpd[1718]: No default route present, overriding ra_lifetime!
Ma config :
config interface 'wan6'
option proto 'dhcpv6'
option device 'eth0.832'
option reqprefix 'auto'
option defaultreqopts '0'
option sendopts '11:xxxxxxxxxx
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid 'xxxxxxxx'
option reqaddress 'none'
option peerdns '0'
list dns 'xxxxxxx:8921'
list dns '2606:4700:4700::1111'
Est-ce que vous avez une idée du problème ? J'aimerais éviter faire une crontab qui reboot tous les 6 jours, c'est plutôt moche.

Bonjour ! @ubune

Il est très important de mentionner l'ONT et de préciser son rôle dans les pré-requis. Cela peut conditionner ses choix et permettre éventuellement
de faire une mise en adéquation avec ses attentes.

• Le routeur ne dispose pas de cage SFP ou SFP+.
  
• L'ONT et le routeur peuvent malheureusement s'avérer être incompatibles.
• L'utilisateur peut s'avérer dans l'incapacité de paramétrer correctement l'ONT.
  
• ...

Je pense plutôt qu'il faut dissocier l'explication/choix de l'ONT du tuto. Certains possedent encore l'ont d'orange par exemple.
Je vais juste mettre une remarque sur le fait qu'il doit être déjà present/synchro.
Comme tu le dis, OpenWrt peut être installé sur pleins de modèle/types de routeurs. Tu peux avoir un routeur avec des ports SFP/SFP+ ou uniquement des ports Ethernet, par exemple. C'est donc plutôt le choix du routeur qui déterminera la solution la plus logique du côté de l'ONT. Ou le choix de l'ONT si le routeur a déjà été acheté...

ce qui est plutôt curieux dans ton cas c'est de ne voir aucun match en dhcp (ipv4), et pourtant ça fonctionne.

Le fait de perdre ipv6 a chaque fin de bail c'est systématique ou aléatoire ?
Peux-tu vérifier cette fois que la rule qui permet le flux udp port 546 a également "match" ?
histoire d'être sûr que le routeur n'a pas drop (fw) la réponse d'orange lors du renew.

Exemple :