La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G SFR / RED => 
5G/4G SFR => Discussion démarrée par: kriss le 14 avril 2023 à 12:05:08
-
Bonjour,
Il s'agit d'un Netgear LM1200 (puce Red) : bridgé sur un PC -> IPv6 Ok
Bridgé sur l'Asus paramétré en IPv6 Passthrough, depuis une session SSH, j'ai ceci :
/tmp/home/root# traceroute6 google.com
traceroute to google.com (2a00:1450:4007:806::200e), 30 hops max, 16 byte packets
1 2a02-8440-6115-00b4-264b-feff-fe72-24c8.rev.sfr.net (2a02:8440:6115:b4:264b:feff:fe72:24c8) 3004.451 ms !H 3007.184 ms !H 3005.840 ms !H
Soit l'adresse br0 du routeur
Merci de toutes indications qui pourraient me sortir de l'impasse.
-
tu as essayé les autres modes disponibles (a part passthrough)?
-
Bonjour,
Si je comprends bien, ton routeur Netgear LM1200 gère bien l'IPv6, vu que cela fonctionne avec un PC connecté directement.
La problématique semble venir de ton Asus qui sert de point d'accès, si je comprends bien le Netgear LM1200 ne fait que modem + NAT (pour l'IPv4).
Quel est le modèle de l'équipement Asus et sa configuration ?
-
Bonjour Vivien,
Asus RT-AX68 routeur AImesh bridgé sur LM1200 configuré en mode bridge
IPv4 tout est okay si l'on excepte le jeu en ligne avec CG-Nat + Nat Asus qui donne parfois des pertes de connection aux serveurs de jeu
en IPv6 :
Le "Native" : traceroute et ping okay depuis le routeur mais je n'ai pas non plus de connectivité depuis les clients Lan
Passthrough est le mode préconisé par Asus dans le cas d'une adresse FAI dynamique
Tout se passe comme si tout ce qui sort du Lan était ignoré ... :-/
-
refait un test avec une config native valable à un instant t :
depuis le routeur Asus, on est bon :
# wget -q -O - https://ipv4v6.lafibre.info/ip.php
2a02:8440:6200:ac9c:264b:feff:fe72:24c8je retrouve bien l'adresse Ipv6 Wan
depuis Windows :
>ping fe80::264b:feff:fe72:24c8
Pinging fe80::264b:feff:fe72:24c8 with 32 bytes of data:
Reply from fe80::264b:feff:fe72:24c8: time=2msmais
>ping 2a02:8440:6200:ac9c:264b:feff:fe72:24c8
Pinging 2a02:8440:6200:ac9c:264b:feff:fe72:24c8 with 32 bytes of data:
Destination host unreachable.
Je sèche ... :-\
-
Tu as bien une (ou plusieurs) GUA sur chaque machine ?
-
Bonjour Renaud,
Oui, c'est du stateless/RA :
Interface 8: aimesh
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Preferred 6d23h13m1s 23h3m34s 2a02:8440:6200:ac9c:b9:2536:7181:5cc4
Public Preferred infinite infinite 2a02:8440:6200:ac9c:xxxx:xxxx:xxxx:a08f
Other Preferred infinite infinite fe80::b251:cfa8:b234:a73e%8
Les drivers de l'interface réseau (Killer 2500) datent mais il n'y a pas plus récent
sur l'Asus, j'ai :
IPv6 routing table
Destination & Next Hop Flags Metric Ref Use Type Iface
2a02:8440:6200:ac9c:b9:2536:7181:5cc4 U 1024 1 0 LAN br0
2a02:8440:6200:ac9c::/64 UAP 256 0 0 WAN eth0
2a02:8440:6200:ac9c::/64 U 256 0 0 LAN br0
fe80::/64 U 256 0 0 WAN eth0
fe80::/64 U 256 0 0 LAN br0
default via fe80::cd5e:38ac:400c:85bb UGDAE 1024 2 0 WAN eth0
ff00::/8 U 256 2 0 WAN eth0
ff00::/8 U 256 2 0 LAN br0
Le modem Netgear n'a pas d'accès SSH (du moins connu) ... Impasse ? :-\
-
SFR ne donne pas la délégation /64 ou le routeur Asus ne sait pas la faire quand l'option DHCP-PD est activée ?
Merci de vos éclaircissements :-)
-
C'est pas en mode AP qu'il faut configurer l'Asus??
-
Pas de délégation sur le mobile, c'est juste Router advertisement - SLAAC.
Tu es sûr que ton asus supporte ce mode particulier ? Car bien que ça semble être le cas d'après ce que tu nous montre, un ping ne donne rien... normalement ça devrait passer, d'autant plus vers la GUA du routeur.
Un ping vers un site extérieur ne fonctionne pas non plus ?
-
Le test https://ip.lafibre.info/ donne la connectivité IPv6 dès que l'on a fait :
ip -6 neigh add proxy <adr temp win du PC) dev <if wan>
La valeur de /proc/sys/net/ipv6/conf/all/proxy_ndp n'a pas d'importance, on la retrouve à 0 après un reboot du routeur
Par contre, ça ne tient que quelques minutes et la ligne proxy qui a été ajoutée n'apparait même pas dans le neigh show où la ligne GW est passée de reachable à failed
Quelle misère ! :(
-
Ça à l'air de bien déconner en effet... Tu as vérifié sur le WAN seul si le proxy ndp était activé, en remplaçant all par eth0 ?
Sur openwrt par ex, si tu regarde à all, c'est à 0, par contre sur eth1 (qui est le WAN), c'est bien à 1.
Concernant ip -6 nei, qui n'affiche pas l'ip ajoutée manuellement, c'est à priori normal... il y a le même problème en ipv4 (https://marc.info/?l=linux-kernel&m=99296348326633&w=2). J'ai testé en rentrant une adresse au hasard et ça ne l'affiche pas non plus chez moi.
Je me demande si ça ne serait pas dû au fait que le routeur a le même préfixe LAN/WAN qui le perturbe car j'ai lu notamment ça : https://gitea.com/CasperVector/6brd l'implémentation ndppd se mélange les pinceaux avec un seul /64. Je ne sais pas quel implémentation utilise ton routeur, mais si ça se trouve c'est une conn*rie du genre.
Pour être sur que ça vient bien de l'asus, tu pourrais essayer une VM openwrt (https://downloads.openwrt.org/releases/19.07.0/targets/x86/64/), configurée en mode relay. En théorie ça devrait fonctionner. Par contre, ton routeur n'est pas (encore) compatible avec, sinon tu aurais pu directement le flasher dessus...
Pour l'installer sur virtualbox : https://openwrt.org/docs/guide-user/virtualization/virtualbox-vm
Normalement ça devrait donner ça :
-
Je me demande si ça ne serait pas dû au fait que le routeur a le même préfixe LAN/WAN qui le perturbe car j'ai lu notamment ça : https://gitea.com/CasperVector/6brd l'implémentation ndppd se mélange les pinceaux avec un seul /64.
Probable
J'ai ceci :
6relayd -drs -Rrelay -Dserver -N -n eth4 br0
Features:
-A Automatic relay (defaults: RrelayDrelayNsr)
-S Automatic server (defaults: RserverDserver)
-R <mode> Enable Router Discovery support (RD)
relay relay mode
server mini-server for Router Discovery on slaves
-D <mode> Enable DHCPv6-support
relay standards-compliant relay
server server for DHCPv6 + PD on slaves
-N Enable Neighbor Discovery Proxy (NDP)
Feature options:
-s Send initial RD-Solicitation to <master>
-u RD: Assume default router even with ULA only
-c RD: ULA-compatibility with broken devices
-m <mode> RD: Address Management Level
0 (default) enable SLAAC and don't send Managed-Flag
1 enable SLAAC and send Managed-Flag
2 disable SLAAC and send Managed-Flag
-o RD: Don't send on-link flag for prefixes
-i <preference> RD: Route info and default preference
medium medium priority (default)
low low priority
high high priority
-n [server] RD/DHCPv6: always rewrite name server
-l <file>,<cmd> DHCPv6: IA lease-file and update callback
-a <duid>:<val> DHCPv6: IA_NA static assignment
-r NDP: learn routes to neighbors
-t <p>/<l>:<if> NDP: define a static NDP-prefix on <if>
slave prefix ~ NDP: don't proxy NDP for hosts and only
serve NDP for DAD and traffic to router
Invocation options:
-p <pidfile> Set pidfile (/var/run/6relayd.pid)
-d Daemonize
6relayd[30405]: Learned about 2a02:8440:6403:7569:5eff:b405:3bd:b062 on eth4
2a02:8440:6403:7569:5eff:b405:3bd:b062 dev eth4 lladdr 6e:cd:d6:53:3a:a5 router STALE
Je ne vois pas ce qui ne plait pas à SFR et qui fait que la connectivité IPv6 échoue :-/
-
eth4 correspond à quoi ? Le WAN de l'asus ? C'était pas plutôt eth0 ? Et la GUA au netgear ?
Le stale sur la GUA est à priori normale (pas de trafic directement dessus), le routage se faisant via la link local. C'est surtout cette dernière qu'il faut regarder si elle ne passe pas en stale puis failed comme tu l'as dit un peu avant.
As-tu une connexion fixe en plus de la 4G avec de l'ipv6 ? Si oui tu pourrais essayer voir si tu as les mêmes résultats.
-
J'ai activé le double WAN avec Ethernet Lan 1 mais chez Asus les prises, ça marche à l'envers ... on s'attendrait à eth1 mais c'est eth4 :-)
Pas de Box, j'en ai plus l'utilité mais là, avec une délégation /56 ou /60, ça marcherait à coup sûr
Le blême, c'est SFR : s'ils assignaient une IP /128 il n'y aurait pas de souci à gérer le /64 ensuite
-
Sauf que ça ne marche pas comme ça... c'est pareil chez tous les opérateurs. C'est sûr que si on avait un /128 sur le WAN et du DHCPv6-PD pour le /64 tout serait plus facile. Mais il faudrait que les smartphones et routeurs GP le supportent par défaut et pour l'instant (surtout concernant android) c'est absolument pas le cas.
Le bon compromis, serait de garder le /64 en SLAAC pour la conf full auto et d'avoir la possibilité d'envoyer une demande de délégation pour récupérer un /64 supplémentaire si on a envie d'avoir son propre routeur sans devoir faire du proxy NDP.
Pas très complexe à mettre en place (on assigne un /63 par ligne en annonçant le 1er /64) et ça contenterait tout le monde je pense.
As-tu essayé openwrt pour confirmer que ça vient bien de ton routeur ? SFR pourrait avoir un soucis, mais j'y crois pas trop.
-
openwrt, pourquoi pas ? mais j'ai bien galéré à mettre en place le container lxc sur mon qnap (abandon de lxc au profit de lxd chez qnap, pourquoi pas mais pas n'importe comment >.<)
Je verrai plus tard mais le passthrough asus, c'est ni plus ni moins que le relay qu'ils ont piqué à openwrt donc je m'attends à la même problématique
Pour l'heure, j'attends un appliance Netgate (pfsense ne supporte pas le nd proxy mais il fait parti de freebsd, on devrait pouvoir bidouiller)
:-)
-
Perso, j'ai un routeur 4G huawei avec des AP Aerohive et l'IPv6 fonctionne bien avec une SIM RED SFR.
Faut pas bridger la partie 4G, mais juste avoir un device qui fait AP only en amont du routeur 4G
-
En amont ?
Pas sur de bien comprendre :-/
-
Ah.
Je voulais dire, que les AP sont directement branchés sur les ports LAN du routeur 4G.
-
Pour être sur que ça vient bien de l'asus, tu pourrais essayer une VM openwrt (https://downloads.openwrt.org/releases/19.07.0/targets/x86/64/), configurée en mode relay. En théorie ça devrait fonctionner.
Hélas j'en suis rendu au même point :
root@OpenWrt:~# route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/0 fe80::7c4b:88b5:74cd:8752 UG 512 3 0 eth1
root@OpenWrt:~# ping -6 google.com
PING google.com (2a00:1450:4007:806::200e): 56 data bytes
64 bytes from 2a00:1450:4007:806::200e: seq=0 ttl=113 time=62.145 ms
root@debian-buster-2:~# route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2a02-8440-620a-a254-0000-0000-0000-0000.rev.sfr.net/64 [::] UA 256 1 0 eth0
2a02-8440-620a-a254-0000-0000-0000-0000.rev.sfr.net/64 [::] U 1024 1 0 eth0
fe80::/64 [::] U 256 2 0 eth0
[::]/0 fe80::5054:ff:fe05:7640 UGDAe 1024 5 0 eth0
root@debian-buster-2:~# ping -6 google.com
PING google.com(par21s18-in-x0e.1e100.net (2a00:1450:4007:806::200e)) 56 data bytes
From fe80::5054:ff:fe05:7640%eth0 (fe80::5054:ff:fe05:7640%eth0): icmp_seq=1 Destination unreachable: No route
Problème sans solution ? :-\
-
Humm... J'avoue je ne m'attendais pas à ça.
J'ai réussi à me procurer une SIM SFR et de mon côté ça marche très bien. À mon avis tu as oublié un truc... ou alors c'est ton netgear qui a un blème. Perso j'utilise du huawei.
root@OpenWrt:~# route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/0 fe80::b273:5dff:fec4:3d30 UG 384 3 580 eth1
::/0 fe80::b273:5dff:fec4:3d30 UG 384 1 0 eth1
2a01:cb14:xxx:xxxx:b4f:24a4:640d:7b48/128 :: U 1024 1 0 br-lan
2a02:8440:5218:e9d:6453:243e:aede:14ac/128 :: U 1024 2 2 br-lan
2a02:8440:5218:e9d::/64 :: U 256 2 11 eth1
fd07:ad3c:7:2:4816:4d0:a700:7a24/128 :: U 1024 1 0 br-lan
fdb0:735d:c43d:3000::/64 :: U 256 1 0 eth1
fe80::/64 :: U 256 2 9 br-lan
fe80::/64 :: U 256 3 6717 eth1
::/0 :: !n -1 1 295331 lo
::1/128 :: Un 0 4 73876 lo
2a02:8440:5218:e9d::/128 :: Un 0 2 0 eth1
2a02:8440:5218:e9d:a00:27ff:fefe:bf0a/128 :: Un 0 4 31 eth1
fdb0:735d:c43d:3000::/128 :: Un 0 2 0 eth1
fdb0:735d:c43d:3000:a00:27ff:fefe:bf0a/128 :: Un 0 3 66 eth1
fe80::/128 :: Un 0 2 0 br-lan
fe80::/128 :: Un 0 2 0 eth1
fe80::a00:27ff:fe41:8021/128 :: Un 0 3 3143 br-lan
fe80::a00:27ff:fefe:bf0a/128 :: Un 0 3 144900 eth1
ff00::/8 :: U 256 3 375456 br-lan
ff00::/8 :: U 256 3 130325 eth1
::/0 :: !n -1 1 295331 lo
C:\Users\renaud>ping -6 google.fr
Envoi d’une requête 'ping' sur google.fr [2a00:1450:4007:80d::2003] avec 32 octets de données :
Réponse de 2a00:1450:4007:80d::2003 : temps=59 ms
Réponse de 2a00:1450:4007:80d::2003 : temps=36 ms
Réponse de 2a00:1450:4007:80d::2003 : temps=49 ms
Réponse de 2a00:1450:4007:80d::2003 : temps=41 ms
Statistiques Ping pour 2a00:1450:4007:80d::2003:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 36ms, Maximum = 59ms, Moyenne = 46ms
C:\Users\renaud>route -6 print
===========================================================================
Liste d'Interfaces
9...08 00 27 79 df ce ......Intel(R) PRO/1000 MT Desktop Adapter
17...08 00 27 ca 31 35 ......Intel(R) PRO/1000 MT Desktop Adapter #2
1...........................Software Loopback Interface 1
===========================================================================
IPv6 Table de routage
===========================================================================
Itinéraires actifs :
If Metric Network Destination Gateway
9 144 ::/0 fe80::a00:27ff:fe41:8021
1 331 ::1/128 On-link
9 144 2a02:8440:5218:e9d::/64 On-link
9 384 2a02:8440:5218:e9d:4da6:811e:8da9:6619/128
On-link
9 384 2a02:8440:5218:e9d:6453:243e:aede:14ac/128
On-link
9 144 fdb0:735d:c43d:3000::/64 On-link
9 384 fdb0:735d:c43d:3000:4da6:811e:8da9:6619/128
On-link
9 384 fdb0:735d:c43d:3000:6453:243e:aede:14ac/128
On-link
9 384 fe80::/64 On-link
9 384 fe80::4da6:811e:8da9:6619/128
On-link
1 331 ff00::/8 On-link
9 384 ff00::/8 On-linkrenaud@renaud-VirtualBox:~$ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2a02:8440:5218:e9d::/64 dev enp0s3 proto ra metric 100 pref medium
fdb0:735d:c43d:3000::/64 dev enp0s3 proto ra metric 100 pref medium
fe80::/64 dev enp0s3 proto kernel metric 100 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::a00:27ff:fe41:8021 dev enp0s3 proto ra metric 100 pref high
-
Perso j'utilise du huawei.
C'est quel modèle ? En mode bridge ou routeur ?
Merci à toi
-
B535-235 ou B535-333.
J'ai testé bridge ou routeur, les deux fonctionnent
Voici la capture en bridge d'ailleurs :
-
B535-333.
Le wi-fi peut être désactivé (je n'arrive pas à trouver le user guide Huawei :-/) ?
Je tiens à conserver le mesh Asus
Merci
-
Oui, pas de soucis. C'est quand même un truc de base.
Par contre, si tu envisage de passer chez la concurrence (Bouygues et tout particulièrement Free qui n'a pas de DNS64 si ipv6 activé), le 333 ne supportant pas le CLAT tu n'auras pas d'accès ipv4 avec ce dernier ! Il faut donc se débrouiller et l'ajouter via une VM (avec risque de coupure). Ou se contenter de l'IPv4 seule. Il est théoriquement possible d'avoir du dualstack chez Free, mais ce n'est pas censé fonctionner, c'est un coup de bol.
Même si en théorie ce n'est pas gênant sur un usage lambda, ça peut l'être si tu veux mettre des DNS IPv4 customs par ex ou avec les JV (consoles & cie).
Je te laisse lire les sujets afférents (section Bouygues et Free mobile notamment).
-
Merci à toi
En regardant à nouveau les captures d'écran, j'ai vu que je n'avais pas d'ULA sur wan6 contrairement à toi. Est-ce que cela peut-être la source du problème ?
Bon dimanche.
-
La ULA n'a pas d'influence normalement.
T'as essayé routeur et bridge sur le netgear ?
-
oui ce matin et comme j'ai fini par ne plus accéder à son UI, j'ai fait un reset et ....
Il semblerait que tout marche à présent ... à confirmer !
++
-
Ah ben génial alors, pourvu que ça dure :)
Ça marche avec l'asus du coup ?
-
Après redémarrage du PC tout est perdu ...
Des routes avaient été créées qui faisaient que ...
A présent :
root@debian-bullseye:~# ping -6 _gateway
PING _gateway(_gateway (fe80::5054:ff:fe05:7640)) 56 data bytes
64 bytes from _gateway (fe80::5054:ff:fe05:7640%eth0): icmp_seq=1 ttl=64 time=0.098 ms
64 bytes from _gateway (fe80::5054:ff:fe05:7640%eth0): icmp_seq=2 ttl=64 time=0.134 ms
64 bytes from _gateway (fe80::5054:ff:fe05:7640%eth0): icmp_seq=3 ttl=64 time=0.150 ms
^C
--- _gateway ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.098/0.127/0.150/0.021 ms
root@debian-bullseye:~# ping -6 ipv6.lafibre.info
PING ipv6.lafibre.info(fr.archive.ubuntu.com (2001:bc8:1600:4:63f:72ff:feaf:a2de)) 56 data bytes
From _gateway (fe80::5054:ff:fe05:7640%eth0) icmp_seq=1 Destination unreachable: No routeMe manque un paramétrage sur openwrt ? :-/
root@OpenWrt:~# ifstatus wan6
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 13485,
"l3_device": "eth1",
"proto": "dhcpv6",
"device": "eth1",
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
],
"ipv6-address": [
{
"address": "2a02:XXXX:XXXX:XXXX:ff:fedc:2f9",
"mask": 64
}
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "2a02:XXXX:XXXX:XXXX::",
"mask": 64,
"nexthop": "::",
"metric": 256,
"source": "::/0"
},
{
"target": "::",
"mask": 0,
"nexthop": "fe80::21cd:4880:95e4:172b",
"metric": 512,
"valid": 63017,
"source": "2a02:XXXX:XXXX:XXXX:XXXX:ff:fedc:2f9/64"
}
],
"dns-server": [
"2a02:8400::2:0",
"2a02:8400::2:1"
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
}
-
Je ne peux pas t'en dire mieux pour le moment, je ne suis pas chez moi et j'ai rendu la SIM SFR à son propriétaire...
Concernant le paramétrage en lui-même, je ne fais rien de spécial si ce n'est passer en mode relay, tout le reste est par défaut.
Tu as bien pris la 19.07 ? Car j'avais des problèmes avec des versions plus anciennes. Je n'ai pas non plus essayé les dernières versions.
-
OpenWrt 22.03.5 r20134-5f15225c1e
Si je branche le PC en direct sur modem bridgé puis je le rebranche sur le Lan Openwrt, la connectivité IPv6 reste malgré que la route default soit à nouveau sur l'ip Lan Openwrt
:-/
-
Essaies la 19.07 que j'ai mis en lien.
Je testerais la 22.03 en rentant pour voir si j'ai le même soucis.
EDIT : AH ! Il semblerait qu'il y ai bien un bug : [22.03] RA,DHCPv6,NDP relay mode makes it impossible to connect to the IPv6 Internet (https://github.com/openwrt/openwrt/issues/9881)
-
Je ferais mieux de jouer au Loto ... On sait jamais ... :-)
-
Testé la 19.07 sans succès et avec d'autres problématiques : routes non créées et pas d'adresse globale pour les clients
-
bug : [22.03] RA,DHCPv6,NDP relay mode makes it impossible to connect to the IPv6 Internet (https://github.com/openwrt/openwrt/issues/9881)
ticket toujours ouvert au bout d'1 an ... :-/
le pire, c'est que j'ai commandé un boitier avec openwrt préinstallé et qui risque aussi de finir sur l'étagère :(
-
Le fait de ne pas avoir de GUA sur les postes était un des problème sur des vieilles versions, mais pas de soucis avec la 19.07. Je vais te passer ma VM en MP histoire d'être sûr.
Concernant virtualbox tu es bien en réseau interne entre openwrt et la debian ? Et en bridge côté WAN ? Installes un windows aussi histoire de pouvoir comparer, même si en théorie ça devrait donner la même chose.
En terme de config, j'ai ça :
/etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.45.1'
option netmask '255.255.255.0'
option ip6assign '64'
config interface 'wan6'
option ifname 'eth1'
option proto 'dhcpv6'
option reqaddress 'none'
option reqprefix '64'
config interface 'WAN'
option ifname 'eth1'
option proto 'dhcp'
/etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option ra 'relay'
option dhcpv6 'relay'
option ndp 'relay'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config dhcp 'wan6'
option dhcpv6 'relay'
option ra 'relay'
option ndp 'relay'
option master '1'
option interface 'wan6'
option start '100'
option leasetime '12h'
option limit '150'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
-
Mon environnement virtuel est le suivant (voir copie d'écran) et pleinement opérationnel en ipv4
Ce matin, en fin de matinée , j'avais la connectivité IPv6 avec openwrt 21, depuis mon windows 10 en filaire
Dans la foulée, je me dis okay, on va voir depuis le smartphone en wifi sur mon AP et là rien.
Je débranche le filaire pour le wifi sur mon win10 et là, toujours rien.
Je rebranche le filaire et la connectivité IPv6 s'était fait la malle et je ne vois plus aucun lease DVCPv6.
Bref, arrachage de cheveux, enfin ceux qui me restent ... :-/
-
Après avoir commenté les 2 p#### lignes :
21 config dhcp 'lan'
22 option interface 'lan'
23 option start '100'
24 option limit '150'
25 option leasetime '12h'
26 option dhcpv4 'server'
27 option ra 'relay'
28 option dhcpv6 'relay'
29 option ndp 'relay'
30 # list ra_flags 'none'
31
32 config dhcp 'wan'
33 option interface 'wan'
34 option ignore '1'
35
36 config odhcpd 'odhcpd'
37 option maindhcp '0'
38 option leasefile '/tmp/hosts/odhcpd'
39 option leasetrigger '/usr/sbin/odhcpd-update'
40 option loglevel '4'
41
42 config dhcp 'wan6'
43 option interface 'wan6'
44 option ignore '1'
45 option master '1'
46 option ra 'relay'
47 option dhcpv6 'relay'
48 option ndp 'relay'
49 # list ra_flags 'none'
tada ! connectivité ipv6 retrouvée sur win10 !
Par contre, le test est négatif avec ip.lafibre.info depuis le smartphone en wifi :-/
-
Cette interface ne me dit rien... tu utilises quoi comme environnement ? proxmox ? esxi ? Une distro lambda avec KVM ?
Car si on utilise pas les mêmes outils dans un premier temps, le soucis peut aussi venir de là.
EDIT : list ra_flags permet de contrôler ce qui est envoyé dans dans les RA, à none ça met tout à 0, donc difficile pour les postes de se configurer une IP en effet ;) Cependant, bizarre que ça ai un incidence en relay, faut que j'essaie.
Pour le wifi, il faudrait tester avec un PC portable et wireshark vérifier le contenu des RA justement. Tu as une GUA ou pas ?
-
Virtualisation (qemu) et Container Station (LXD) sous QNAP :-)
Pour les flags, ils devaient être de base dans la 21 car je n'avais touché à rien hors paramétrage initial sous LUCI
Pour le wifi, c'est ce que j'avais fait ce matin depuis mon PC avant d'avoir la zone ...
Cela dit, ce n'est pas stable ... là, je viens de faire un resume du PC après sleep et j'ai à nouveau perdu la connectivité IPv6 ... :(
-
Virtualisation (qemu) et Container Station (LXD) sous QNAP :-)
Ah ok, je ne suis pas très familier de ces solutions toutes prêtes. Chez moi le NAS est aux petits oignons sur base debian. Côté virtu, c'est virtualbox/vmware sur PC et proxmox en hyperviseur.
Pour les flags, ils devaient être de base dans la 21 car je n'avais touché à rien hors paramétrage initial sous LUCI
Possible, après none en relay est peut-être logique vu que ce n'est pas openwrt qui a la main sur les RA dans ce cas.
Pour le wifi, c'est ce que j'avais fait ce matin depuis mon PC avant d'avoir la zone ...
Cela dit, ce n'est pas stable ... là, je viens de faire un resume du PC après sleep et j'ai à nouveau perdu la connectivité IPv6 ... :(
Bizarre... et en déco/reco le réseau, ça revient ?
-
Je vais attendre d'avoir mon appliance dédiée pour m'y remettre en espérant que je n'aurais pas de souci car c'est un fork d'openwrt qui y est préinstallé
Merci de ton aide apportée
Bonne soirée
-
De rien :)
Du coup, j'ai testé la 22.03 et j'ai fini par tilter : mettre le LAN en relay mode ne suffit pas. Il faut bien faire de même sur le wan en éditant le fichier dhcp à la main (comme écrit dans la doc tout bêtement, ça fait un moment que je l'avais mis en place, totalement zappé), car par défaut ce n'est pas modifié en même temps (et option dans luci pas visible car non configuré au départ).
Ça marche bien aussi. Par contre, pas vu la ligne ra_flags.
-
Il faut bien faire de même sur le wan en éditant le fichier dhcp à la main
wan ou wan6 ? :-/
je l'avais fait au travers de l'interface web sur wan6
-
Oui wan6.
-
Pour info, succès total avec Raspberry Pi 2 Model B Rev 1.1 + OpenWrt 22.03.05 + dongle Huawei Brovi E3372-325
Par contre, Raspberry Pi 2 Model B Rev 1.1 + OpenWrt 22.03.05 + modem Netgear LM1200 toujours les mêmes soucis avec des DAD et une connectivité IPv6 qui semble parfois être là :(
-
On aurait donc un bug du netgear avec cette conf, dommage. En plus il est pas franchement bon marché, pour un truc avec juste un port LAN et cat 4... À tout hasard il est à jour ?
Et le Raspberry, c'est donc ton appliance ou pas reçue encore ?
-
Il est à jour mais faudra que je reteste quand il est en mode routeur mais je n'aime pas ces soluces où il faut coller une IP en DMZ à cause du double Nat ... :-/
Le Raspberry, il dormait dans un tiroir, c'était l'occasion de le réveiller ... :-)
J'attends l'appliance (pas fait gaffe que ça venait de Chine) :(
Sinon il est pas impossible que je monte un router 4G sur une base Mikrotik ... à suivre :-)
-
Pour le NAT, tu es déjà en CGNAT en 4G, donc un peu plus un peu moins, ça change pas grand chose ;D
Pour ta base mikrotik tu pencherais pour quel modèle ? Perso, je trouve qu'ils sont assez chers (genre le LTE12 à + de 200€), mais si ça peut t'éviter d'avoir à rajouter un autre routeur au cul vu que routerOS est très complet, why not.
De mon côté les huawei me vont très bien : 4 ports LAN + 1 RJ11 pour un téléphone (selon le modèle, tous le l'ont pas), toujours pratique à ~100€, c'est un meilleur rapport Q/P je trouve.
-
Bah là, sous Caulof, bonjour la High Latency et le Packet Burst !
RBM33G pour Mikrotik mais la facture grimpe déjà à 180 boules et encore, je n'ai pas encore ajouté les antennes dans le panier :-)
-
Pas mal ce genre de carte custom, après vu qu'il faut rajouter les modems LTE ça grimpe vite en effet, sinon c'est assez abordable.
T'as pris un modem mikortik pour être sûr de la compatibilité du coup ? Car je sais pas si t'as fait gaffe, mais y'a pas la B28 (700) dans les modèles proposés... et crois-moi elle peut être plus utile qu'on ne le pense.
Genre chez moi je suis bien content de l'avoir : routeur mal placé car pas le choix pour le brancher au LAN, j'ai un débit pas terrible (surtout en UP) sur la B20 (malgré les 10 Mhz de largeur), mais quasi constant et bien meilleur sur la B28 (5 Mhz), même aux heures de pointe.
EDIT : ST à l'instant :
800 Mhz : https://www.speedtest.net/result/14773835105
700 Mhz : https://www.speedtest.net/result/14773812629
-
à priori sur les 2 boutiques, ils ne proposent que celle-là :
https://www.wifi-france.com/mikrotik/r11e-4g
Le R11e-4G prend en charge les bandes LTE FDD 3 (1800 MHz), 7 (2600 MHz), 20 (800 MHz) et 31 (450 MHz), ainsi que les bandes LTE TDD 41n (2500 MHz), 42 (3500 MHz) et 43 (3700 MHz).
c'est plus le ping qui m'intéresse car là, avec le RPi, c'est la cata pour le jeu en ligne ... :-)
-
C'est encore pire celle-ci : elle est en fin de vie sur le site officiel et il manque la B1 (2100). N'achète pas ça.
Et il y a bien la R11e-LTE : https://www.wifi-france.com/mikrotik/r11e-lte ainsi que la LTE6 : https://www.wifi-france.com/mikrotik/r11e-lte6
Mais franchement, je serais toi je prendrais le nouveau Chateau LTE6 : https://www.getic.fr/product/mikrotik-chateau-lte6-ax
C'est le même prix que ta board tout compris, déjà tout fait, avec toutes les fréquences françaises en CAT6 (2CA) et le wifi AX !
-
LTE6 : https://www.wifi-france.com/mikrotik/r11e-lte6
Effectivement, je suis passé à côté mais leur filtre en peigne est rangé avec les pieds ... :-/
Mais franchement, je serais toi je prendrais le nouveau Chateau LTE6 : https://www.getic.fr/product/mikrotik-chateau-lte6-ax
à approfondir car je vois RouterOS Lvl4 et le passage vers OpenWrt nécessite Lvl6 de ce que j'ai compris ...
-
Enfin ! 8)
-
Effectivement, je suis passé à côté mais leur filtre en peigne est rangé avec les pieds ... :-/
Oui pas pratique, j'ai tapé direct dans la barre de recherche.
à approfondir car je vois RouterOS Lvl4 et le passage vers OpenWrt nécessite Lvl6 de ce que j'ai compris ...
Tu veux pas utiliser routerOS donc ? Faut suivre^^ Dans ce cas il faudrait en effet rester sur ta board, ils ont déjà du mal avec le LTE12 et le LTE6 vient juste de sortir, y'a rien dessus. Et par rapport à la version, ce n'est pas le "level" (qui indique les fonctionnalités accessibles comme le nombre de tunnel VPN max par ex) mais la version de routerOS, en l’occurrence, il faudrait la version 6, hors le LTE12 (et donc le LTE6) sont livré d'office en v7, donc plus dur d'y installer autre chose.
Enfin ! 8)
Super 8) Quel setup du coup ?
-
J'avais bien compris pour le Lvl mais je n'me vois pas briquer un truc à 200 boules en le downgradant de 7 à 6 :-)
Pour le reste, ce n'est pas stable (pour une raison que j'aimerais bien connaître)
mais j'avais :
- remplacé dnsmasq par dnsmasq-dhcpv6
- désactivé le relais pour dhcpv6-service
- modifié la règle icmp6-forward
list icmp_type 'neighbour-advertisement'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
-
J'avais bien compris pour le Lvl mais je n'me vois pas briquer un truc à 200 boules en le downgradant de 7 à 6 :-)
C'est sûr. Et comme j'ai dit, il n'est de toute façon pas supporté pour le moment...
Pour le reste, ce n'est pas stable (pour une raison que j'aimerais bien connaître)
mais j'avais :
- remplacé dnsmasq par dnsmasq-dhcpv6
- désactivé le relais pour dhcpv6-service
- modifié la règle icmp6-forward
list icmp_type 'neighbour-advertisement'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
C'est quand même bizarre. Normalement pas besoin de rajouter NA/NS/RA au pare-feu. Puisque le routeur fait l'intermédiaire, les machines ne dialoguent pas directement avec le modem en amont. Excepté pour le ping et autre packet too big qu'il faut laisser passer sans modif.
Chez moi tout marche très bien avec la conf par défaut...
-
Un ping de l'ipv6 attribuée au modem depuis OpenWrt suffit à redonner la connectivité IPv6
Maintenant comment automatiser cela ? Pour l'heure, je n'ai pas d'autres moyens que de me connecter à la WebUI du modem pour la connaitre ... :-/
-
Ton modem a toujours le même suffixe ou pas ? Si c'est le cas, il faudrait juste récupérer le préfixe en cours d'utilisation.
Par contre, ne me demande pas de faire le script, j'ai aucune compétence en script bash^^
-
Le script, c'est pas un souci ... :-)
Le souci, c'est le curl d'authentification qui ne marche pas (pour une raison inconnue) du coup, je suis marron pour récupérer le json avec toutes les données du modem ...
Les gars du XDA son en train de décortiquer le firmware que les inges de Netgear se sont amusés à encrypter ... ::)
Mon souci vient du fait qu'openwrt et le modem reçoivent chacun une IP globale via le dhcp de SFR et le fait que la connectivité soit aléatoire, je me demande si ça ne vient pas de leur fait ....
-
Par rapport aux IP, il n'y a rien de bizarre, c'est pareil chez tout le monde. Il faut voir ça comme un unique LAN (comme quand tu branches tout au cul du modem) et là c'est tout de suite plus cohérent. Sauf qu'on y rajoute du pseudo routage entre.
Quand à ton histoire de ping, ça me fait penser à un problème que j'ai eu avec virtualbox lors de l'utilisation en wifi, mais je crois que ça n'a pas de rapport. En gros, le trafic multicast est bloqué en entrée par l'interface wifi et impossible d'associer IP et MAC (la VM ne reçoit pas les NS), il fallait donc faire un ping sur la GUA du routeur depuis le guest pour que au moins un paquet arrive au routeur et que celui-ci fasse la correspondance.
À tout hasard, tu peux tenter d'activer le all multicast sur le WAN de l'openwrt, mais j'y crois pas trop : ip link set $DEV allmulticast on
-
Bien vu ! ;)
Un ping de la GUA du modem depuis le PC lui redonne ensuite la connectivité IPv6
Mais dommage qu'openwrt soit le seul à gérer ce foutu relais car il faut l'avouer, il n'est pas très end-user friendly :-)
-
Je pense que la source de mes ennuis viennent de là :
Sun Jun 4 09:54:25 2023 daemon.err odhcpd[2315]: Failed to send to 2a02:8440:xxxx:xxxx:919c:2c60:2719:766b%lan@br-lan (Operation not permitted)
Sun Jun 4 09:54:26 2023 user.notice nlbwmon: Reloading nlbwmon due to ifup of wan6 (eth0)
(à mon sens) Cette adresse n'est-elle pas pour eth0 ? mais au lieu de ça, j'obtiens une stateless sur wan6 :
inet6 2a02:8440:xxxx:xxxx:783e:ef ff:fe 63:b35d/64 scope global noprefixroute
valid_lft forever preferred_lft forever
Autrement, super le p'tit nanopi r5s : openwrt préinstallé, rien à faire à part mettre les interfaces en relais :-)
-
Finalement une config okay :
Huawei B535-235a (mode bridge) + NanoPi R5S FriendlyWrt (aka OpenWrt 22.03.4 mode relay)
Merci pour ton support :-)
-
Ah ben voilà, ça marche enfin :)
Et de rien ;)