La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: renaud07 le 11 mars 2025 à 03:49:38
-
J'ai voulu tester le macvlan pour faire cracher tous ses préfixes à la LB. Alors, ça marche, mais on se retrouve coincé à devoir se contenter du routeur.
Vu que c'est /64 par /64 et par interface virtuelle, impossible de déléguer à un autre routeur, même si on assigne pas tous les préfixes au LAN. Y'a une astuce ou c'est mort ?
Par exemple sur la capture, on ne peut pas déléguer ee::/64 à un autre routeur, même en attribuant que c3::/64 au LAN. Par contre attribuer les 2 au LAN marche (mais pas de délégation non plus).
-
@renaud07 :
On peut légitiment se demander si les Livebox délégueront un jour d'autres longueurs de préfixe que du /64. Il s'agit peut-être d'une limitation fixée par Orange.
Auquel cas, il serait plus avisé d'intervertir la Livebox et le routeur. Si cela est un challenge, eh bien!... fais comme il te plaît.
-
J'ai voulu tester le macvlan pour faire cracher tous ses préfixes à la LB. Alors, ça marche, mais on se retrouve coincé à devoir se contenter du routeur.
Vu que c'est /64 par /64 et par interface virtuelle, impossible de déléguer à un autre routeur, même si on assigne pas tous les préfixes au LAN. Y'a une astuce ou c'est mort ?
Par exemple sur la capture, on ne peut pas déléguer ee::/64 à un autre routeur, même en attribuant que c3::/64 au LAN. Par contre attribuer les 2 au LAN marche (mais pas de délégation non plus).
je ne connais pas assez openwrt a ce niveau. odhcp6c fait serveur de délégation ? ce n'est pas clair dans la doc. si ton interface a une IP dans ee::/64 c'est trop tard effectivement.
au besoin peut-etre un script indépendant peut faire un requete de prefix a la LB et le servir ensuite en delegation sur une interface lan ? a creuser.
-
Si tu obtiens tous les /64, tu as bien un /56 routé en intégralité.
Si tu configures odhcpd pour distribuer des préfixes dans le /56, ca ne marche pas? Il faudra peut-être scripter pour reconfigurer ce /56 en cas de changement de préfixes délégués par la livebox.
J'aime l'ingéniosité, mais ca fait quand même bricole :)
Je pense que le soucis vient du fait qu'on ne peut pas avoir tous les /64 sur une seule interface... D’ailleurs, je sais même pas comment configurer le client DHCP pour avoir plusieurs demandes de IA_PD /64 (en admettant que la box accepte, ce qui m'étonnerais)
Si c'est resté comme cela aussi longtemps, on peut penser que c'est bel et bien intentionnel pour segmenter les offres...
Dans ce cas, je me demande juste pourquoi la livebox répond positivement à une seconde requête de délégation.
Croisions les doigts pour que les demandes faites dans le topic des features avancées soient exaucées... Mais à priori, il y a déjà du mieux, puisque on peut désormais avoir 2 préfixes délégués qui fonctionnent, ce n'était pas le cas avant.
je ne connais pas assez openwrt a ce niveau. odhcp6c fait serveur de délégation ? ce n'est pas clair dans la doc. si ton interface a une IP dans ee::/64 c'est trop tard effectivement.
au besoin peut-etre un script indépendant peut faire un requete de prefix a la LB et le servir ensuite en delegation sur une interface lan ? a creuser.
Yep, odhcp6c fait bien de la délégation. Lorsque je suis en direct, je récupère mon /56 sur le WAN et je peux déléguer un /60 par ex à un autre routeur sans soucis.
Pour le script c'est à creuser effectivement.
-
Même problème en Slovaquie !
Source : https://openwrt.org/docs/guide-user/network/wan/isp-configurations#orange_slovensko
Downstream configuration for LAN interfaces (https://openwrt.org/docs/guide-user/network/ipv6/configuration#downstream_configuration_for_lan_interfaces)
ip6assign: Prefix size used for assigned prefix to the interface (e.g. 64 will assign /64-prefixes)
ip6class: Filter for prefix classes to accept on this interface (e.g. wan6 - only assign prefix from the respective interface, local - only assign the ULA-prefix)
-
Effectivement c'est odhcpd, mon doigt a ripé ;) Je me suis servi de l'exemple AT&T pour la conf.
Et dire qu'il suffirait de mettre la partie firmware qui gère tout ça en opensource ouvert aux contributions pour faire un super truc activable à la demande, mais non...
-
Je pense que le soucis vient du fait qu'on ne peut pas avoir tous les /64 sur une seule interface... D’ailleurs, je sais même pas comment configurer le client DHCP pour avoir plusieurs demandes de IA_PD /64 (en admettant que la box accepte, ce qui m'étonnerais)
Testé avec testdhcpv6pd (https://github.com/nspeed-app/testdhcpv6pd), la lb supporte bien 2 ou plus demandes de prefix en 'meme temps'.
PS T:\dev\testdhcpv6pd> .\testdhcpv6pd -a 14 -p ::/64 -p ::/64 8
2025/03/11 22:01:34 Sending a DHCPv6-PD Solicit on interface Ethernet 10G Intel
[dhcpv6] 2025/03/11 22:01:34 sent message: Message{
MessageType=SOLICIT
TransactionID=0xd34841
Options: [
Client ID: DUID-LLT{HWType=Ethernet HWAddr=80:61:5f:0a:47:e9 Time=795042094}
Requested Options: DNS, Domain Search List
Elapsed Time: 0s
IAPD: IAID=0x00000001 T1=0s T2=0s Options=[
IA Prefix: {PreferredLifetime=0s, ValidLifetime=0s, Prefix=::/64, Options={[]}}
]
IAPD: IAID=0x00000002 T1=0s T2=0s Options=[
IA Prefix: {PreferredLifetime=0s, ValidLifetime=0s, Prefix=::/64, Options={[]}}
]
]
}
[dhcpv6] 2025/03/11 22:01:34 received message: Message{
MessageType=ADVERTISE
TransactionID=0xd34841
Options: [
Client ID: DUID-LLT{HWType=Ethernet HWAddr=80:61:5f:0a:47:e9 Time=795042094}
Server ID: DUID-LL{HWType=Ethernet HWAddr=58:1d:d8:63:ad:c0}
IAPD: IAID=0x00000001 T1=5m0s T2=8m0s Options=[
IA Prefix: {PreferredLifetime=10m0s, ValidLifetime=24h0m0s, Prefix=2a01:xxxx:xxxx:78d4::/64, Options={[]}}
]
IAPD: IAID=0x00000002 T1=5m0s T2=8m0s Options=[
IA Prefix: {PreferredLifetime=10m0s, ValidLifetime=24h0m0s, Prefix=2a01:xxxx:xxxx:78da::/64, Options={[]}}
]
Preference: [255]
DNS: [2a01:xxxx:xxxx:7800:5a1d:d8ff:fe63:adc0]
Domain Search List: [home]
]
}
2025/03/11 22:01:34 got a prefix = 2a01:xxxx:xxxx:78d4::/64 (pttl=10m0s,vttl=24h0m0s)
2025/03/11 22:01:34 got a prefix = 2a01:xxxx:xxxx:78da::/64 (pttl=10m0s,vttl=24h0m0s)
sauf que parfois ca propose 2 fois le meme .. (bug coté LB?).
du coup il serait plus safe de faire plusieurs demandes l'une a la suite.
selon la norme un meme client (identifié par son DUID) peut demander plusieurs prefixes (séparement ou d'un coup) en variant l'IAID de la demande. l'IAID est propre a chaque client donc 2 clients différents (DUID différents) peuvent avoir des IAID identiques.
concernant odhcpd, a regarder le code rapidement, il communique par ubus (https://openwrt.org/docs/techref/ubus)donc on peut éventuellement lui envoyer des commandes par la (cf doc commande ubus, on peut lister les serveurs inscrits et faire des scripts avec pour piloter les services).
Dans le cas d'une propagation de PD, j'imagine que le client (odhcp6c) signale le lease reçu de la LB au serveur PD (odhcpd) via ubus. Le code ubus coté serveur ne fait état que de leases IPv4 et IPv6 (mais on voit bien "ipv6-prefix" dans l'ubus du code serveur). mais je ne vois rien dans odhcp6c concernant ubus...donc y'a surement un script shell qui gere odhcp6c et agit a la reception des leases. ll faudrait trouver ce script.
bref y'a moyen peut-etre par ce coté (scripts +ubus) mais je n'ai pas de plateforme/vm openwrt sous la main pour creuser plus et faire des tests
-
Après pas mal de recherches, j'ai enfin trouvé comment personaliser l'IAID : il faut ajouter :X à l'option reqprefix par exemple 64:5 64:4. Par contre, je ne sais pas trop la syntaxe pour le mettre dans le fichier de config. J'ai testé :
option reqprefix '64:4'
option reqprefix '64:5'
ou
option reqprefix '64:4 64:5'
Dans le premier cas seul une valeur est prise, dans la seconde, pas de requête (sans doute il ne faut pas l'écrire comme ça). Par contre en ligne de commande simple :
odhcp6c -P 64:4 -P 64:5 eth0.3
8)
00:20:26.549744 IP6 (flowlabel 0x629b3, hlim 1, next-header UDP (17) payload length: 181) fe80::a0be:43ff:fec5:8057.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=d92492 (elapsed-time 819) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 a2be43c58057) (reconfigure-accept) (Client-FQDN)[b] (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:4 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)) (IA_PD IAID:5 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))[/b]
Maintenant, faut tester avec la box, ce qui ne va pas être simple dans mon cas pour l'instant...
-
les scripts pour le client sont la: https://github.com/openwrt/openwrt/tree/main/package/network/ipv6/odhcp6c/files
ca met ce qui suit "reqprefix" apres "-P" pour le passer a odhcp6c :
[ "$reqprefix" != "no" ] && append opts "-P$reqprefix"
tu peux donc éventuellement essayer:
option reqprefix '64:4 -P 64:5'
c'est un peu cheat mais ca marchera peut-etre ;)
-
Ça marche :D
01:08:08.439941 IP6 (flowlabel 0x629b3, hlim 1, next-header UDP (17) payload length: 181) fe80::a0be:43ff:fec5:8057.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=de0b22 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 a2be43c58057) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:4 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)) (IA_PD IAID:5 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
01:08:08.457805 IP6 (class 0xc0, hlim 64, next-header UDP (17) payload length: 181) fe80::xxx:1eff:fe6c:xxxx.547 > fe80::a0be:43ff:fec5:8057.546: [udp sum ok] dhcp6 advertise (xid=de0b22 (client-ID hwaddr type 1 a2be43c58057) (server-ID hwaddr type 1 xxxx1e6cxxxx) (IA_PD IAID:4 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4f0::/64 pltime:600 vltime:86400)) (IA_PD IAID:5 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4ff::/64 pltime:600 vltime:86400)) (preference 255) (DNS-server 2a01:cbxx:xxxx:xxxx:xxxx:1eff:fe6c:xxxx fe80::xxx:1eff:fe6c:xxxx) (DNS-search-list home.))
Par contre, pas d’affichage du second préfixe dans luci... Bizarre. Mais c'est déjà un bon début.
EDIT : un ifstatus de l'interface remonte bien les deux prefixes, l'affichage dans luci ne doit pas avoir prévu le cas j'imagine...
root@LEDE:~# ifstatus WAN6_LB
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 11,
"l3_device": "eth0.3",
"proto": "dhcpv6",
"device": "eth0.3",
"updated": [
"addresses",
"routes",
"prefixes",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
],
"ipv6-address": [
{
"address": "2a01:cbxx:xxxx:xxxx:a0be:43ff:fec5:8057",
"mask": 64,
"preferred": 589,
"valid": 86389
}
],
"ipv6-prefix": [
{
"address": "2a01:cbxx:xxxx:x4f0::",
"mask": 64,
"preferred": 589,
"valid": 86389,
"class": "00000004",
"assigned": {
"VMs": {
"address": "2a01:cbxx:xxxx:x4f0::",
"mask": 64
}
}
},
{
"address": "2a01:cbxx:xxxx:x4ff::",
"mask": 64,
"preferred": 589,
"valid": 86389,
"class": "00000005",
"assigned": {
"VMs": {
"address": "2a01:cbxx:xxxx:x4ff::",
"mask": 64
}
}
}
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "2a01:cbxx:xxx:xxxx::",
"mask": 64,
"nexthop": "::",
"metric": 256,
"valid": 86389,
"source": "::/0"
}
],
"dns-server": [
"2a01:cbxx:xxx:xxxx:xxxx:1eff:fe6c:xxxx",
"fe80::xxxx:1eff:fe6c:xxxx"
],
"dns-search": [
"home"
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
"passthru": "001700202a01cb140d2a940046a61efffe6cab56fe8000000000000046a61efffe6cab560018000604686f6d6500"
}
}
Et encore mieux, les 2 coquins se sont attribué à l'interface VMS (je n'avais pas fait attention au début). Donc cette partie fonctionne. Reste à vérifier qu'en attribuant qu'un seul, je peux effectivement avoir l'autre sur un routeur différent.
-
Mauvaise nouvelle, ça ne fonctionne pas plus avec cette méthode même si un seul /64 est attribué au LAN, il me dit toujours NoPrefixAvail... à confirmer chez quelqu’un d'autre cela dit, sur une connexion plus stable...
J'ai également tenté de rajouter l'option ip6prefix au LAN en précisant un des préfixes délégués (on se retrouve donc avec un ipv6-pd sur le LAN), sans succès, après je sais pas si cette option est censé s'utiliser de cette manière ou si c'est juste pour faire du statique côté WAN.
D'après la doc, il faudrait assigner plus qu'un 64 au LAN pour que la délégation soit possible (et c'est bien ce que je fais en temps normal) Dans leur exemple ils assignent un /60 au LAN. Dans ce cas on peut distribuer du /62, /63 ou /64.
EDIT : Autre limitation qui est plus embêtante cette fois : J'ai voulu demander 5 préfixes, la LB me les renvoie pas de soucis, sauf que c'est openwrt cette fois qui n'en prend que 4... On va pas pouvoir déléguer les 255 de cette manière à moins de recourir aux interfaces virtuelles, mais ça va en faire un sacré paquet :-X
-
D'après la doc, il faudrait assigner plus qu'un 64 au LAN pour que la délégation soit possible (et c'est bien ce que je fais en temps normal) Dans leur exemple ils assignent un /60 au LAN. Dans ce cas on peut distribuer du /62, /63 ou /64.
si je comprend bien, pour distribuer en PD coté LAN il faut au moins un /63 ? si on a plusieurs /64 non contigues ca ne le fait pas ?
j'avoue la doc ici: https://openwrt.org/docs/guide-user/network/ipv6/configuration n'est pas clair clair.
mais le README du serveur a plus d'info: https://github.com/openwrt/odhcpd/blob/master/README
mais concerne /etc/config/dhcp pas /etc/config/network
il y a une option "dhcpv6_pd" pour mettre le serveur en mode 'serveur de delegation'.
bon apres ton cas d'usage est plutot d'avoir un assignement sur plusieurs LAN non ? ou tu veux re-deleguer derriere a d'autres routeurs?
poste tes 2 fichiers de config au besoin.
-> ce sujet devient un peu fouillis car le titre est "Remplacement de la Livebox par un routeur Openwrt" et on parle de delegation derriere une livebox ;)
-
si je comprend bien, pour distribuer en PD coté LAN il faut au moins un /63 ? si on a plusieurs /64 non contigues ca ne le fait pas ?
Oui. Mais y'a peut-être moyen de bypasser ça sans trop bidouiller.
il y a une option "dhcpv6_pd" pour mettre le serveur en mode 'serveur de delegation'.
C'est déjà le cas chez moi.
bon apres ton cas d'usage est plutot d'avoir un assignement sur plusieurs LAN non ? ou tu veux re-deleguer derriere a d'autres routeurs?
À d'autres routeurs, vu ma config réseau faire passer tout par OWRT ne m’arrange pas, j'ai un uplink de 100 Mbps entre le LAN et le routeur (pont wifi).
-> ce sujet devient un peu fouillis car le titre est "Remplacement de la Livebox par un routeur Openwrt" et on parle de delegation derriere une livebox ;)
Je pensais que ça serait une formalité ou presque... je peux ouvrir un autre sujet dédié ou toi crée un autre sujet et déplace tous les messages dedans ?
-
C'est bon j'ai séparé, je n'ai pas pris certains messages non pertinents (désolé basilix). Le sujet est complexe donc éviter le spam ou les copier/coller trop long.
@renaud07, résume ton besoin et poste ta config (au minimum /etc/config/dhcp et /etc/config/network).
-
@kgersen :
C'est vrai que j'ai tendance à déborder du sujet principal, à tord ou à raison (voir ci-dessous).
Je pense que les programmes OpenWrt sont composés. Je ne suis pas convaincu qu'on puisse dériver des fonctionnalités sans en saisir l'architecture.
Je n'ai peut-être pas la bonne technique : je creuse. Le sujet est complexe. J'aborde cette complexité par plusieurs bouts. Désolé, mais je ne suis pas
persuadé que la technique que @renaud07 et toi aimeriez employer soit la bonne. Je pense que les gens qui ont conçu ces logiciels sont des cerveaux.
J'ai répondu à certaines questions. Le reste je n'ai pas trouvé.
-
Pas plus simple de faire comme tout le monde et simplement bypass la livebox ... ?
-
Dans mon cas il me faudrait au moins un autre /64 pour mon routeur dédié aux VM. Et que je puisse en avoir 2-3 autres à dispo pour d'autres usages.
Côté config :
/etc/config/dhcp
config dhcp 'lan'
option interface 'lan'
option ignore '1'
option dhcpv6_pd '1'
option dhcpv6_na '0'
list domain 'domain.lan'
list dns 'fe80::ba27:ebff:xxx:xxxx'
option ra_management '0'
option ra 'server'
option dhcpv6 'server'
/etc/config/network
config interface 'WAN4_LB'
option ifname 'eth0.3'
option proto 'dhcp'
config interface 'WAN6_LB'
option ifname 'eth0.3'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix '64:1 -P 64:2 -P 64:3 -P 64:4 -P 64:5'
Avec cette config, et un des préfixes assignés au LAN, ça ne fonctionne pas. Le préfixe est bien annoncé, mais le routage est cassé. La LB ne doit pas du tout aimer avoir plusieurs préfixes pour la même @MAC. D'ailleurs elle n'affiche qu'un seul préfixe (cf capture)
"ipv6-prefix": [
{
"address": "2a01:cbxx:xxx:x4ce::",
"mask": 64,
"preferred": 526,
"valid": 86326,
"class": "00000003",
"assigned": {
}
},
{
"address": "2a01:cbxx:xxx:x4d8::",
"mask": 64,
"preferred": 526,
"valid": 86326,
"class": "00000002",
"assigned": {
}
},
{
"address": "2a01:cbxx:xxx:x4ea::",
"mask": 64,
"preferred": 526,
"valid": 86326,
"class": "WAN6_LB",
"assigned": {
"lan": {
"address": "2a01:cbxx:xxx:x4ea::",
"mask": 64
}
}
},
{
"address": "2a01:cbxx:xxx:x4f0::",
"mask": 64,
"preferred": 526,
"valid": 86326,
"class": "00000004",
"assigned": {
}
Pas plus simple de faire comme tout le monde et simplement bypass la livebox ... ?
Si il n'y avait pas à acheter pour des centaines d'euros de matos et à bidouiller des firmwares qui ne pardonnent pas en cas d'erreur, la question ne se poserait sans doute pas...
Perso, si je peux me débrouiller pour avoir des préfixes délégués qui fonctionnent, je crois que je vais m'en tenir à laisser mon routeur derrière la box. Ça me fait un peu ch*er, oui, mais c'est clairement devenu une usine à gaz trop sensible depuis qu'on est obligé d'avoir des ONT perso. Et vu que c'est de plus en plus compliqué d'en réclamer des externes avec le XGSPON qui se déploie... :-\
Vivement que le législateur passe par là... oui je sais je rêve.
-
Avec cette config, et un des préfixes assignés au LAN, ça ne fonctionne pas. Le préfixe est bien annoncé, mais le routage est cassé. La LB ne doit pas du tout aimer avoir plusieurs préfixes pour la même @MAC. D'ailleurs elle n'affiche qu'un seul préfixe (cf capture)
oui tant que y'a pas 2 lignes ou plus dans l'interface de la live box ca ne marchera pas...
il faut rententer avec 2 macvlan peut -etre?
-
oui tant que y'a pas 2 lignes ou plus dans l'interface de la live box ca ne marchera pas...
il faut rententer avec 2 macvlan peut -etre?
Pas de soucis avec les macvlan. C'est bien le premier truc que j'ai testé. Je pensais qu'on aurait pu s'en passer avec les multiples IAID, mais c'est encore trop complexe pour mademoiselle...
-
Pas de soucis avec les macvlan. C'est bien le premier truc que j'ai testé. Je pensais qu'on aurait pu s'en passer avec les multiples IAID, mais c'est encore trop complexe pour mademoiselle...
oui car tu confirme qu'avec une seule interface vers la LB tu as bien eu 2 baux avec 2 préfixes différents (avec la manip "...-P..." )mais dans l'interface de la LB on en voyait qu'un ?
ca veut dire qu'elle a remplacé le premier par le deuxieme au lieu de l'ajouter donc elle ne respecte pas la norme => il faudrait confirmer avec une capture réseau éventuellement (histoire d'évacuer un probleme coté openwrt, notamment sur le duid et l'iaid envoyés).
avec macvlan le souci est maintenant d'arriver a :
A - mettre un prefix sur une interface lan de l'openwrt: ca c'est ok vu ta derniere capture ?
B - mettre l'autre prefix a dispo via dhcpv6-pd avec le serveur odhcpd d'openwrt.
Pour B comment teste tu (en gros ou vois tu que ca ne marche pas) ? as tu essayé avec https://github.com/nspeed-app/testdhcpv6pd ?
-
bon j'ai fait un test rapide en direct derriere une livebox 7, apres systemd-networkd.
machine avec 2 cartes réseaux physiques vers la LB.
c'est un peu le souci dans la lb entre ce qui est affiché dans l'interface et les leases actifs et routés...
j'ai une prefix routé , qui marche (tester depuis l'exterieur et l'interieur) mais qui n'apparait pas dans l'interface de la lb...
Mar 12 22:41:20 nuca systemd-networkd[341]: ens8: DHCP: received delegated prefix 2a01:xxxx:xxxx:78c5::/64
et dans la lb:
(https://i.imgur.com/0oUFTHr.png)
quand de l'exterieur je cherche a joindre le 1er prefix (78df): "Destination unreachable: No route" (reponse de l'ipv6 public externe de lb)
le deuxieme (78e8) marche (les paquets arrivent bien sur l'interface de PC-620)
et 78c5 marche a moitié (les paquets n'arrivent pas mais y'a pas erreur Destination unreachable"
donc j'ai pris mon devtool Chrome et j'ai regardé comment fonctionne l'interface de la LB; il y a un échange par websocket et une réponse en json:
{
"status": [
{
"MacAddress": "00:30:93:xx:xx:xx",
"PDPrefixList": [
{
"Prefix": "2a01:xxxx:xxxx:78df::",
"PrefixLen": 64
},
{
"Prefix": "2a01:xxxx:xxxx:78c5::",
"PrefixLen": 64
}
]
},
{
"MacAddress": "1C:69:7A:xx:xx:xx",
"PDPrefixList": [
{
"Prefix": "2a01:xxxx:xxxx:78e8::",
"PrefixLen": 64
}
]
}
]
}
et oui le code HTML de la page n'a pas prévu d'afficher plusieurs prefixes pour la meme MAC...et n'affiche pas forcement celui qui est bon (routé).
-
Je viens de découvrir un truc ahurissant que j'avais pas remarqué hier : quand je disais qu'openwrt ne prenait que 4 préfixes au lieu de 5 avec les IAID...
Encore du grand Orange, regardez bien le reply :
02:42:16.624181 IP6 (flowlabel 0x629b3, hlim 1, next-header UDP (17) payload length: 300) fe80::a0be:43ff:fec5:8057.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=63da0d (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 a2be43c58057) (reconfigure-accept) (Client-FQDN) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)) (IA_PD IAID:2 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)) (IA_PD IAID:3 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)) (IA_PD IAID:4 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)) (IA_PD IAID:5 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
02:42:16.634777 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 316) fe80::xxxx:1eff:fe6c:xxxx.547 > fe80::a0be:43ff:fec5:8057.546: [udp sum ok] dhcp6 advertise (xid=63da0d (client-ID hwaddr type 1 a2be43c58057) (server-ID hwaddr type 1 xxxx1e6cxxxx) (IA_PD IAID:1 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4ea::/64 pltime:600 vltime:86400)) (IA_PD IAID:2 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xx:x4d8::/a64 pltime:600 vltime:86400)) (IA_PD IAID:3 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4ce::/64 pltime:600 vltime:86400)) (IA_PD IAID:4 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4f0::/64 pltime:600 vltime:86400)) (IA_PD IAID:5 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4ff::/64 pltime:600 vltime:86400)) (preference 255) (DNS-server 2a01:cb14:d2a:9400:46a6:1eff:fe6c:ab56 fe80::xxxx:1eff:fe6c:xxxx) (DNS-search-list home.))
02:42:16.974814 IP6 (flowlabel 0x629b3, hlim 1, next-header UDP (17) payload length: 312) fe80::a0be:43ff:fec5:8057.546 > ff02::1:2.547: [udp sum ok] dhcp6 request (xid=f74818 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96) (client-ID hwaddr type 1 a2be43c58057) (server-ID hwaddr type 1 xxxx1e6cxxxx) (reconfigure-accept) (Client-FQDN) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2a01:cbxx:xxx:x4ea::/64 pltime:600 vltime:86400)) (IA_PD IAID:2 T1:0 T2:0 (IA_PD-prefix 2a01:cbxx:xx:x4d8::/64 pltime:600 vltime:86400)) (IA_PD IAID:3 T1:0 T2:0 (IA_PD-prefix 2a01:cbxx:xxx:x4ce::/64 pltime:600 vltime:86400)) (IA_PD IAID:4 T1:0 T2:0 (IA_PD-prefix 2a01:cbxx:xxx:x4f0::/64 pltime:600 vltime:86400)) (IA_PD IAID:5 T1:0 T2:0 (IA_PD-prefix 2a01:cbxx:xxx:x4ff::/64 pltime:600 vltime:86400)))
02:42:17.123835 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 271) fe80::xxxx:1eff:fe6c:xxxx.547 > fe80::a0be:43ff:fec5:8057.546: [udp sum ok] dhcp6 reply (xid=f74818 (client-ID hwaddr type 1 a2be43c58057) (server-ID hwaddr type 1 xxxx1e6cxxxx) (IA_PD IAID:1 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4ea::/64 pltime:600 vltime:86400)) (IA_PD IAID:2 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xx:x4d8::/64 pltime:600 vltime:86400)) (IA_PD IAID:3 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4ce::/64 pltime:600 vltime:86400)) (IA_PD IAID:4 T1:300 T2:480 (IA_PD-prefix 2a01:cbxx:xxx:x4f0::/64 pltime:600 vltime:86400)) (preference 255) (DNS-server 2a01:cb14:d2a:9400:46a6:1eff:fe6c:ab56 fe80::xxxx:1eff:fe6c:xxxx) (DNS-search-list home.))
Oui, il manque un préfixe ! Alors que les 5 sont présents dans le advertise... J'ai pas les mots.
Pour ce qui est de l'assignation aux interfaces : les 2 préfixes fonctionnent. J'en ai mis un au LAN, l'autre à l'interface VMS. Au moins un truc qui marche :P
Reste à pouvoir en déléguer d'autres. J'ai testé avec testdhcpv6pd et je n'obtiens rien :
2025/03/12 03:08:01 Sending a DHCPv6-PD Solicit on interface wlo1
[dhcpv6] 2025/03/12 03:08:01 sent message: Message{
MessageType=SOLICIT
TransactionID=0x74a2e7
Options: [
Client ID: DUID-LLT{HWType=Ethernet HWAddr=f4:7b:09:xx:xx:xx Time=795060481}
Requested Options: DNS, Domain Search List
Elapsed Time: 0s
IAPD: IAID=0x01000000 T1=0s T2=0s Options=[
IA Prefix: {PreferredLifetime=0s, ValidLifetime=0s, Prefix=::/64, Options={[]}}
]
]
}
[dhcpv6] 2025/03/12 03:08:01 received message: Message{
MessageType=ADVERTISE
TransactionID=0x74a2e7
Options: [
Server ID: DUID-LL{HWType=Ethernet HWAddr=18:1e:78:xx:xx:xx}
Client ID: DUID-LLT{HWType=Ethernet HWAddr=f4:7b:09:xx:xx:xx Time=795060481}
Max Solicit Timeout Value: [0 0 0 60]
DNS: [fe80::ba27:ebff:xxxx:xxxx]
Domain Search List: [domain.lan]
IAPD: IAID=0x01000000 T1=0s T2=0s Options=[
Status Code: {Code=NoPrefixAvail (6); Message=}
]
]
}
2025/03/12 03:08:01 no prefix found
-
nos deux derniers messages ont du se croiser:) il y a en effet un bug dans l'affichage de l'interface de la lb.
J'ai demandé a l'auteur de Livebox Monitor s'il peut nous aider (on peut en ligne de commande aussi obtenir les baux dans la LB mais je n'ai pas trop le temps de chercher comment).
je referais d'autres essais ce week-end.
-
Ce n'est pas très reluisant de déprécier ainsi Orange et sa Livebox. Il paraît évident que ce boîtier Internet n'est pas prévu pour cet usage.
Il faut suivre un autre modèle. De toute façon, on ne peut pas changer le micrologiciel de la Livebox. Autant se rendre à l'évidence, et aller
de l'avant ! Faire quelque chose qui tienne la route. ???
-
Ce n'est pas très reluisant de déprécier ainsi Orange et sa Livebox.
Et pourquoi donc ?
Apparemment Orange fait de la m* sur ce point, rien ne va, autant du coté du routage que du coté du contenu de la console d'admin. Moi si je fais de la m* dans mon travail, je m'attends à ce que mes collègues me le disent et en retour je fais pareil. C'est comme ça qu'on avance.
Si Orange veut qu'on ne puisse récupérer qu'un préfixe, alors qu'elle l'implémente correctement. Même chose si on est sensés pouvoir en récupérer plusieurs. Là on a un truc qui ne fait correctement ni l'un ni l'autre.
-
je m'attends à ce que mes collègues me le disent
Surtout les clients :-)
Si Orange veut qu'on ne puisse récupérer qu'un préfixe, alors qu'elle l'implémente correctement. Même chose si on est sensés pouvoir en récupérer plusieurs. Là on a un truc qui ne fait correctement ni l'un ni l'autre.
Je pense que c'est une feature tellement peu utilisée sur le segment visé que ce n'est jamais priorisé... on voit qu'ils tentent de changer les choses (e.g. le fait de pouvoir déléguer 2 préfixes maintenant, contre un seul auparavant), mais probablement que les ressources affectées n'ont ni le temps ni les compétences. Ou alors ce n'est pas testé.
-
Si il n'y avait pas à acheter pour des centaines d'euros de matos et à bidouiller des firmwares qui ne pardonnent pas en cas d'erreur, la question ne se poserait sans doute pas...
Perso, si je peux me débrouiller pour avoir des préfixes délégués qui fonctionnent, je crois que je vais m'en tenir à laisser mon routeur derrière la box. Ça me fait un peu ch*er, oui, mais c'est clairement devenu une usine à gaz trop sensible depuis qu'on est obligé d'avoir des ONT perso. Et vu que c'est de plus en plus compliqué d'en réclamer des externes avec le XGSPON qui se déploie... :-\
Vivement que le législateur passe par là... oui je sais je rêve.
Est-ce envisageable pour toi de passer chez Milkywan ? C'est bien le seul opérateur disponible nationalement qui permet officiellement d'utiliser son propre routeur. L'ONT est fourni, donc avec ton OpenWRT, ça fait 0€ de matériel supplémentaire. J'ai tenté la délégation de préfixe une fois derrière la Livebox 6 pour une machine VPN, devant l'échec 3x/4, et l'impossibilité de choisir le préfixe, j'ai abandonné tout de suite. Ça se voit quand c'est un travail fait à contrecœur.
Mais ce qui me retourne le cerveau,
Apparemment Orange fait de la m* sur ce point, rien ne va, autant du coté du routage que du coté du contenu de la console d'admin.
C'est à quel point Orange persiste à améliorer le matériel de génération en génération, mais conserver la même interface enrageante au pire degré à l'usage depuis 2016. Il semble qu'il y ait un espoir avec la démocratisation de PurplOS sur les prochaines box de plusieurs opérateurs, mais j'ai abandonné l'affaire.
-
Est-ce envisageable pour toi de passer chez Milkywan ? C'est bien le seul opérateur disponible nationalement qui permet officiellement d'utiliser son propre routeur. L'ONT est fourni, donc avec ton OpenWRT, ça fait 0€ de matériel supplémentaire. J'ai tenté la délégation de préfixe une fois derrière la Livebox 6 pour une machine VPN, devant l'échec 3x/4, et l'impossibilité de choisir le préfixe, j'ai abandonné tout de suite. Ça se voit quand c'est un travail fait à contrecœur.
+1 pour Milkywan, je regarde aussi de mon côté car les préfixes Orange ont tendance à changer plus souvent ces derniers temps. Entre les frais d'ouverture de ligne et l'abonnement, faut tout de même que ca passe économiquement.
Ceci dit, pour moi l'interco avec Orange depuis un routeur OpenWRT est relativement simple et sans souci. J'ai un ONT externe fourni par Orange lors de la souscription de l'abonnement, donc tout ce qu'il y a à faire c'est DHCPv6/v4 avec les bonnes options.
Le réseau est nickel niveau qualité. Encore une fois, le seul truc qui me dérange, c'est les rotations de préfixe récentes (3 en 2 mois, alors qu'avant je n'en avais jamais).
De mon point de vue, avec les bugs de délégation de préfixe jamais vraiment résolus, et la possibilité qu'ils reviennent dans une version de firmware future, devoir utiliser la livebox serait un no-go et me ferait changer d'opérateur de suite.
Il y a Bouygues avec ses prefixes statiques et une config plus standard que chez Orange, aussi.
-
@zoc :
On n'est pas d'accord, c'est certain. Pour moi, les choses sont claires. C'est le modèle qui diffère. Inutile de pester sur la Livebox.
Il n'est indiqué nul part que ce modèle n'est pas conforme aux standards. Il faut apporter des références, SVP.
L-2: The IPv6 CE router MUST assign a separate /64 from its delegated prefix(es) (and ULA prefix if configured to provide ULA addressing)
for each of its LAN interfaces.
Source : https://www.rfc-editor.org/rfc/rfc7084#section-4.3
Normal que l'interface d'administration de la Livebox n'affiche pas les bonnes informations. La fonctionnalité si convoitée n'est pas supportée.
À ce que je sache, il n'y a qu'une interface LAN sur une Livebox.
-
@zoc :
On n'est pas d'accord, c'est certain. Pour moi, les choses sont claires. C'est le modèle qui diffère. Inutile de pester sur la Livebox.
Il n'est indiqué nul part que ce modèle n'est pas conforme aux standards. Il faut apporter des références, SVP.
Normal que l'interface d'administration de la Livebox n'affiche pas les bonnes informations. La fonctionnalité si convoitée n'est pas supportée.
À ce que je sache, il n'y a qu'une interface LAN sur une Livebox.
serieux arrete de spammer avec des posts qui n'apporte que confusion ou erreurs ? (comme le ttl dans un autre sujet...)
cette rfc que tu cites n'est pas une norme c'est juste une information.
On parle ici d'un bug/erreur dans l'interface de LB comme il y en a d'autres notamment avec le firewall IPv6 qu'on peut configurer plus finement avec Livebox Monitor par exemple. Il y a aussi le vrai RFC de DHCPv6-PD qui n'est pas respecté vu que ca ne route pas un prefix qui techniquement délégué.
Ce genre de bidouille permettre souvent de remonter des infos a Orange pour qu'ils améliorent leur box, d'autant que c'est le meme soft qui est dans la Livebo Pro donc y'a rien de normal que la fonctionnalité ne soit pas supportée. Il faut faire du bad buzz pour que ca remonte chez Orange.
Soit ils limitent a un /64 et qu'un seul: erreur si on en demande un autre, soit ca fonctionne correctement pour N prefixes. c'est cela qu'on attend meme d'une box GP et encore plus d'une Pro.
Est-ce envisageable pour toi de passer chez Milkywan ? C'est bien le seul opérateur disponible nationalement qui permet officiellement d'utiliser son propre routeur. L'ONT est fourni, donc avec ton OpenWRT, ça fait 0€ de matériel supplémentaire. J'ai tenté la délégation de préfixe une fois derrière la Livebox 6 pour une machine VPN, devant l'échec 3x/4, et l'impossibilité de choisir le préfixe, j'ai abandonné tout de suite. Ça se voit quand c'est un travail fait à contrecœur.
on peut demander un ONT 10Gbps chez Bouygues et mettre sa box derriere. c'est l'opérateur GP chez qui c'est le plus simple à faire.
pour ce qui est d'Orange, j'ai 3 Livebox Pro en production avec toute une delegation de prefix IPv6 derriere et ca fonctionne sans souci.
Ici on parle d'un souci quand on veut plusieurs prefixes. Jusqu'à peu la seule solution était de remplacer completement la LB ou d'aller voir ailleurs, la on tente de voir si on peut faire avec, rien de plus.
On est sur une discussion technique précise et ca part encore en discussion politico-comptoir sur Orange... je ne vais pas a nouveau spérarer le sujet mais svp restons sur la technique, y'a d'autres sujets pour promouvoir Milkywan ou cracher sur Orange.
-
@kgersen :
Je vais m'arrêter là vu que ce n'est pas le sujet. Ce n'est pas facile de construire un point de vue sans démonstration.
J'en ai trop fait dans mes autres messages (maladroit). Mais j'essaye de mieux comprendre l'écosystème de OpenWrt.
Je me suis lancé dans le code source et la documentation. C'est quelque peu vexant ou déplacé de dire que je fais du
spam et que dans les grandes lignes j'apporte plus de confusion qu'autre chose.
-
@kgersen :
Je vais m'arrêter là vu que ce n'est pas le sujet. Ce n'est pas facile de construire un point de vue sans démonstration.
J'en ai trop fait dans mes autres messages (maladroit). Mais j'essaye de mieux comprendre l'écosystème de OpenWrt.
Je me suis lancé dans le code source et la documentation. C'est quelque peu vexant ou déplacé de dire que je fais du
spam et que dans les grandes lignes j'apporte plus de confusion qu'autre chose.
oui désolé mais relis tes interventions et pose toi la question. La forme compte aussi entre 'affirmer un truc' et supposer. copier/coller un bout de texte que tout le monde peut trouver par soi-meme n'est pas toujours pertinent.
et si ton point de vue exprimé plus avant est qu'on y arrivera pas et qu'on doit abandonner pourquoi continuer a interferer ?
fin du hs, svp.
-
J'ai besoin d'un petit rafraîchissement sur le parefeu. Je galère pour essayer ne serait-ce que faire répondre au ping les adresses de l’extérieur... Ce n'est pas forwardé par défaut ? Je sais que la box le bloque pour elle même mais je pensais pas que c'était le cas pour le reste du LAN. Le niveau faible ne donne rien, il faut que je passe en personnalisé pour avoir l'option ping et encore que pour la box.
Autre soucis, je ne vois aucun équipement remonter dans la liste pour ouvrir les ports/protocoles, je me demande si ce n'est pas à cause du "object object" sur les 2 préfixes délégués. Et je n'arrive pas à savoir quelle option envoyer par OWRT pour que ça affiche un truc correct. C'est l'option FQDN (39) ?
Il envoie bien LEDE dans mon cas, j'ai essayé de le modifier avec sendopts '39:00044c45444400' qui devrait envoyer "LEDD", sauf que ça n'a pas l'air de lui plaire, car plus de solicit au restart de l'interface.
-
J'ai besoin d'un petit rafraîchissement sur le parefeu. Je galère pour essayer ne serait-ce que faire répondre au ping les adresses de l’extérieur... Ce n'est pas forwardé par défaut ? Je sais que la box le bloque pour elle même mais je pensais pas que c'était le cas pour le reste du LAN. Le niveau faible ne donne rien, il faut que je passe en personnalisé pour avoir l'option ping et encore que pour la box.
Autre soucis, je ne vois aucun équipement remonter dans la liste pour ouvrir les ports/protocoles, je me demande si ce n'est pas à cause du "object object" sur les 2 préfixes délégués. Et je n'arrive pas à savoir quelle option envoyer par OWRT pour que ça affiche un truc correct. C'est l'option FQDN (39) ?
Il envoie bien LEDE dans mon cas, j'ai essayé de le modifier avec sendopts '39:00044c45444400' qui devrait envoyer "LEDD", sauf que ça n'a pas l'air de lui plaire, car plus de solicit au restart de l'interface.
oui il faut ouvrir dans le parefeu de la livebox:
soit en mode personnalisé, ensuite il faut faire une regle IPv6 en bas.
soit en restant en mode moyen avec "livebox monitor" (https://p-dor.github.io/LiveboxMonitor/) on peut maintenant preciser un prefix en destination. Attention cette regle n'appaitra pas dans l'interface web de la livebox mais sera active:
livebox, page parefeu en bas
(https://i.imgur.com/OmYlhhc.png)
livebox monitor, onglet NAT/PAT, partie basse:
(https://i.imgur.com/EFEIMp2.png)
la deuxieme regle n'apparait pas la livebox mais elle est bien la.
-
ps: pour mes tests j'ouvre tout le /56 dans le pare-feu ca évite les aller retour avec livebox monitor.
-
Autre soucis, je ne vois aucun équipement remonter dans la liste pour ouvrir les ports/protocoles, je me demande si ce n'est pas à cause du "object object" sur les 2 préfixes délégués. Et je n'arrive pas à savoir quelle option envoyer par OWRT pour que ça affiche un truc correct. C'est l'option FQDN (39) ?
Pour cette liste coté lb, c'est relou ca ne propose que les noms connus et qui ont une IPv6 public (cf "Mes équipements connectés" ). L'uuid n'est pas pris en charge. bref c'est un grand amateurisme dans cette partie. Heureusement il y a l'API et Livebox Monitor.
-
Je crois que ma box a un soucis, impossible d’ouvrir LB monitor... On dirait que l'onglet mes équipements connectés bug sévère, j'ai une page blanche avec juste le bouton back maintenant (ça marchait encore y'a 2 jours).
Ça sent le reset cette histoire >:(
-
Après des heures de galère et la LB reset... J'ai enfin du ping qui arrive sur mon préfixe délégué \o/ J'ai aussi essayé un port sur l'adresse WAN de l'openwrt, ça marche, sauf que là c'est lui qui refuse la connexion (j'ai testé avec SSH, j'ai pourtant bien ajouté la règle dans son parefeu, sans doute un truc qui m'échappe)
Par contre, il y a encore un bug très bizarre, car j'ai cru que ça ne fonctionnait pas au début... Il ne faut pas que je coche tous les protocoles, en particulier AH et GRE pour que ça fonctionne. Dès que un des deux est coché, le ping ne passe plus. Ou alors c'est un spécial Livebox 4 ?
On va finir par leur faire tout le debug gratos ::)
02:46:42.296795 IP6 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8 > 2a01:cbxx:xxx:xxea::1: ICMP6, echo request, seq 1, length 64
02:46:42.297355 IP6 2a01:cbxx:xxx:xxea::1 > 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8: ICMP6, echo reply, seq 1, length 64
02:46:43.292621 IP6 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8 > 2a01:cbxx:xxx:xxea::1: ICMP6, echo request, seq 2, length 64
02:46:43.293011 IP6 2a01:cbxx:xxx:xxea::1 > 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8: ICMP6, echo reply, seq 2, length 64
EDIT : la connexion SSH marche si je joins le routeur par le préfixe délégué, peut-être le fait de l'adresse SLAAC côté WAN (ou une restriction en dur quelque part, car le port est techniquement ouvert, il répond un connection refused, sinon rien ne se passe). Du coup, plus besoin des règles de ports, vu qu'on ouvre tout le préfixe par les protocoles, nickel.
-
J'ai des bonnes et des mauvaises nouvelles :
-Bonne : le routage marche sans problème avec 3 préfixes et sans être limité à OWRT.
-Mauvaise : Je n'arrive toujours pas à les déléguer, mais c'est très facilement contourné avec une route statique, un peu moins pratique, certes.
Pour éviter que la box se mélange les pinceaux, je n'envoie qu'un seul préfixe avec le FQDN (le principal pour le LAN dans mon cas) les deux autres sont réclamés par les macvlan sans envoyer l'option (rajouter option noclientfqdn '1') la box leur attribue un nom générique et tout va bien.
Reste à tester avec des hôtes derrières et vérifier la bonne ouverture du pare-feu.
root@debian:~# ping -6 -I 2a01:cbxx:xxx:xxee::1 google.fr
PING google.fr(par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003)) from 2a01:cbxx:xx:xxee::1 : 56 data bytes
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=1 ttl=248 time=33.0 ms
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=2 ttl=248 time=32.2 ms
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=3 ttl=248 time=34.1 ms
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=4 ttl=248 time=32.3 ms
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=5 ttl=248 time=33.2 ms
^C
--- google.fr ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 32.211/32.958/34.113/0.694 ms
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:75:f7:fc brd ff:ff:ff:ff:ff:ff
inet 192.168.1.165/24 brd 192.168.1.255 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 2a01:cbxx:xx:xxea:a00:27ff:fe75:f7fc/64 scope global dynamic mngtmpaddr
valid_lft 86375sec preferred_lft 575sec
inet6 fe80::a00:27ff:fe75:f7fc/64 scope link
valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1540 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:1d:49:4f brd ff:ff:ff:ff:ff:ff
inet6 2a01:cbxx:xxx:xxee::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe1d:494f/64 scope link
valid_lft forever preferred_lft forever
root@debian:~# ping -6 -I 2a01:cbxx:xxx:xxc3::1 google.fr
PING google.fr(par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003)) from 2a01:cbxx:xxx:xxc3::1 : 56 data bytes
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=1 ttl=248 time=33.8 ms
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=2 ttl=248 time=33.9 ms
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=3 ttl=248 time=34.4 ms
64 bytes from par10s39-in-x03.1e100.net (2a00:1450:4007:807::2003): icmp_seq=4 ttl=248 time=34.2 ms
^C
--- google.fr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 33.776/34.089/34.418/0.251 ms
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:75:f7:fc brd ff:ff:ff:ff:ff:ff
inet 192.168.1.165/24 brd 192.168.1.255 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 2a01:cbxx:xxx:xxea:a00:27ff:fe75:f7fc/64 scope global dynamic mngtmpaddr
valid_lft 86081sec preferred_lft 281sec
inet6 fe80::a00:27ff:fe75:f7fc/64 scope link
valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1540 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:1d:49:4f brd ff:ff:ff:ff:ff:ff
inet6 2a01:cbxx:xxx:xxc3::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe1d:494f/64 scope link
valid_lft forever preferred_lft forever
/etc/config/network
config device 'vwan1'
option name 'vwan1'
option type 'macvlan'
option ifname 'eth0.3'
option macaddr '70:e7:cf:ae:f2:00'
config device 'vwan2'
option name 'vwan2'
option type 'macvlan'
option ifname 'eth0.3'
option macaddr '70:e7:cf:ae:f2:01'
config interface 'WAN6_LB'
option ifname 'eth0.3'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix '64:1'
config interface 'VWAN_LB1'
option ifname 'vwan1'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option noclientfqdn '1'
config interface 'VWAN_LB2'
option ifname 'vwan2'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option noclientfdqn '1'
config route6
option target '2a01:cbxx:xx:xxc3::/64'
option gateway 'fe80::a00:27ff:fe75:f7fc'
option interface 'lan'
config route6
option target '2a01:cbxx:xxx:xxee::/64'
option interface 'lan'
option gateway 'fe80::a00:27ff:fe75:f7fc'
-
pour résumer:
* entre livebox et openwrt: c'est ok tu as 3 prefixes et ca route bien
* entre openwrt et autre routeur coté lan: tu n'arrives pas a déléguer automatiquement
donc c'est un problème (ou une limitation) d'odhcpd. t'as des logs en principe (logread -e dhcp) ? y'a quoi dans ton /etc/config/dhcp ? que donne 'ubus call dhcp ipv6leases' ?
-
Le néant.
root@LEDE:~# ubus call dhcp ipv6leases
{
"device": {
"eth0.40": {
"leases": [
]
},
"br-lan": {
"leases": [
]
}
}
}
/etc/config/dhcp
config dhcp 'lan'
option interface 'lan'
option ignore '1'
option dhcpv6_pd '1'
option dhcpv6_na '0'
list domain 'dom.lan'
list dns 'fe80::ba27:ebff:xxxx:xxxx'
option ra_management '0'
option ra 'server'
option dhcpv6 'server'
-
Testé avec un 2nd openwrt en VM et une Linux mint derrière ça marche nickel, accès SSH validé. Et après plusieurs essais, j'ai enfin compris la logique du parefeu de la LB : pour que tout marche dans tous les cas il ne faut pas cocher TCP/UDP dans les protocoles sur LB monitor et faire les ouvertures de port une par une... Car si on regarde bien, TCP et UDP ne sont pas dans la liste des protos sur la LB, ceci explique sans doute cela.
Chose que je n'ai pas compris par contre, il a fallut que je définisse manuellement la route par défaut, alors que le SLAAC est bien actif côté WAN. Avec les tests sur ma debian un peu plus tôt, la route était bien mise en place comme n'importe quel hôte. Ou c'est lié au préfixe absent, y'a peut-être une mise en place automatique quand celui-ci est reçu.
EDIT : En comparant avec le routeur principal, il n'y a pas de route par défaut tout court, uniquement en fonction du préfixe, ce qui explique pourquoi elle était inexistante sur la VM. Il faut donc bien que le préfixe soit reçu sur le WAN.
Si j'arrive la mettre en place rapidement, je testerais aussi la délégation derrière la VM, peut-être que la version de mon routeur est trop ancienne (19.07), odhcpd a peut-être eu des MAJ depuis le temps.
-
Si tu obtiens tous les /64, tu as bien un /56 routé en intégralité.
Si tu configures odhcpd pour distribuer des préfixes dans le /56, ça ne marche pas ? Il faudra peut-être scripter pour reconfigurer ce /56 en cas de changement de préfixes délégués par la livebox.
J'aime l'ingéniosité, mais ca fait quand même bricole :)
[...] Si je comprend bien, pour distribuer en PD coté LAN il faut au moins un /63 ? si on a plusieurs /64 non contigues ça ne le fait pas ? [...]
Comment le routeur demandant un préfixe sait-il que d'autres préfixes proviennent tous du même préfixe délégué (par un autre moyen) ?
-
Comment le routeur demandant un préfixe sait-il que d'autres préfixes proviennent tous du même préfixe délégué (par un autre moyen) ?
je ne comprend pas bien la question.
le routeur "demandant" ne connait rien. il fait un broadcast sur son interface wan et si y'a au moins un serveur dhcpv6-pd dessus, il aura une réponse.
@renaud07
J'ai testé avec une VM openwrt a jour. il y a bien une limitation : un /64 reçu delegation ne peut être redonné entièrement a un autre routeur.
Si on lui donne un /63 il saura donner 2 /64. c'est une limitation dans le code , le cas n'est pas prévu car en général quand on recoit un /64 c'est pour l'utiliser localement sur un autre interface (en général son LAN) et pas pour la re-déléguer a un autre équipement.
j'ai fait un peu le tour du sujet.
le principe de fonctionnement est:
client dhcpv6 sur wan: odhcp6c, il est basic, a chaque évènement dhcp il reconfigure l'interface.
pour les prefixes reçus en délégation, il appele la function proto_add_ipv6_prefix de netifd
on peut donc retrouver cette info dans netifd avec ubus:
ubus call network.interface.wan6 statuson trouvera dans le résultat:
"ipv6-prefix": [
{
"address": "2a01:xxxx:xxxx:78d1::",
"mask": 64,
"preferred": 588,
"valid": 86388,
"class": "wan6",
"assigned": {
}
}
],
la "class" correspond a "ip6class" dans uci et "IPv6 prefix filter" dans luci. Ca permet coté downstream de choisir ou pas cet upstream. Dans openwrt c'est le nom de l'interface donc. (cas ou on a plusieurs wan par exemple et qu'on veut controler qui delegue vers ou).
Une delegation s'applique localement sur une interface avec "ipassign".
En server de delegation odhcpd n'a pas beaucoup de configuration et documentation. il lit les infos via ubus mais ce sait pas donner un /64 depuis un /64 (je ne sais meme pas si la norme autorise cela d'ailleurs)
odhcpd a un attribut d'interface non documenté c'est "pd_manager" qui permet de préciser un socket (local ou réseau) vers un autre programme qui va fournit les prefixes a déléguer. Mais je n'ai rien trouver en ligne ou dans les packages openwrt qui correspondrait.
Il serait a priori pas trop compliquer d'écrire un programme compatible avec ce truc...
mais il y aussi les autres packages dhcp server dans openwrt, notamment isc et kia. ce sont un peu les "standards" dans le monde Linux donc ca vaut peut-etre le coup de tenter avec eux plutot que d'utiliser odhcpd. j'ai souvent utiliser isc mais pas dans ce contexte. jamais kia encore.
on peut aussi ouvrir un ticket https://github.com/openwrt/odhcpd/issues (ou voir si y'a deja une demande identique).
-
Merci pour tes recherches. C'est bien ce que je pensais : impossible de faire quoi que ce soit si on juste un /64.
ISC, je l'utilise aussi en DHCP principal sur mon LAN, il me servait aussi à adresser la LB quand je faisais mes tests. Niveau config, je sais pas si on peut le faire autant dynamique que odhcpd qui est très intégré au système, c'est plus fait pour de l'assignation statique... Pas testé non plus kea pour l'instant.
-
@kgersen :
Je croyais que l'idée était de fabriquer un préfixe pour parvenir à le déléguer. Combiner, par exemple, quatre /64 pour former un /62.
Si on lui donne un /63 il saura donner 2 /64. C'est une limitation dans le code , le cas n'est pas prévu car en général quand on recoit un /64 c'est pour l'utiliser localement sur un autre interface (en général son LAN) et pas pour la re-déléguer a un autre équipement.
Très étrange !
Exemple avec quatre routeurs R0, R1, R2, R3 :
R0 délègue un préfixe /64 à R1.
R1 délègue à nouveau ce préfixe /64 à R2.
R2 ne délègue pas ce préfixe /64 à R3.
-
@kgersen :
Je croyais que l'idée était de fabriquer un préfixe pour parvenir à le déléguer. Combiner, par exemple, quatre /64 pour former un /62.
Très étrange !
Exemple avec quatre routeurs R0, R1, R2, R3 :
R0 délègue un préfixe /64 à R1.
R1 délègue à nouveau ce préfixe /64 à R2.
R2 ne délègue pas ce préfixe /64 à R3.
Désolé mais je ne comprend rien a ce que tu essais de dire...
-
Désolé mais je ne comprend rien a ce que tu essais de dire...
Le serveur DHCP de la Livebox délègue un préfixe /64 à OpenWrt. Le serveur DHCP de OpenWrt devrait potentiellement déléguer ce préfixe /64 à un autre routeur.
Donc, le serveur DHCP de ce routeur pourrait-il déléguer à nouveau ce préfixe /64 à un autre routeur ? Et ainsi de suite...
Il me semble qu'il serait impossible de déléguer un préfixe /64 (non assigné à une interface) à plusieurs routeurs successifs. Je ne comprends pas la logique. Dans le
cas d'un préfixe de longueur inférieure à 64 bits, pour du routage statique, chaque interface se voit assigner un préfixe. Une partie de sa plage d'adresse est réallouée
à un client DHCP (requesting router) associé à une de ses interfaces.
P.S. : Si on ne comprend pas ce que j'essaye de dire, alors j'arrête. De mon côté, c'est inutile de persister à tourner en boucle. Et de votre côté, inutile de me répondre.
-
Le serveur DHCP de la Livebox délègue un préfixe /64 à OpenWrt. Le serveur DHCP de OpenWrt devrait potentiellement déléguer ce préfixe /64 à un autre routeur.
Donc, le serveur DHCP de ce routeur pourrait-il déléguer à nouveau ce préfixe /64 à un autre routeur ? Et ainsi de suite...
non justement c'est le problème qu'on a... il ne peut délégué un /64 à partir d'un ou meme plusieurs /64. il faut explicitement qu'il reçoive un /63 ou plus grand (/62,etc).
On pourrait éventuellement reconstruire un /63 ou plus grand mais pour cela il faudrait recevoir des /64 contiguës ce qui n'est pas le cas, la livebox distribue des /64 pris au hasard dans son /56 (ou alors elle utilise un algo non aléatoire non connu par nous). Et cette reconstruction n'est pas simple à faire de toute facon (il faut changer le script dhcpv6.script et/ou utiliser des "client scripts" perso (dans /etc/odhcp6c.user.d)
il reste la solution du relai , l'openwrt servant juste de relai mais je ne sais si ca fonctionne avec openwrt. (et les relai DHCPv6-PD peuvent poser des problemes de stabilité)
le plus 'propre' est soit d'utiliser autre chose que le client et le serveur dhcpv6 d'openwrt (odhcp6c et odhcpd), OpenWrt permettant d'en utiliser d'autres packages
soit de les modifier pour que:
* odhcp6c soit capable de demander plusieurs /64 depuis une meme interface (ceci est contournable via les interfaces mac vlan comme a fait renaud07 mais c'est un peu lourding)
* odhcpd soit capable de déléguer un /64 à partir d'un /64 *c'est le point bloquant ici*
-
J'ai installé les packages isc-dhcp sur ma VM openwrt, mais je sens que ça va pas le faire, y'a littéralement aucune automatisation du fichier de config.
S'il faut écrire autant de code que pour modifier odhcpd... autant essayer de faire fonctionner ce dernier.
-
odhcpd provides server services for DHCP, RA, stateless SLAAC and stateful DHCPv6, prefix delegation and can be used to relay RA, DHCPv6 and NDP between routed (non-bridged) interfaces in case no delegated prefixes are available.
On sait que le client DHCPv6 ne peut pas obtenir un préfixe de longueur inférieure à 64 bits. Mais en lisant le propos précédent, cela donne l'impression que odhcpd peut demander un préfixe à la Livebox.
Quelle différence avec un relais DHCP ?
Il me semble qu'on peut former une chaîne de relais DHCP. Ainsi, le préfixe /64 d'un routeur quelconque serait toujours attribué par le serveur DHCPv6 de la Livebox.
-
Il peut relayer mais pour cela il faut une interface non figurée vers la livebox, plsu précisemment une interface ou il n'a pas déjà un client dhcpv6 (udp port 546) en écoute (un seul service peut 'bind' ce port a un moment donné).
Il faut donc une interface dédiée a cela ou désactiver completement odhcp6c. C'est le relai évoqué précédemment.
-
Problème que je n'avais pas anticipé : lorsque ma connexion coupe, la LB cesse de router le préfixe en envoyant tout à 0 et openwrt reste comme un c*n sans relancer la connexion.
Y'a un paramètre pour refaire un SARR automatiquement ? Chose que j'avais totalement oublié de mettre en place aussi lorsque j'avais découplé routeur et modem, heureusement que ça coupait moins souvent, donc je le faisais à la main.
-
Que veux-tu dire par "envoyant tout à 0" ?
J'ai ca sur mon routeur pour monitorer la connexion et relancer automatiquement si besoin, si ca peut t'être utile.
#!/bin/sh
HOST=fe80::ba0:bab%eth0.832
TIMER=57
TRIES=10
CMD='killall odhcp6c; sleep 5; killall udhcpc; sleep 3h'
failcount=0
while :; do
ping -s0 -w5 -c2 ${HOST} >/dev/null
if [[ $? -ne 0 ]]; then
logger -t "${0}" -- "host ${HOST} is unreachable (try #${failcount} of ${TRIES})"
failcount=$((${failcount} + 1))
if [[ ${failcount} -ge ${TRIES} ]]; then
failcount=0
logger -t "${0}" -- "running ${CMD}"
sh -c "${CMD}"
fi
else
if [[ ${failcount} -gt 0 ]]; then
logger -t "${0}" -- "host ${HOST} is reachable"
fi
failcount=0
fi
sleep ${TIMER}
done
Le script est lancé par /etc/rc.local au boot, après un sleep de 5 minutes pour laisser le temps à la connexion de s'établir.
D'après mes logs, ca déclenche (redémarre les clients DHCP) une fois toutes les quelques semaines, toujours la nuit. Le routeur récupère le même préfixe. BNG qui reboot ?
Je ne fais rien avec l'ONT externe. Il se gère tout seul et ne m'a jamais ennuyé.
EDIT: si ta connexion coupe fréquemment, il te faudra probablement ajuster les timers... c'est fait pour une connexion stable avec déconnexion rare. Par contre si tu redémarres les clients DHCP et que la box ne s'est pas reconnectée, est-ce que ca ne risque pas de ne pas te réattribuer de préfixe ?
J'espère que tu n'obtiens pas un nouveau préfixe à chaque fois, d'ailleurs...
-
Je voulais dire les RA, elle envoie le préfixe avec un lifetime à 0 (faut que je revérifie exactement).
Merci pour script, je vais tester ça :)
-
c'est violent la commande CMD (kill ...) ...
on peut restart toutes les interfaces avec:
ubus call network restart
(cf https://openwrt.org/docs/techref/ubus#netifd)
il y a un systeme d'evenement dans openwrt : https://openwrt.org/docs/guide-user/base-system/hotplug (cf iface notamment)
Tu peux éventuellement faire un script qui réagit au prefix deprecated.
-
justement, tuer les démons marque les interfaces down et relance toute la configuration. C'est le but, et en effet, c'est pas sensé déclencher 10x par jour...
-
Quelle idée m'a pris de débrancher le RJ11 au lieu de faire un reconnect depuis la box... c'est reparti pour un sync loop :( Ça faisait 4 jours que j'avais pas perdu la connexion.
En plus je crois que j'ai pas assez resserré les timers, la connexion revient avant que tous les essais aboutissent. Sans compter que ça ping depuis la SLAAC du WAN qui revient bien plus vite, j'ai l'impression, hors il faudrait que ça soit à partir du préfixe délégué pour que ça soit en échec.
Je suis bon pour attendre des heures que ça se stabilise...