Auteur Sujet: VoWifi cassé [corrigé par maj Bouygues 64.2] (Lu 6471 fois)

Towny47 · « **Réponse #12 le:** 11 juillet 2025 à 16:39:31 »

Ouais il y a un incident aujourd'hui, ils sont dessus

Antoinel · « **Réponse #13 le:** 12 juillet 2025 à 11:54:02 »

C'est résolu normalement. Il faut redémarrer le téléphone par contre.

fred et sylvie · « **Réponse #14 le:** 12 juillet 2025 à 13:23:42 »

J'ai pas eu besoin de rebooter mon iPhone, l'option appel wifi c'est re-selectionnée toute seule

simon · « **Réponse #15 le:** 06 septembre 2025 à 18:10:26 »

Je me suis rendu compte que les IPv6 de la passerelle vowifi de Bouygues avaient été retirées du DNS car la VoWifi passait mal depuis quelques semaines et que je me demandais ce qui avait changé.
D'ailleurs, mon téléphone passe beaucoup moins en VoWifi depuis, je ne sais pas si c'est lié (probablement, car la mauvaise qualité des appels est à priori liée à un taux de perte de paquets important avec les passerelles en IPv4. Je suppose que ca n'aide pas le téléphone à établir le tunnel IPSec et s'inscrire sur l'IMS).
La couverture mobile chez moi n'a pas changé, avec 1 barre la plupart du temps, parfois 2 par beau temps.

Code: [Sélectionner]

$ host epdg.epc.mnc020.mcc208.pub.3gppnetwork.org
epdg.epc.mnc020.mcc208.pub.3gppnetwork.org has address 62.201.149.82
epdg.epc.mnc020.mcc208.pub.3gppnetwork.org has address 62.201.149.81

avant, on avait

Code: [Sélectionner]

$ host epdg.epc.mnc020.mcc208.pub.3gppnetwork.org
epdg.epc.mnc020.mcc208.pub.3gppnetwork.org has address 62.201.149.81
epdg.epc.mnc020.mcc208.pub.3gppnetwork.org has address 62.201.149.82
epdg.epc.mnc020.mcc208.pub.3gppnetwork.org has IPv6 address 2001:864:f100::2:c
epdg.epc.mnc020.mcc208.pub.3gppnetwork.org has IPv6 address 2001:864:f100::2:8

Les IP retirées répondent toujours, je me demande pourquoi elles ne sont plus dans le DNS. Un oubli suite à la panne ?

renaud07 · « **Réponse #16 le:** **Hier** à 04:47:05 »

Et si tu essaies de répondre les IPv6 à la place des DNS publics ?

De mon côté, je n'arrive toujours pas à utiliser l'IPv6 malgré mes 2 tels récents. J'imagine que c'est lié au profil en dur dans la ROM, la résolution DNS demande uniquement un record A... Et si j'essaie de ruser avec un CNAME il ne cherche pas à le résoudre, ça ne doit même pas être implémenté $:-\$

Car avec une résolution classique ça fonctionne bien :

Code: [Sélectionner]

host epdg.epc.mnc020.mcc208.pub.3gppnetwork.org
epdg.epc.mnc020.mcc208.pub.3gppnetwork.org is an alias for bouygues.vowifi.test.
bouygues.vowifi.test has IPv6 address 2001:864:f100::2:c

simon · « **Réponse #17 le:** **Hier** à 10:15:57 »

Le comportement peut dépendre de pas mal de facteurs, mais effectivement, si tu n'as qu'une A query, c'est que le composant VoWifi d'Android et/ou du firmware de ton téléphone ne tente pas d'utiliser la connectivité IPv6.
Je vais voir si je trouve le temps de faire un override DNS. Il faut le faire sur le resolveur car impossible d'éditer /etc/hosts sur un iPhone...

Par contre, chose intéressante: quand le record DNS avait des enregistrements AAAA, sur un réseau dual stack, l'iPhone préférait toujours IPv4 pour la VoWifi. Ce n'est que sur des réseaux v6-only + DNS64/NAT64 qu'il utilisait IPv6.

simon · « **Réponse #18 le:** **Hier** à 11:48:23 »

Je te confirme que ca fonctionne sans souci, sur les deux endpoints. Je peux passer des appels et envoyer/recevoir des SMS.

Code: [Sélectionner]

09:43:03.189619 IP6 2a01:cb08:xxxx:xx03:5dc1:37:f691:6bfe.49375 > 2a01:cb08:xxxx:xx03::9.53: 55708+ A? epdg.epc.mnc020.mcc208.pub.3gppnetwork.org. (60)
09:43:03.191833 IP6 2a01:cb08:xxxx:xx03:5dc1:37:f691:6bfe.60495 > 2a01:cb08:xxxx:xx03::9.53: 11451+ AAAA? epdg.epc.mnc020.mcc208.pub.3gppnetwork.org. (60)
09:43:03.192349 IP6 2a01:cb08:xxxx:xx03::9.53 > 2a01:cb08:xxxx:xx03:5dc1:37:f691:6bfe.60495: 11451* 2/0/0 AAAA 2001:864:f100::2:c, AAAA 2001:864:f100::2:8 (116)
09:43:03.211038 IP6 2a01:cb08:xxxx:xx03::9.53 > 2a01:cb08:xxxx:xx03:5dc1:37:f691:6bfe.49375: 55708 2/0/0 A 62.201.149.82, A 62.201.149.81 (92)
09:43:03.259295 IP6 2a01:cb08:xxxx:xx03:1c89:a3ce:f943:3d80.500 > 64:ff9b::3ec9:9552.500: isakmp: parent_sa ikev2_init[I]
09:43:04.232362 IP6 2a01:cb08:xxxx:xx03:5dc1:37:f691:6bfe.54678 > 2a01:cb08:xxxx:xx03::9.53: 35947+ AAAA? ipv4only.arpa. (31)
09:43:04.232900 IP6 2a01:cb08:xxxx:xx03::9.53 > 2a01:cb08:xxxx:xx03:5dc1:37:f691:6bfe.54678: 35947 2/0/0 AAAA 64:ff9b::c000:aa, AAAA 64:ff9b::c000:ab (87)
09:43:04.409005 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500 > 2001:864:f100::2:c.500: isakmp: parent_sa ikev2_init[I]
09:43:04.424174 IP6 2001:864:f100::2:c.500 > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500: isakmp: parent_sa ikev2_init[R]
09:43:04.443094 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500 > 2001:864:f100::2:c.500: isakmp: child_sa  ikev2_auth[I]
09:43:04.599350 IP6 2001:864:f100::2:c.500 > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500: isakmp: child_sa  ikev2_auth[R]
09:43:04.921440 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500 > 2001:864:f100::2:c.500: isakmp: child_sa  ikev2_auth[I]
09:43:05.162825 IP6 2001:864:f100::2:c.500 > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500: isakmp: child_sa  ikev2_auth[R]
09:43:05.250649 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500 > 2001:864:f100::2:c.500: isakmp: child_sa  ikev2_auth[I]
09:43:05.409822 IP6 2001:864:f100::2:c.500 > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7.500: isakmp: child_sa  ikev2_auth[R]
09:43:05.482680 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x1), length 136
09:43:05.566416 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x1), length 120
09:43:06.090894 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x2), length 120
09:43:06.090973 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x3), length 136
09:43:06.119227 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x2), length 120
09:43:06.121247 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x4), length 104
09:43:06.121315 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x5), length 1352
09:43:06.121354 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x6), length 456
09:43:06.152904 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x3), length 104
09:43:06.327909 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x4), length 952
09:43:06.445180 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x7), length 104
09:43:06.669932 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x8), length 168
09:43:06.698889 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x5), length 168
09:43:06.701103 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0x9), length 152
09:43:06.702366 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0xa), length 1384
09:43:06.702432 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0xb), length 1000
09:43:06.732373 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x6), length 152
09:43:06.738800 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x7), length 152
09:43:07.075665 IP6 2001:864:f100::2:c > 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7: ESP(spi=0x0ee50c78,seq=0x8), length 1144
09:43:07.136741 IP6 2a01:cb08:xxxx:xx03:38:9851:c3ff:15c7 > 2001:864:f100::2:c: ESP(spi=0x43002d5a,seq=0xc), length 152

Chose intéressante : l'iPhone essaye en v4 à travers la passerelle NAT64 d'abord, puis, sans réponse, essaye l'adresse v6 native une seconde plus tard... je me demande si c'est l'opérateur qui définit ce comportement par son fameux carrier bundle ou si c'est juste un bout de code qui privilégie toujours l'IPv4, comme il en reste beaucoup.

Je viens de faire un second test: si j'active un DHCPv4 sur le réseau et malgré la présence d'un AAAA pour epdg.epc.mnc020.mcc208.pub.3gppnetwork.org., l'iphone essaye en boucle l'adresse IPv4, et même si cette dernière ne répond jamais (mon routeur wifi de test n'a pas de route v4), il ne tente jamais en v6.
Si je veux qu'il tente d'utiliser v6, que ce soit par le NAT64 ou en direct, il faut couper v4 entièrement.

renaud07 · « **Réponse #19 le:** **Hier** à 18:02:27 »

Donc même avec l'ipv6 activé côté iphone, ce n'est pas une science exacte...

Je me demande si l'implémentation de qualcomm est bien au point. Car j'ai vu passer un article de x0r pour qui la vowifi ne fonctionnait pas : les requêtes partent bien avec l'IP du DNS mais avec l'@MAC du routeur par défaut et son routeur rejetait les paquets au lieu de les re-router. Si ça ne pose pas de souis si le routeur fait aussi DNS, dans son cas avec un DNS tiers, ça ne fonctionnait pas. Apparemment, c'est un bug connu de longue date et toujours pas corrigé.

Je vais essayer avec de l'ipv6 only pour voir si j'obtiens une résolution AAAA car j'ai toujours du dualstack de mon côté, c'est peut-être pour ça aussi que je n'obtiens qu'une requête A.

EDIT : Expérience non concluante. Aucune requête AAAA. J'ai eu une seule fois une requête avec l'ipv6 du système mais toujours avec un record A. Et en v6 only, rien du tout.

Code: [Sélectionner]

18:18:13.386093 IP6 2a01:cbxx:xxx:xxxx:4030:eb39:abf2:7dfe.44584 > fd07:ad3c:7:0:192:168:1:10.domain: 19892+ A? epdg.epc.mnc020.mcc208.pub.3gppnetwork.org. (60)