Le réseau vous donne quels DNS ? 2001:860:d002:1201::129:201 ?

Si c'est bien celui là qui vous est attribué, vous constatez aussi un grand nombre de timeouts ?

En faisant un essai en mode bridge pour vérifier le DNS j'ai découvert un truc bizarre : Lorsque je passe par le routeur, les adresses DNS64 ne fonctionnent pas. Du coup le navigateur passe systématiquement par l'ipv4 littérale ce qui fait travailler le CLAT pour rien. Et dès que je me mets en bridge, ça refonctionne...

Il suffit de lancer un ping sur une 64:ff9b::, ça ne répond pas et dès que le bridge est actif, ça part.

Y'a un bug quelque part non ?

EDIT : Testé avec mon smartphone en partage de connexion sur sosh : Aucun problème. Je vais essayer ma SIM sosh dans le routeur pour voir.

EDIT2 : Idem avec Sosh, ça ne fonctionne pas non plus, même en désactivant le parefeu (des fois qu'il y ai une règle à la c*n sur ces adresses)...

Si je comprends bien, si tu passes ton routeur 4G en mode "bridge" (pas sur de comprendre ce que ca fait exactement, car ce n'est pas de l'Ethernet des deux côtés), tu ne peux plus rien joindre dans 64:ff9b::/96?
Et si tu le reconfigure pour qu'il agisse comme un routeur, ca fonctionne, c'est ca ?

C'est l'inverse. En mode bridge, ça marche. En mode routeur, les paquets partent mais ne reçoivent aucune réponse.

64:ff9b:: map vers 0.0.0.0, je ne m'attendrai pas à ce que ca réponde aux pings. Chez moi, le NAT64 local (mon routeur) me revoie un destination unreachable: no route, ce qui a du sens (0.0.0.0 n'est pas une IPv4 valide).

Je voulais dire vers une adresse commençant par 64:ff9b:: je me doute que si je ne mets que le préfixe ça ne risque pas de réponde 

Aucune idée...

Et j'ai un peu de mal à comprendre pourquoi y'en aurait un. La partie CLAT ok, mais l’ensemble ça me parait bizarre. Vu que le cas ipv6 only est bien géré, ça n'a pas de sens. Et je n'ai rien vu dans l’interface qui s'y rapporte.

Mais maintenant que tu en parles, j'ai remarqué sur le firmware du b535-333 (donc celui qui ne supporte pas le CLAT), un binaire tayga. Mais j'ai aussi comparé avec le b535-232 (petit frère du 235 sans prise tel) qui lui aussi supporte le CLAT et il n'y était pas, mais j'avais bien clatd. Et impossible de mettre la main sur celui du b535-235 hormis sur des sites payants.

Ou alors il y a simplement une règle en dur qui bloque le préfixe 64:ff9b::/96 pour forcer le passage en ipv4 littérale après pourquoi faire ça ? Mystère...

Non aucun accès, huawei a bien verrouillé son affaire...

Tayga sait faire du NAT64 mais on peut aussi l'utiliser comme un CLAT (c'est d'ailleurs ce que fait clatd de Tore Anderson), donc difficile de savoir sans investiguer plus.

Ah oui c'est vrai qu'il est en dépendance de clatd.

Sinon je viens de faire un traceroute et contre toute attente ça va plus loin que le routeur. Mais ça s'arrête au PLAT on dirait vu que les autres adresses sont en 64:ff9b::

Vers twitter.com :

Bridge :
renaud@Linuxmint:~$ traceroute 64:ff9b::68f4:2ac1
traceroute to 64:ff9b::68f4:2ac1 (64:ff9b::68f4:2ac1), 30 hops max, 80 byte packets
 1  2a04:cec0:1109:8c1e:b273:5dff:fec4:3d30 (2a04:cec0:1109:8c1e:b273:5dff:fec4:3d30)  0.927 ms  1.011 ms  1.096 ms
 2  2a04:cec0:1109:8c1e:0:61:5720:a40 (2a04:cec0:1109:8c1e:0:61:5720:a40)  118.908 ms  118.901 ms  118.968 ms
 3  * * *
 4  2001:860:b211:5100::14:4 (2001:860:b211:5100::14:4)  120.615 ms * *
 5  2001:860:b211:5100::15:3 (2001:860:b211:5100::15:3)  119.671 ms  119.884 ms  119.650 ms
 6  64:ff9b::a7d:7832 (64:ff9b::a7d:7832)  119.866 ms  38.488 ms  26.514 ms
 7  lo1-lns-c10k05-m.club-internet.fr (64:ff9b::5959:64e2)  32.505 ms  42.318 ms  42.308 ms
 8  64:ff9b::d4c2:aa00 (64:ff9b::d4c2:aa00)  50.578 ms  50.645 ms  50.371 ms
 9  be5.cbr01-cro.net.bbox.fr (64:ff9b::d4c2:ab8d)  50.545 ms  50.608 ms  59.256 ms
10  64:ff9b::3e22:2fa (64:ff9b::3e22:2fa)  50.288 ms  47.765 ms  45.754 ms
11  * * *
12  twitter2.par.franceix.net (64:ff9b::2531:ed47)  51.896 ms  51.869 ms  51.708 ms
13  * * *
14  64:ff9b::68f4:2ac1 (64:ff9b::68f4:2ac1)  56.066 ms  52.077 ms  41.056 ms
Routeur :
renaud@Linuxmint:~$ traceroute 64:ff9b::68f4:2ac1
traceroute to 64:ff9b::68f4:2ac1 (64:ff9b::68f4:2ac1), 30 hops max, 80 byte packets
 1  2a04:cec0:1104:de18:b273:5dff:fec4:3d30 (2a04:cec0:1104:de18:b273:5dff:fec4:3d30)  0.880 ms  0.966 ms  1.059 ms
 2  2a04:cec0:1104:de18:0:61:5721:5640 (2a04:cec0:1104:de18:0:61:5721:5640)  46.486 ms  46.475 ms  46.635 ms
 3  * * *
 4  2001:860:b211:5100::14:4 (2001:860:b211:5100::14:4)  46.719 ms  47.425 ms  47.615 ms
 5  2001:860:b211:5100::15:3 (2001:860:b211:5100::15:3)  46.651 ms  46.601 ms  46.633 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Je me suis amusé à faire un petit test ce soir : mettre l'IMEI de mon B525 (qui avait la dual stack avec l'APN eBouygtel.com) sur le Chateau LTE12.
Et bien il s'avère que.... Ça ne fonctionne pas ! Impossible d'avoir IPv4 et IPv6.

Donc soit ce n'est pas uniquement lié à l'IMEI soit le mode auto du Chateau LTE12 n'est pas en capacité d'obtenir la même chose que IPv4+IPv6 sur les Huawei.

C'est quand même bien dommage...