La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: basilix le 22 août 2024 à 07:19:53
-
Bonjour !
Est-ce normal que la Livebox lance ses clients DHCP à neuf minutes et trente secondes ?
Je pose la question car mon routeur OpenWrt ne parvient pas à solliciter le routeur du lien. J'essaye encore de finaliser la configuration.
Il y a plusieurs éléments qui pose problème dans ma mise en œuvre : version de développement, configuration changeante pour tester...
Néanmoins, il y a quelque jours j'étais parvenu à obtenir une connectivité IPv6.
Wed Aug 21 13:33:54 2024 daemon.notice unbound: [2820:0] notice: init module 0: respip
Wed Aug 21 13:33:54 2024 daemon.notice unbound: [2820:0] notice: init module 1: iterator
Wed Aug 21 13:33:54 2024 daemon.info unbound: [2820:0] info: start of service (unbound 1.20.0).
Wed Aug 21 13:33:54 2024 daemon.info dropbear: Using network interface 'lan' (network device 'br-lan') for direct binding
Wed Aug 21 13:34:08 2024 kern.info kernel: [ 35.622071] sfp sfp-1: module FS [redacted] [redacted] [redacted] [redacted] [redacted]
Wed Aug 21 13:34:08 2024 kern.info kernel: [ 35.671305] hwmon hwmon4: temp1_input not attached to any thermal zone
Wed Aug 21 13:34:10 2024 daemon.warn odhcpd[1780]: No default route present, overriding ra_lifetime to 0!
Wed Aug 21 13:34:10 2024 daemon.notice netifd: Network device 'lan1' link is down
Wed Aug 21 13:34:10 2024 kern.info kernel: [ 38.415070] br-lan: port 1(lan1) entered disabled state
Wed Aug 21 13:34:10 2024 kern.info kernel: [ 38.415191] mt7530-mdio mdio-bus:1f lan1: Link is Down
Wed Aug 21 13:34:11 2024 daemon.notice netifd: bridge 'br-lan' link is down
Wed Aug 21 13:34:11 2024 daemon.notice netifd: Interface 'lan' has link connectivity loss
Wed Aug 21 13:34:11 2024 daemon.warn odhcpd[1780]: No default route present, overriding ra_lifetime to 0!
Wed Aug 21 13:34:18 2024 kern.info kernel: [ 45.700695] mt7530-mdio mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control off
Wed Aug 21 13:34:18 2024 kern.info kernel: [ 45.700716] br-lan: port 1(lan1) entered blocking state
Wed Aug 21 13:34:18 2024 daemon.notice netifd: Network device 'lan1' link is up
Wed Aug 21 13:34:18 2024 daemon.notice netifd: bridge 'br-lan' link is up
Wed Aug 21 13:34:18 2024 daemon.notice netifd: Interface 'lan' has link connectivity
Wed Aug 21 13:34:18 2024 kern.info kernel: [ 45.713827] br-lan: port 1(lan1) entered forwarding state
Wed Aug 21 13:34:19 2024 daemon.warn odhcpd[1780]: No default route present, overriding ra_lifetime to 0!
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Network device 'eth1' link is up
Wed Aug 21 13:34:20 2024 daemon.notice netifd: 8021q 'eth1.832' link is up
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Interface 'wan6' has link connectivity
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Interface 'wan6' is setting up now
Wed Aug 21 13:34:20 2024 kern.info kernel: [ 48.374977] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
Wed Aug 21 13:34:20 2024 daemon.err odhcp6c[3062]: Failed to send RS (Address not available)
Wed Aug 21 13:34:21 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Aug 21 13:34:22 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Aug 21 13:34:30 2024 daemon.notice netifd: Interface 'wan6' is now up
Wed Aug 21 13:34:30 2024 user.notice firewall: Reloading firewall due to ifup of wan6 (eth1.832)
Wed Aug 21 13:34:30 2024 daemon.notice netifd: wan6 (3062): Cannot find device "wan6"
Wed Aug 21 13:34:30 2024 daemon.notice netifd: wan6 (3062): Cannot find device "wan6"
Wed Aug 21 13:34:39 2024 daemon.notice netifd: Network device 'lan1' link is down
Wed Aug 21 13:34:39 2024 kern.info kernel: [ 66.821016] br-lan: port 1(lan1) entered disabled state
Wed Aug 21 13:34:39 2024 kern.info kernel: [ 66.821135] mt7530-mdio mdio-bus:1f lan1: Link is Down
Wed Aug 21 13:34:40 2024 daemon.notice netifd: bridge 'br-lan' link is down
Wed Aug 21 13:34:40 2024 daemon.notice netifd: Interface 'lan' has link connectivity loss
Wed Aug 21 13:34:40 2024 daemon.warn odhcpd[1780]: No default route present, overriding ra_lifetime to 0!
Wed Aug 21 13:34:43 2024 kern.info kernel: [ 71.167357] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx
Wed Aug 21 13:34:43 2024 kern.info kernel: [ 71.167378] br-lan: port 1(lan1) entered blocking state
Wed Aug 21 13:34:43 2024 kern.info kernel: [ 71.180485] br-lan: port 1(lan1) entered forwarding state
Wed Aug 21 13:34:43 2024 daemon.notice netifd: Network device 'lan1' link is up
Wed Aug 21 13:34:43 2024 daemon.notice netifd: bridge 'br-lan' link is up
Wed Aug 21 13:34:43 2024 daemon.notice netifd: Interface 'lan' has link connectivity
Wed Aug 21 16:30:06 2024 authpriv.info dropbear[3259]: Child connection from [redacted]
Wed Aug 21 16:30:06 2024 user.info : Binding to interface 'br-lan'
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: service stopped (unbound 1.20.0).
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: server stats for thread 0: [redacted] queries, [redacted] answers from cache, [redacted] recursions, [redacted] prefetch, [redacted] rejected by ip ratelimiting
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: server stats for thread 0: requestlist max [redacted] avg [redacted] exceeded [redacted] jostled 0
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: average recursion processing time [redacted] sec
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: histogram of recursion processing times
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: [25%]=[redacted] median[50%]=[redacted] [75%]=[redacted]
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: lower(secs) upper(secs) recursions
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: [redacted] [redacted] [red]
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: [redacted] [redacted] [red]
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: [redacted] [redacted] [red]
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: [redacted] [redacted] [red]
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: [redacted] [redacted] [red]
Wed Aug 21 16:30:10 2024 daemon.info unbound: [2820:0] info: [redacted] [redacted] [red]
Wed Aug 21 16:30:10 2024 daemon.notice unbound: [3460:0] notice: init module 0: respip
Wed Aug 21 16:30:10 2024 daemon.notice unbound: [3460:0] notice: init module 1: iterator
Dans le journal :
Wed Aug 21 13:34:20 2024 daemon.err odhcp6c[3062]: Failed to send RS (Address not available)
Wed Aug 21 13:34:21 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Aug 21 13:34:22 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
-
Ma question est peut-être naïve. J'essaye de dissocier au mieux la source des dysfonctionnements.
-
Normalement le délai d'auto-configuration n'a rien à voir avec l'erreur que tu vois dans le log. Il me *semble* que c'est un problème avec la version de OpenWRT.
Pour une raison inconnue, le client odhp6 n'arrive pas à envoyer des paquets. J'ai trouvé le suivant dans les forums OpenWrt : https://forum.openwrt.org/t/openwrt-22-03-2-frequent-disconnects-odhcp6c-5287-failed-to-send-solicit-message-to-ff02-2-network-unreachable/148454/5 (https://forum.openwrt.org/t/openwrt-22-03-2-frequent-disconnects-odhcp6c-5287-failed-to-send-solicit-message-to-ff02-2-network-unreachable/148454/5)
Il faut vérifier que ton intérface WAN ait une adresse IPv6 Link-Local (e.g. FE80::/10)
-
Comment constates tu que la Livebox (re)lance ses clients DHCP après 9min30? Les livebox sont connues pour être lentes à démarrer, mais 9 minutes me semble extreme. Tu as une capture ?
Pour ton souci d'OpenWRT, j'opterai pour un problème de configuration :
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Network device 'eth1' link is up
Wed Aug 21 13:34:20 2024 daemon.notice netifd: 8021q 'eth1.832' link is up
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Interface 'wan6' has link connectivity
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Interface 'wan6' is setting up now
Wed Aug 21 13:34:20 2024 kern.info kernel: [ 48.374977] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
L'interface vient d'être configurée et le lien vient de monter.
Wed Aug 21 13:34:20 2024 daemon.err odhcp6c[3062]: Failed to send RS (Address not available)
Wed Aug 21 13:34:21 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Aug 21 13:34:22 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
J'ai aussi ces messages et pour moi, si ils n'apparaissent que temporairement après la configuration d'une interface, ils sont sans danger.
Pour envoyer un router sollicitation, odhcp6c a besoin qu'une adresse source link local soit configurée sur l'interface.
Or, pendant les premières secondes suivant le passage en up de l'interface, une telle adresse est bien automatiquement générée par le kernel, mais elle n'est pas tout de suite utilisable : le processus de Duplicate Address Detection vérifie d'abord qu'elle n'existe pas déjà sur le lien. Ce processus prend environ 1-2s, et tant qu'il n'est pas fini, les tentatives d'émission avec cette adresse source échouent avec Address not available.
Une fois le processus terminé, si l'adresse est bien unique sur le lien, les tentatives d'émission n'auront pas d'erreur.
Wed Aug 21 13:34:30 2024 daemon.notice netifd: Interface 'wan6' is now up
Wed Aug 21 13:34:30 2024 user.notice firewall: Reloading firewall due to ifup of wan6 (eth1.832)
Wed Aug 21 13:34:30 2024 daemon.notice netifd: wan6 (3062): Cannot find device "wan6"
Wed Aug 21 13:34:30 2024 daemon.notice netifd: wan6 (3062): Cannot find device "wan6"
Wed Aug 21 13:34:39 2024 daemon.notice netifd: Network device 'lan1' link is down
netifd a un souci avec la configuration de wan6, et potentiellement de lan1 également. N'aurais tu pas confondu ou interverti wan6 et lan1 dans un fichier de configuration ?
Tu peux éventuellement poster /etc/config/network ici, en omettant tes chaines d'authentification DHCP.
-
@fttmeh:
13: eth1.832@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 09:21:59:5C:F0:07 brd ff:ff:ff:ff:ff:ff
inet6 fe80::0921:59ff:fe5c:f007/64 scope link
valid_lft forever preferred_lft forever
@simon:
root@OpenWrt:~$ sudo ifstatus wan6
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 849,
"l3_device": "eth1.832",
"proto": "dhcpv6",
"device": "eth1.832",
"updated": [
"routes",
"prefixes",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
],
"ipv6-address": [
],
"ipv6-prefix": [
{
"address": "2a01:db8:85a3:3f00::",
"mask": 56,
"preferred": 603951,
"valid": 603951,
"class": "wan6",
"assigned": {
"lan": {
"address": "2a01:db8:85a3:3f00::",
"mask": 60
}
}
}
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "::",
"mask": 0,
"nexthop": "fe80::ba0:bab",
"metric": 512,
"valid": 3651,
"source": "2a01:db8:85a3:3f00::/56"
}
],
"dns-server": [
],
"dns-search": [
"XXX.xxxxx.orange-xxxxxx.net"
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
"passthru": "d2f6d76ceb66471ac4b5cd2af4422418bfeddb29c12f9d8d87eb95d708aa0a1e"
}
}
Pourtant, j'ai refait ma configuration à zéro plusieurs fois avec différentes images du micrologiciel OpenWrt (versions snapshot, version 23.05.4).
Lorsque je relance l'inferface ifdow wan6 puis ifup wan6, il n'y a plus d'infos de configuration provenant de Orange dans la sortie de ifstatus wan6.
-
package network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1/8'
option ip6addr '::1/128'
config globals 'globals'
option ula_prefix 'fd65:c6ad:93db::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'sfp2'
list ports 'wan'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1/24'
option ip6assign '60'
config device
option type '8021q'
option ifname 'eth1'
option vid '832'
option name 'eth1.832'
list egress_qos_mapping '6:6'
config interface 'wan'
option device 'eth1.832'
option proto 'dhcp'
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90 119 120 125'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835 90:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
option clientid '1512372786bc5'
option disabled '1'
config interface 'wan6'
option device 'eth1.832'
option proto 'dhcpv6'
option reqaddress 'none'
option reqprefix 'auto'
option sendopts '11:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 15:FSVDSL_livebox.Internet.softathome.Livebox5 16:0000040e0005736167656d'
option noclientfqdn '1'
option clientid '00030001512372786bc5'
config device
option name 'eth1'
option macaddr '51:23:72:78:6B:C5'
Je reçois bien les paramètres de configuration DHCPv6. L'interface br-lan reçoit une adresse unicast globale (GUA). Mais pas ma station ni l'interface eth1.832.
Je pense que le problème vient d'ailleurs comme l'a indiqué @simon, l'interface br-lan et lan1.
-
C'est sur qu'on peut réussir en tout cas, on est nombreux à l'avoir fait :)
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'sfp2'
list ports 'wan'
Les ports 'wan' et 'sfp2' sont dans le bridge br-lan, c'est voulu ?
C'est quoi comme routeur ? Il y a un port SFP ? Si oui, est-ce qu'un ONT est connecté dessus ?
Peux-tu essayer de sortir 'wan' et 'sfp2' du bridge ?
Note que l'interface eth1.832 (celle qui fait face à l'ONT) n'a pas besoin d'une adresse GUA. Chez moi, il n'y en a pas. Le routeur est joignable par les GUA assignées à ses autres VLANs.
-
@simon :
C'est une carte de développement : le Bananapi BPI-R3. Il a deux ports SFP. Une des cages SFP est reliée à une MAC (eth1) et l'autre au commutateur interne (eth0).
Le port wan est un port du commutateur et peut servir soit pour une connexion wan ou alors lan. Mais cela m'étonnerait beaucoup que le problème vienne de là.
Je crois qu'on peut faire abstraction de tout cela à cause de la technologie Distributed Switch Architecture.
C'est vraiment bizarre !
L'autre jour, tout fonctionnait correctement en IPv6 sur ce routeur. Ensuite, j'ai modifié régulièrement la configuration pour réaliser d'autres tests. J'essayais d'intégrer un correctif dans
le client DHCPv4 udhcpc de OpenWrt (https://lafibre.info/remplacer-livebox/patch-udhcpc6-soumis-sur-la-liste-de-diffusion-busybox/) pour modifier la priorité interne des paquets DHCPv4. Pour être sûr, j'ai également vérifié l'état de la carte SD (cela semble OK).
Ma configuration personnalisée faisait appel à odhcpd et unbound. J'ai recommencé les tests avec dnsmasq et odhcpd-ipv6 sur OpenWrt v23.05.4.
-
Je vois bien passer les requêtes ICMPv6 NS et NA et j'obtiens un préfixe IPv6. Mais pour le reste, cela ne fonctionne pas la connexion.
Je vais reprendre ma configuration et réessayer en simplifiant, voire en compilant les sources si vraiment rien ne passe. Je me suis
aperçu que le module kmod-nft-arp n'était pas chargé dans l'image officielle de la version 23.05.4. Or, j'en ai besoin afin de modifier
le PCP des paquets ARP. J'ai sûrement fait une erreur quelque part ou alors c'est un dysfonctionnement qui tombe au plus mal. En
plus c'est super chiant de répéter les même opérations et de regarder « à la loupe ».
-
Tu peux executer les commandes suivantes et poster leur resultat ?
ip a
ip -6 r
ip n
ps w
-
J'ai fait comme j'ai pu pour modifier les informations sensibles.
root@OpenWrt:~# ip ad
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::b874:87ff:feba:dce9/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 8d:4e:2a:bc:b9:b0 brd ff:ff:ff:ff:ff:ff permaddr ba:74:87:ba:dc:ea
inet6 fe80::8d4e:2aff:febc:b9b0/64 scope link
valid_lft forever preferred_lft forever
4: wan@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
5: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
6: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
7: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
8: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
9: sfp2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
10: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ce:a8:ac:b7:c0:5e brd ff:ff:ff:ff:ff:ff
11: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether cf:44:c5:da:03:05 brd ff:ff:ff:ff:ff:ff
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether ba:74:87:ba:dc:e9 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 2001:db8:7d8b:c65b::1/64 scope global dynamic noprefixroute
valid_lft 604757sec preferred_lft 604757sec
inet6 fd62:ceca:732c::1/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::b874:87ff:feba:dce9/64 scope link
valid_lft forever preferred_lft forever
13: eth1.832@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 8d:4e:2a:bc:b9:b0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::8d4e:2aff:febc:b9b0/64 scope link
valid_lft forever preferred_lft forever
root@OpenWrt:~# ip -6 r
default from 2001:db8:7d8b:c65b::/56 via fe80::ba0:bab dev eth1.832 proto static metric 512 pref medium
2001:db8:7d8b:c65b::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2001:db8:7d8b:c65b::/56 dev lo proto static metric 2147483647 pref medium
fd62:ceca:732c::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd62:ceca:732c::/48 dev lo proto static metric 2147483647 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth1.832 proto kernel metric 256 pref medium
root@OpenWrt:~# ip n
192.168.1.151 dev br-lan lladdr 45:24:65:72:37:80 REACHABLE
fe80::ba0:bab dev eth1.832 lladdr 1b:c2:52:4e:22:3a router STALE
fe80::8d4e:2aff:febc:b9b0 dev eth1.832 lladdr 8d:4e:2a:bc:b9:b0 STALE
fd62:ceca:732c::8b6 dev br-lan lladdr 45:24:65:72:37:80 REACHABLE
fe80::f560:e3b9:9f54:3e70 dev br-lan lladdr 45:24:65:72:37:80 STALE
L'adresse MAC 45:24:65:72:37:80 est celle de ma station. L'adresse MAC 8d:4e:2a:bc:b9:b0 est celle clonée de la Livebox.
root@OpenWrt:~# ps w
PID USER VSZ STAT COMMAND
1 root 1868 S /sbin/procd
2 root 0 SW [kthreadd]
3 root 0 IW< [rcu_gp]
4 root 0 IW< [rcu_par_gp]
5 root 0 IW< [slub_flushwq]
6 root 0 IW< [netns]
7 root 0 IW [kworker/0:0-dev]
8 root 0 IW< [kworker/0:0H-mm]
9 root 0 IW [kworker/u8:0-ev]
10 root 0 IW< [mm_percpu_wq]
11 root 0 SW [rcu_tasks_trace]
12 root 0 SW [ksoftirqd/0]
13 root 0 IW [rcu_sched]
14 root 0 SW [migration/0]
15 root 0 SW [cpuhp/0]
16 root 0 SW [cpuhp/1]
17 root 0 SW [migration/1]
18 root 0 SW [ksoftirqd/1]
19 root 0 IW [kworker/1:0-rcu]
20 root 0 IW< [kworker/1:0H-ev]
21 root 0 SW [cpuhp/2]
22 root 0 SW [migration/2]
23 root 0 SW [ksoftirqd/2]
24 root 0 IW [kworker/2:0-rcu]
25 root 0 IW< [kworker/2:0H-ev]
26 root 0 SW [cpuhp/3]
27 root 0 SW [migration/3]
28 root 0 SW [ksoftirqd/3]
29 root 0 IW [kworker/3:0-dev]
30 root 0 IW< [kworker/3:0H-kb]
31 root 0 IW< [inet_frag_wq]
32 root 0 IW [kworker/0:1-rcu]
33 root 0 SW [oom_reaper]
34 root 0 IW< [writeback]
35 root 0 SW [kcompactd0]
41 root 0 IW [kworker/3:1-mm_]
45 root 0 IW< [pencrypt_serial]
46 root 0 IW< [pdecrypt_serial]
47 root 0 IW [kworker/1:1-rcu]
48 root 0 IW< [cryptd]
51 root 0 IW [kworker/2:1-eve]
74 root 0 IW< [kblockd]
75 root 0 IW< [blkcg_punt_bio]
76 root 0 IW< [ata_sff]
77 root 0 IW [kworker/1:2-eve]
78 root 0 SW [watchdogd]
79 root 0 IW [kworker/1:3-rcu]
80 root 0 IW [kworker/u8:1-ev]
81 root 0 IW< [kworker/1:1H-kb]
113 root 0 IW [kworker/u8:2-ev]
118 root 0 SW [kswapd0]
121 root 0 IW< [kthrotld]
139 root 0 IW [kworker/2:2-dev]
243 root 0 SW [hwrng]
244 root 0 IW [kworker/2:3-eve]
245 root 0 IW [kworker/2:4-dev]
246 root 0 IW [kworker/2:5-rcu]
247 root 0 IW [kworker/2:6-rcu]
276 root 0 IW< [iscsi_eh]
277 root 0 IW< [iscsi_conn_clea]
288 root 0 IW [kworker/u8:3-ev]
290 root 0 SW [spi0]
319 root 0 SW [spi1]
320 root 0 IW [kworker/1:4-rcu]
372 root 0 IW [kworker/0:2-dev]
373 root 0 IW [kworker/0:3-dev]
374 root 0 IW [kworker/0:4-dev]
415 root 0 SW [napi/mtk_eth-5]
416 root 0 SW [napi/mtk_eth-6]
448 root 0 IW< [mld]
449 root 0 IW [kworker/0:5-eve]
450 root 0 IW [kworker/0:6-rcu]
451 root 0 IW [kworker/0:7]
452 root 0 IW< [ipv6_addrconf]
453 root 0 IW< [kworker/2:1H-kb]
460 root 0 IW [kworker/3:2-dev]
461 root 0 IW [kworker/3:3-dev]
462 root 0 IW [kworker/3:4-dev]
463 root 0 IW [kworker/3:5-eve]
464 root 0 IW [kworker/3:6-rcu]
465 root 0 IW [kworker/3:7]
466 root 0 IW< [dsa_ordered]
467 root 0 IW< [kstrp]
480 root 0 IW< [mmc_complete]
482 root 0 IW< [kworker/0:1H-mm]
501 root 0 SW [irq/145-aerdrv]
510 root 0 SW [irq/82-mt7530]
558 root 0 SW [ubi_bgt0d]
563 root 0 IW< [kworker/3:1H-kb]
715 root 0 SW [f2fs_ckpt-259:1]
716 root 0 SW [f2fs_flush-259:]
717 root 0 SW [f2fs_discard-25]
718 root 0 SW [f2fs_gc-259:1]
804 ubus 1376 S /sbin/ubusd
805 root 908 S /sbin/askfirst /usr/libexec/login.sh
840 root 1064 S /sbin/urngd
922 root 0 SW [irq/117-1032000]
923 root 0 IW< [wq_ring0]
924 root 0 SW [irq/118-1032000]
925 root 0 IW< [wq_ring1]
926 root 0 SW [irq/119-1032000]
927 root 0 IW< [wq_ring2]
928 root 0 SW [irq/120-1032000]
929 root 0 IW< [wq_ring3]
995 root 0 SW [irq/65-sfp-1-mo]
996 root 0 SW [irq/62-sfp-1-lo]
997 root 0 SW [irq/23-sfp-1-tx]
1001 root 0 SW [irq/63-sfp-2-mo]
1002 root 0 SW [irq/47-sfp-2-lo]
1003 root 0 SW [irq/64-sfp-2-tx]
1011 root 0 IW< [cfg80211]
1020 root 0 SW [napi/phy0-7]
1021 root 0 SW [napi/phy0-8]
1022 root 0 SW [napi/phy0-9]
1023 root 0 SW [napi/phy0-10]
1024 root 0 SW [napi/phy0-11]
1025 root 0 SW [napi/phy0-12]
1033 root 0 SW [mt76-tx phy0]
1254 logd 1332 S /sbin/logd -S 64
1314 root 3600 S /sbin/rpcd -s /var/run/ubus/ubus.sock -t 30
1541 root 1108 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -s -g -p 22 -K 300 -T 3 -W 262144
1645 root 2764 S {hostapd} /sbin/ujail -t 5 -n hostapd -U network -G network -C /etc/capabilities/wpad.json -c -- /usr/sbi
1646 root 2764 S {wpa_supplicant} /sbin/ujail -t 5 -n wpa_supplicant -U network -G network -C /etc/capabilities/wpad.json
1648 network 4496 S /usr/sbin/hostapd -s -g /var/run/hostapd/global
1649 network 4460 S /usr/sbin/wpa_supplicant -n -s -g /var/run/wpa_supplicant/global
1710 root 2040 S /sbin/netifd
1826 root 1720 S /usr/sbin/odhcpd
1942 root 2756 S /usr/sbin/uhttpd -f -h /www -r OpenWrt -x /cgi-bin -u /ubus -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -R -p 0.0.
2359 root 2764 S {ntpd} /sbin/ujail -t 5 -n ntpd -U ntp -G ntp -C /etc/capabilities/ntpd.json -c -u -r /bin/ubus -r /usr/b
2381 ntp 1316 S /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.ntp.org -p 2.o
2659 root 2764 S {dnsmasq} /sbin/ujail -t 5 -n dnsmasq -u -l -r /bin/ubus -r /etc/TZ -r /etc/dnsmasq.conf -r /etc/ethers -
2665 dnsmasq 1648 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
2935 root 1076 S odhcp6c -s /lib/netifd/dhcpv6.script -Nnone -P0 -c00030001709741c2f4d5 -f -r11 -r17 -r23 -r24 -x11 000000
3089 root 1132 R /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -s -g -p 22 -K 300 -T 3 -W 262144 -2 9
3090 root 1328 S -ash
3102 root 1324 R ps w
-
Super.
Côté IPv6, tout semble en ordre :
- odhcp6c est lancé sur eth1.832 et tu obtiens bien un /56 (2001:db8:7d8b:c65b::/56),
- le premier /64 est assigné à br-lan (2001:db8:7d8b:c65b::/64), et le routeur s'assigne 2001:db8:7d8b:c65b::1 sur cette interface,
- le routeur d'Orange est joignable sur eth1.832 (fe80::ba0:bab dev eth1.832 lladdr 1b:c2:52:4e:22:3a),
- odhcpd est lancé, il devrait annoncer 2001:db8:7d8b:c65b::/64 sur br-lan et ses ports associés,
- la résolution NDP marche bien côté LAN, puisque la MAC de ta station est bien dans le cache.
-> à priori, la connectivité IPv6 devrait être OK. Est-ce que des adresses IPv6 se configurent bien sur ta/tes stations ? Tu peux rejouer ip a et ip -6 r sur cette station pour voir (linux), ifconfig -a (macOS) ou encore ipconfig /all (windows).
Tu peux aussi faire des traceroute/tracert/mtr pour regarder ou ca coince, et poster ici le résultat si besoin.
Pour écarter tout souci, je commenterai la section
config globals 'globals'
option ula_prefix 'fd65:c6ad:93db::/48'
du fichier /etc/config/network si tu n'as pas l'utilité d'un préfixe ULA, ou au moins juste le temps de faire tes tests.
Si des adresses IPv6 sont bien configurées sur les stations, tu peux regarder du côté du firewall du routeur éventuellement (il ne faut pas le désactiver, hein :-) mais vérifier que les règles sont cohérentes).
En IPv4, le client DHCPv4 ne tourne pas et tu n'as pas d'adresse IPv4 publique. Tu n'as donc pas de connectivité IPv4.
Vu que tu utilises dnsmasq et qu'Orange n'annonce pas encore de DNS IPv6 par DHCPv6, la résolution DNS ne va pas fonctionner en tant que tel.
En partant du principe que tu n'as pas volontairement désactivé IPv4, je me demande tout de même si l'interface physique 'wan' et la connectivité IPv4 'wan' ne se marchent pas dessus, vu qu'elles ont le même nom.
Peux-tu faire un ifstatus wan et poster le résultat ici?
Ensuite, pourrais-tu tenter de renommer la configuration IPv4 en 'wan4'? i.e.
config interface 'wan'
option device 'eth1.832'
devient
config interface 'wan4'
option device 'eth1.832'
attention: l'interface physique wan ne change pas.
Il faudra potentiellement ajuster des règles de firewall suite à ce changement, même si je pense que luci fait bien les choses.
-
Vu que tu utilises dnsmasq et qu'Orange n'annonce pas encore de DNS IPv6 par DHCPv6, la résolution DNS ne va pas fonctionner en tant que tel.
ça fait quelques mois qu'orange annonce des dns ipv6 après une requête dhcpv6, sauf si j'ai pas compris ce que tu as voulu dire :)
Jerem
-
Je pense que ce qui manque est l’annonce du serveur DNS dans le RA (option RDNSS)
-
@simon : Merci pour ton aide ! J'ai repris la configuration usine seulement pour trouver l'origine du problème. Sinon, j'avais installé le DNS récursif unbound et cela fonctionnait en IPv6.
Je vais tester cela.
-
@jeremyp3 : Non, tous les clients n'ont pas encore de serveurs DNS IPv6 annoncés par Orange. C'est mon cas.
-
[basilix@WORKSTATION ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 45:24:65:72:37:80 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0
valid_lft 43148sec preferred_lft 43148sec
inet6 fd62:ceca:732c::8b6/128 scope global dynamic noprefixroute
valid_lft 43145sec preferred_lft 43145sec
inet6 2001:db8:7d8b:c65b::8b6/128 scope global dynamic noprefixroute
valid_lft 43145sec preferred_lft 43145sec
inet6 2001:db8:7d8b:c65b:f569:11f4:f8c8:841f/64 scope global dynamic noprefixroute
valid_lft 604004sec preferred_lft 604004sec
inet6 fd62:ceca:732c:0:a4a7:2d33:4294:3c69/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::a6b2:e672:1f13:052b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:6d:e1:93:bd:ed brd ff:ff:ff:ff:ff:ff permaddr f4:ce:23:06:f9:05
[basilix@WORKSTATION ~]$ ip -6 r
2001:db8:7d8b:c65b::8b6 dev enp3s0 proto kernel metric 100 pref medium
2001:db8:7d8b:c65b::/64 dev enp3s0 proto ra metric 100 pref medium
2001:db8:7d8b:c65b::/56 via fe80::b874:87ff:feba:dce9 dev enp3s0 proto ra metric 100 pref medium
fd62:ceca:732c::8b6 dev enp3s0 proto kernel metric 100 pref medium
fd62:ceca:732c::/64 dev enp3s0 proto ra metric 100 pref medium
fd62:ceca:732c::/48 via fe80::b874:87ff:feba:dce9 dev enp3s0 proto ra metric 100 pref medium
fe80::/64 dev enp3s0 proto kernel metric 1024 pref medium
default via fe80::b874:87ff:feba:dce9 dev enp3s0 proto ra metric 20100 pref medium
-
Je crois comprendre ce qui s'est passé.
La connexion Orange est fonctionnelle.
[basilix@WORKSTATION ~] ping 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888) 56 octets de données
64 octets de 2001:4860:4860::8888 : icmp_seq=1 ttl=115 temps=10.3 ms
64 octets de 2001:4860:4860::8888 : icmp_seq=2 ttl=115 temps=9.58 ms
^C
--- statistiques ping 2001:4860:4860::8888 ---
2 paquets transmis, 2 reçus, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 9.575/9.913/10.252/0.338 ms
L'interface graphique de ma station affichait « connexion réseau limitée (pas de connexion Internet) ». À ce moment là, j'ai dû lancer
ip addr show eth1.832 sur mon routeur pour vérifier que l'interface « WAN » recevait une IPv6. Ce qui n'était pas le cas. Dans
toute cette complexité j'ai confondu les choses et j'en suis ensuite parvenu à penser que ma connexion IPv6 dysfonctionnait. C'est ce
que j'obtiens avec la configuration usine en reprenant les paramètres du tutoriel OpenWrt (Note : sendopts ne devrait pas spécifier
l'option 17 (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/)). Il faut dire que je n'avais pas vraiment suivi le tutoriel lors de l'élaboration de ma configuration.
Il faut maintenant que je revois ma configuration de l'image de développement.
-
ça fait quelques mois qu'orange annonce des dns ipv6 après une requête dhcpv6, sauf si j'ai pas compris ce que tu as voulu dire :)
Tu as bien compris :) mais à priori ce n'est pas encore déployé dans mon coin. J'utilise mon propre resolver donc ca n'a pas d'importance pour mon setup.
-
@simon : Merci pour ton aide ! J'ai repris la configuration usine seulement pour trouver l'origine du problème. Sinon, j'avais installé le DNS récursif unbound et cela fonctionnait en IPv6.
Je vais tester cela.
Ton PC a bien l'air d'avoir une connectivité IPv6, c'est tout bon alors ?
Unbound, c'est très bien ! Tu peux même l'utiliser pour faire du DNS64, ce que je fais.
J'ai également un NAT64 sur le routeur (tayga) et je tourne en IPv6 only sur mes VLANs. On peut configurer odhcpcd pour qu'il émette dans les RA tout ce qu'il faut pour bien supporter les réseaux IPv6-only (RDNSS et PREF64).
-
@simon : Je n'ai pas encore testé sur l'image de développement. Mais sur l'image de production (version publiée) cela fonctionne.
Je prévoyais également de faire de l'IPv6 sur le réseau local et la traduction d'adresse IPv6/IPv4 sur le routeur avec Jool (NAT64 avec état).
Mais il est mal intégré à OpenWrt (script d'initialisation SysV. et pas avec procd). Je l'ai signalé mais on m'a alors fait remarquer que je
pouvais aussi m'impliquer afin de l'améliorer. Lors de mon test, dans certains cas, Jool ne se configurait pas automatiquement. L'intégration
actuelle ne me semble pas robuste ou effective.
J'ai plusieurs VLANs mais curieusement j'ai choisi de désactiver SLAAC et d'avoir du DHCPv6 partout. Je devrais faire tourner un serveur
Web dans une DMZ (créée avec le pare-feu de OpenWrt). Mais peut-être que c'est inutile si le préfixe IPv6 reste stable sur une longue période.
Pour les informations RDNSS et PREF64 j'avais déjà vu cela dans l'excellent MOOC « Objectif IPv6 ».
-
Tu as bien compris :) mais à priori ce n'est pas encore déployé dans mon coin. J'utilise mon propre resolver donc ca n'a pas d'importance pour mon setup.
Idem ici, sont pas pressés. Mais vu que j'ai aussi mon DNS perso, ça ne change pas grand chose.
ça fait quelques mois qu'orange annonce des dns ipv6 après une requête dhcpv6, sauf si j'ai pas compris ce que tu as voulu dire :)
C'est quoi l'adresse ? J'ai envie de tester par curiosité voir si ça répond vu que c'est pas encore déployé.
-
C'est quoi l'adresse ? J'ai envie de tester par curiosité voir si ça répond vu que c'est pas encore déployé.
il se peut que ça soit différent selon les régions, mais moi j'ai:
option dhcp6.name-servers 2a01:cfc4:2000:e::1,2a01:cfc4:2180:4000::1;
-
En partant du principe que tu n'as pas volontairement désactivé IPv4, je me demande tout de même si l'interface physique 'wan' et la connectivité IPv4 'wan' ne se marchent pas dessus, vu qu'elles ont le même nom.
Peux-tu faire un ifstatus wan et poster le résultat ici?
En fait, j'avais volontairement désactivé mon interface wan (L3). Je n'ai pas encore pu ajouter le correctif du client DHCPv4 permettant de changer la priorité Linux interne des paquets.
Aujourd'hui, en construisant l'image par compilation, j'ai malencontreusement oublié de la désactiver à nouveau. Bizarrement, l'interface a tout de même reçue une adresse IPv4 publique.
À priori, c'est celle attribuée à la Livebox, après avoir intervertis la Livebox et le routeur.
J'ai eu le même problème qu'auparavant lorsque j'ai lancé le routeur avec l'image construite avec la version snapshot. Aucune connectivité IPv6 (tel qu'indiqués par ip a et ifstatus wan6).
Il semblerait que cela ne fonctionnait pas parce que je lançais en parallèle le redémarrage du routeur par SSH et, après un court laps de temps, ma station. J'en avais plus que marre de tout
éteindre et démarrer : éteindre ma station, éteindre le routeur, démarrer le routeur, démarrer ma station.
L'interface L3 wan recevait une IPv4 publique mais pas d'adresse IPv6 globale (la Livebox attribue quant à elle une GUA a son interface wan). Tout fonctionne semble fonctionner en IPv6 !
-
Par contre, je me demandais si c'était normal que l'état des interfaces change de REACHABLE à STALE ?
root@OpenWrt:~# ip n
192.168.1.151 dev br-lan lladdr 45:24:65:72:37:80 REACHABLE
fe80::ba0:bab dev eth1.832 lladdr 1b:c2:52:4e:22:3a router STALE
fe80::8d4e:2aff:febc:b9b0 dev eth1.832 lladdr 8d:4e:2a:bc:b9:b0 STALE
fd62:ceca:732c::8b6 dev br-lan lladdr 45:24:65:72:37:80 REACHABLE
fe80::f560:e3b9:9f54:3e70 dev br-lan lladdr 45:24:65:72:37:80 STALE
-
Yes, c'est normal. L'état est à REACHABLE juste après un échange NDP ou ARP, puis passe en STALE après l'expiration d'un timer. Si l'entrée est utilisée, elle va être rafraichie (nouvel échange NDP ou ARP) et repasser en REACHABLE, mais si elle ne l'est pas, elle peut rester en STALE un bout de temps.
-
C'est formidable, j'ai réussi à intégrer le correctif du client DHCPv4 dans OpenWrt. Le seul bémol est qu'il faut partir du code source et que
j'utilise la version snapshot. Pour une raison inconnue, je parviens à modifier le DSCP des paquets DHCPv4/v6 avec les règles suivantes
mais cela ne fonctionne pas avec la priorité interne Linux (meta priority set 0:6).
table netdev filter {
chain egress {
type filter hook egress device "eth1" priority filter; policy accept;
udp dport 547 ip6 dscp set cs6 comment "Set DSCP value to 6 for DHCPv6 packets"
udp dport 67 ip dscp set cs6 comment "Set DSCP value to 6 for DHCPv4 packets"
}
}
-
Ca marche aussi si tu le fais sur la table ip/ip6 et sur la chaine output ? Histoire que le filter n'impacte pas trop les perfs pour les paquets forwardés ?
Par contre, j'ai un peu de mal à suivre. Le patch applique la CoS au niveau Ethernet, mais pas DSCP, donc tu utilises nftables pour modifier le DSCP ?
Je crois que la valeur du champ DSCP n'a aucune importance, c'est bien la CoS Ethernet qui compte chez Orange. Mais tu le fais peut-être pour la science :)
-
C'est le grand chef qui l'a dit « [...] et idéalement changer aussi le DSCP ». ;)
OpenWrt a ajouté une option dans leur client DHCPv6 pour définir la priorité interne. La même personne, il me semble, a développé un correctif équivalent pour le client
DHCPv4 udhcpc intégré à BusyBox (note). J'ai calqué l'intégration de la fonctionnalité skpriority de odhcp6c dans OpenWrt. Ainsi, les « raw sockets » ne font plus défaut
par rapport au PCP (priority code point, CoS).
Les autres paquets dont il faut modifier le PCP ou le DSCP peuvent l'être via des règles nftables.
table arp filter
flush table arp filter
table arp filter {
chain output {
type filter hook output priority filter; policy accept;
oifname "eth1.832" meta priority set 0:6 counter
}
}
oifname "eth1.832" icmpv6 type { 133, 135, 136 } meta priority set 0:6 ip6 dscp set cs6 counter
Note : Le correctif n'a pas été intégré à BusyBox. Mais on peut l'intégrer via le mécanisme de patch QUILT (et en faisant quelques ajouts) dans le BusyBox de OpenWrt.
-
Le problème est réapparu.
J'étais parvenu à faire fonctionner deux images sur des cartes mémoires différentes. Désormais, aucune n'a une connectivité IPv6 valide.
La première image fonctionnait avec unbound et odhpcd. La seconde image fonctionnait avec dnsmaq, unbound et odhcpd-ipv6-only.
Les deux images étaient compilé à partir du code source en version snapshot. Quelle galère à tout configurer ! Je trouve qu'il y a beaucoup
de dysfonctionnements.
-
il se peut que ça soit différent selon les régions, mais moi j'ai:
option dhcp6.name-servers 2a01:cfc4:2000:e::1,2a01:cfc4:2180:4000::1;
Merci. Ça fonctionne bien chez moi aussi, mais toujours rien dans les réponses DHCPv6.
-
C'est différent, car étant dans le nord-est, j'en ai d'autres.
Cela doit être sectorisé comme en IPv4.
-
C'est différent, car étant dans le nord-est, j'en ai d'autres.
Pour notre info, peux-tu les partager ?
-
Pour ma part: 2a01:cfc4:2000:4::12 et 2a01:cfc4:2000:2::11
-
Sur les 4 préfixes, voici ceux que j'ai trouvé en plus. Si vous ne savez pas quoi choisir...
2a01:cfc4:2000:e::1
2a01:cfc4:2000:e::2
2a01:cfc4:2180:4000::1
2a01:cfc4:2180:4000::2
2a01:cfc4:2000:4::2
2a01:cfc4:2000:4::5
2a01:cfc4:2000:4::7
2a01:cfc4:2000:4::8
2a01:cfc4:2000:4::9
2a01:cfc4:2000:4::10
2a01:cfc4:2000:4::12
2a01:cfc4:2000:4::13
2a01:cfc4:2000:4::14
2a01:cfc4:2000:2::2
2a01:cfc4:2000:2::3
2a01:cfc4:2000:2::4
2a01:cfc4:2000:2::5
2a01:cfc4:2000:2::6
2a01:cfc4:2000:2::7
2a01:cfc4:2000:2::9
2a01:cfc4:2000:2::10
2a01:cfc4:2000:2::11
2a01:cfc4:2000:2::12