La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: MarcFramboisier le 14 octobre 2024 à 20:13:23
-
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/
-
Bonjour,
si ça arrive après 20h presque pile, c'est au moment du renew. peut être que la cohérence entre v4 et v6 n'est pas satisfaite du coup orange déconnecte la ligne ...
ça m'est arrivé, du coup peut être vérifier ce point, bien vérifier que les options soient toutes cohérentes
-
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 (https://udhcp.busybox.net/README.udhcpc) ou odhcp6c (https://github.com/openwrt/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. (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1079566/#msg1079566)
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é !!
-
@jeremyp, je viens encore de comparer la trace réseau de mon turris avec celle relevée sur la Livebox. Je ne vois aucune différence.
Du coup, je vais laisser tourner :
tcpdump -i eth2 -w /mnt/bck/trace/omnia.pcap udp port 546 or udp port 67 or icmp6 or arp or igmp &pour écouter ce que se raconte mon turris et l'infra d'orange.
-
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.
-
Comme l'a suggéré @jeremyp3, c'est bien au renew que la connexion est interrompue. Dans les traces, je vois partir la requête dhcpv6 de renew, puis après plus aucun packet en provenance d'orange.
J'arrive à déclencher ce comportement par :killall -s SIGUSR1 odhcp6cSi on lance un renew sur ipv4, le comportement à l'air différent. Je continue à tester
-
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 ?
-
Je pense que le client envoie sa requête RENEW en multicast. Ma capture réseau a été réalisé sur quelques minutes et ne fait pas apparaître les messages RENEW.
C'est que semble indiquer la section « 17.1. Source Address and Interface Selection for Address Assignment (https://www.rfc-editor.org/rfc/rfc8415.html#section-17.1) » du RFC 8415.
17.1. Source Address and Interface Selection for Address Assignment
When a client sends a DHCP message directly to a server using unicast (after receiving the Server Unicast option (see Section 21.12) from that server),
the source address in the header of the IPv6 datagram MUST be an address assigned to the interface for which the client is interested in obtaining
configuration and that is suitable for use by the server in responding to the client.
21.12. Server Unicast Option
If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server,
the client SHOULD unicast any Request, Renew, Release, and Decline messages to the server.
-
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.
-
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.
La problématique est de pouvoir détecter correctement une perte de connexion. Je pense qu'il faut similer une rupture de connexion et observer ce que fait la Livebox.
Normalement, le serveur DHCPv6 est censé répondre au message RENEW par un message REPLY (c.f. section 18.3.4. Receipt of Renew Messages (https://www.rfc-editor.org/rfc/rfc8415.html#section-18.3.4)).
-
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)"
}
-
Je me prends peut-être la tête pour rien... mais il y a Ubus (https://openwrt.org/docs/techref/ubus) (message odhcp6c), netifd (https://openwrt.org/docs/techref/netifd) (Hotplug || odhcp6c) et Watchcat (https://openwrt.org/docs/guide-user/advanced/watchcat) (en roue de secours).
-
Pour aller plus loin, il faut remettre la LB pendant 1 journée complète, avec mon Turris en interception pour récupérer le paquet de renew et comparer avec ce qu'envoie mon Turris.
Mon contournement avec des relances de cycles à 0h30 et 6h30, engendre deux petites coupures de connexion, pendant que je dors.
Le hotplug ne semble pas avoir un état 'attention, je vais faire un renew'. Du coup, je doute de son utilité dans mon cas.
Quant à l'unicast, nous avons la même lecture de la RFC, si le serveur renvoie l'option 12, on peut faire de l'unicast.
Merci d'avoir pris le temps de me répondre.
-
Il me semble qu'il faut avoir des connaissances en C et système, pour aller plus loin. La documentation OpenWrt est trop lacunaire.
Il me manque beaucoup de connaissances en système. Toutefois, en observant attentivement la documentation, il me semble que
je suis sur la bonne voie. Je me doute bien que le Hotplug ne va pas s'activer magiquement en fonction d'un état qui varie. C'est ce
que je cherche à comprendre ou à déterminer. Plus on avance, plus on a l'impression que cela devient une chasse gardée !
Bref, je crois que j'ai une piste.
(programmersought.com) hotplug script call (https://www.programmersought.com/article/10805629016/)
Dans cet article, il est dit que le client dhcp émet un appel ubus qui est traité par netifd. Celui-ci déclenche finalement un événement Hotplug
en invoquant le script hotplug-call.
-
Cela résolverait partiellement le problème.
Je pense qu'il faut aussi rechercher au niveau de procd. :-X
Divulgachage : en cas de résolution, je pense qu'on pourrait améliorer le tutoriel de @ubune sur la gestion du PCP et DSCP des paquets
avec nftables (https://lafibre.info/remplacer-livebox/filtrer-les-raw-socket-avec-nftables/msg1079566/#msg1079566).
-
Ce que j'ai dit à propos du potentiel script Hotplug n'est pas très logique.
udhcp6c sait dans quel état il se trouve. En conséquence, le script dhcpv6.script sert probablement à modifier l'état des autres processus.
Conclusion : Je ne sais pas. Tant pis !