Je rencontre un soucis de déconnexion au bout d'environ 20h, avec un Turris Omnia sous openwrt.
Ma configuration a fonctionné plus de 2 ans. j'ai demandé à changer d'abonnement internet auprès d'Orange qui nous a renvoyé une LB5 en remplacement de la LB3, en même temps mon turris est monté en version 7, comme la LB5 a été activé avec l'ONT intégré, j'ai acquis un ONT Leox.
Bref en peu de temps je suis passé d'un Turris sous Turris OS 6, avec ONT Orange à Turris OS7 (openwrt 22.03), avec ONT Leox, un abonnement LB3 à LB5.
Après modif de la conf du turris pour adapter les options MAC, DUID, authentification, j'obtiens bien une ip v4 et un subnet v6.
Je positionne bien la COS6 sur les trames ARP, icmp, igmp, dhcp.
Et là patatra, au bout d'une vingtaine d'heure, je perds la connexion avec Orange, je ne trouve rien dans les logs du Turris, du coup je ne sais pas trop où chercher.
Je me reconnecte en relançant les interfaces WAN au travers de le interface Luci
Une de mes hypothèse est qu'Orange, me jette, paske je lui balance de la m...., dans quels cas cela pourrait-il se produire ? Une idée d'où monter des traces sur openwrt ?
Ma conf est là https://www.framboisier.com/blog/2022/05/28/remplacement-de-ma-livebox-par-un-turris-omnia-sous-openwrt/

Savoir exactement ce qui se produit au moment où le client DHCP perd son bail aiderait sûrement.

Je ne sais pas encore comment le faire car je n'y ais pas réfléchi suffisamment. Je pense qu'il faudrait voir comment le client DHCP gère son état.
Le client DHCP (udhcpc ou odhcp6c) permet de notifier un changement d'état et lancer un script Shell. Il y a aussi Hotplug. Je suppose qu'il existe
un moyen de connaitre l'état du client en écrivant un script. Il y a plusieurs mois j'avais lu le RFC 8415 pour découvrir le fonctionnement de DHCPv6.
J'ai partiellement lu le RFC 2131 pour me permettre d'implémenter des options DHCP dans le serveur DHCPv4 odhcpd. En bref, je ne me souviens
plus vraiment de la façon dont les échanges de messages DHCP se font. À mon avis, c'est la clé du problème.

---

Remarque

Je retranscris ici le message que j'avais initialement publié, en réponse, dans le fil de discussion « Orange Conformité Protocolaire ».

@MarcFramboisier :

Je suis "bloqué" dans le même état avec OpenWrt. Pour faire simple, ma connexion IPv6 ne fonctionnait plus après un laps de temps et je ne sais pas
comment déterminer l'origine de la panne. Dans son tutoriel OpenWrt, @ubune teste régulièrement l'état de sa connectivité et relance le routeur en cas
de rupture de la connexion (c'est ce que rapporte de faire @levieuxatorange). Moi, je ne faisais rien. Dans la documentation OpenWrt, j'ai l'impression
qu'on indique le minimum pour rechercher la défaillance, à savoir, relancer la connexion et observer le trafic (ifdown / ifup...).

Remarque

OpenWrt est basé sur firewall4 ou fw4. On peut potentiellement appliquer le PCP et le DSCP des paquets en utilisant des règles nftables.
Je n'y suis pas arrivé avec OpenWrt mais il se pourrait que je m'y sois pris comme un manche. Hotplug pourrait éventuellement le faire ?
Néanmoins, un problème potentiel est que la version stable de OpenWrt ne dispose pas d'un noyau suffisamment récent. Par conséquent,
j'ai finis par procéder différemment : installation d'un correctif pour fixer la priorité dans udhcpc (BusyBox) et utilisation de l'option skpriority
(dhcpv6). Les autres règles peuvent être définies de la bonne manière sans problème avec nftables (crochet postrouting ou output+ table ARP).

Je précise cela car iptables est déprécié !!

La commande tcpdump ci-dessus à l'air de "manger" des paquets : ex, je vois bien arriver les demandes ARP d'Orange, mais pas les réponses de mon routeur, bien présentes si je ne mets aucun filtre. Si quelqu'un a une idée plus pertinente que de laisser tourner un tcpdump sans filtre, je suis preneur.

Pas de solution sur le renew. Du coup, en contournement, je relance un cycle complet depuis le Solicit avec un intervalle de moins de 20h, par un killall -s SIGUSR2 odhcp6c.
Le renew doit-il être en unicast ?

C'est encore dommage que le rôle de SIGUSR2 ne soit pas indiqué dans la documentation. Je croyais qu'il aurait fallu développer un script pour relancer la transaction après un RELEASE.
Je pense que @MarcFramboisier tu as trouvé la solution. C'est mieux que de redémarrer entièrement le routeur en cas de perte de la connexion comme le propose @ubune dans son tutoriel.

[12:42] À voir si cela s'intègre avec Hotplug.

En cherchant, je ne suis pas persuadé que le mécanisme Hotplug puisse vraiment s'appliquer. On sait que le client DHCPv6 lance le script dhcpv6.script lors d'un changement d'état.
Mais l'état dans lequel se trouve le client DHCPv6 après une rupture de connexion n'est pas tellement clair.

** State Script **

The state script is called whenever the DHCPv6 state changes.
The script is called with the following parameters: <interface> <state>


States:
* started      The DHCPv6 client has been started
* bound         A suitable server was found and addresses or prefixes acquired      
* informed      A stateless information request returned updated information
* updated      Updated information was received from the DHCPv6 server
* ra-updated      Updated information was received from via Router Advertisement
* rebound      The DHCPv6 client switched to another server
* unbound      The DHCPv6 client lost all DHCPv6 servers and will restart
* stopped      The DHCPv6 client has been stopped

dhcpv6.script

case "$2" in
bound)
teardown_interface "$1"
setup_interface "$1"
;;
informed|updated|rebound)
setup_interface "$1"
;;
ra-updated)
[ -n "$ADDRESSES$RA_ADDRESSES$PREFIXES$USERPREFIX" ] && setup_interface "$1"
;;
started|stopped|unbound)
teardown_interface "$1"
;;
esac

teardown_interface() {
proto_init_update "*" 0
proto_send_update "$INTERFACE"
}

netifd-proto.sh

proto_init_update() {
        local ifname="$1"
        local up="$2"
        local external="$3"

        PROTO_KEEP=0
        PROTO_INIT=1
        PROTO_TUNNEL_OPEN=
        PROTO_IPADDR=
        PROTO_IP6ADDR=
        PROTO_ROUTE=
        PROTO_ROUTE6=
        PROTO_PREFIX6=
        PROTO_DNS=
        PROTO_DNS_SEARCH=
        PROTO_NEIGHBOR=
        PROTO_NEIGHBOR6=
        json_init
        json_add_int action 0
        [ -n "$ifname" -a "*" != "$ifname" ] && json_add_string "ifname" "$ifname"
        json_add_boolean "link-up" "$up"
        [ -n "$3" ] && json_add_boolean "address-external" "$external"
}

proto_send_update() {
        local interface="$1"

        proto_close_nested
        json_add_boolean keep "$PROTO_KEEP"
        _proto_push_array "ipaddr" "$PROTO_IPADDR" _proto_push_ipv4_addr
        _proto_push_array "ip6addr" "$PROTO_IP6ADDR" _proto_push_ipv6_addr
        _proto_push_array "routes" "$PROTO_ROUTE" _proto_push_route
        _proto_push_array "routes6" "$PROTO_ROUTE6" _proto_push_route
        _proto_push_array "ip6prefix" "$PROTO_PREFIX6" _proto_push_string
        _proto_push_array "dns" "$PROTO_DNS" _proto_push_string
        _proto_push_array "dns_search" "$PROTO_DNS_SEARCH" _proto_push_string
        _proto_push_array "neighbor" "$PROTO_NEIGHBOR" _proto_push_ipv4_neighbor
        _proto_push_array "neighbor6" "$PROTO_NEIGHBOR6" _proto_push_ipv6_neighbor
        _proto_notify "$interface"
}

_proto_notify() {
        local interface="$1"
        local options="$2"
        json_add_string "interface" "$interface"
        ubus $options call network.interface notify_proto "$(json_dump)"
}