La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Bouygues Telecom => 
5G/4G Bouygues Telecom => Discussion démarrée par: fred et sylvie le 10 juin 2025 à 18:44:23
-
Salut à tous,
Sur mon iPhone 15 pro, j'ai reçu une mise à jour opérateur Bouygues, la 64.1
Celle ci permet d'activer la 5G SA dans les réglages.
2 observations:
1/ Bien qu'activer, la connexion ne semble pas se faire en Stand Alone, peut etre pas encore activée sur le réseau?
2/ Le profil 64.1 casse le VoWifi.
-
Oui, un autre utilisateur, antoinel, l'avait remarqué aussi. Cela montre que Bouygues Telecom a transmis ses paramètres SA à Apple, ce qui veut dire sans doute que l'ouverture de la SA chez Bouygues Telecom est proche. Mais donc pas encore activée sur le réseau.
https://lafibre.info/4g-orange/lancement-officiel-de-la-5g-sa-aujourdhui/msg1120647/#msg1120647
-
Selon Igen, Bouygues ouvre les vannes le 23/06 pour les clients GP
De mon côté, je rencontre aussi le souci des appels Wi-Fi qui ne fonctionnent plus et cela depuis cette mise à jour. Test croisé avec l’iPhone de madame, elle en SIM et moi en eSIM. Le chat Bouygues ne voit pas où est le problème, c’est activé de leur côté ???
Pas d’onglet pour la voix sur la 5G SA chez Bouygues contrairement à Orange
-
Bonjour,
Je confirme que j'ai perdu aussi la VoWifi sur Bouygues depuis la màj. J'ai un forfait BandY sur eSim.
-
Le lancement de la 5G SA pour le grand public chez Bouygues Telecom serait programmé le lundi 23 juin 2025, dans moins de deux semaines.
(source est Univers Freebox)
SFR devrait également lancer de la 5G SA dans quelques mois.
-
Effectivement, je viens de voir. Il sera intéressant de voir si la 5G SA sera activée sur le 3500 ET le 2100 MHz. Je parie sur le 3500 MHz seul, car il y a environ 6000 sites 2100 sans 3500 MHz, où les débits sans agrégation seraient plutôt faibles.
-
Bonjour,
VoWiFi cassé aussi avec réglages opérateur Bouygues Telecom 64.1 sur iPhone 12 et iPhone 12 mini avec eSIM et SIM physique respectivement. Sur le chat ils ne comprennent rien : Ils demandent sans cesse de redémarrer le téléphone. La restauration complète du téléphone remet la version 64.0 et les appels Wifi fonctionnent mais la mise à jour se fait toute seule et les casse à nouveau.
Merci
-
VoWiFi à nouveau fonctionnel avec la toute juste sortie version 64.2
-
Mise à jour 64.2 répare aussi le VoWifi chez moi aussi
-
Mise à jour Bouygues 64.2 voWiFi fonctionnel à nouveau
-
Depuis ce matin, j’ai perdu le wowifi et volte avec un message de iOS indiquant que ça a été désactivé. Je ne peux plus réactivé les appels wifi. Et vous ?
-
Pareil, sur mon iPhone 15 Pro, avec le dernier iOS, j’ai eu un message hier soir, et impossible de réactiver depuis.
J’ai laissé un message sur l’assistance ce matin
-
Ouais il y a un incident aujourd'hui, ils sont dessus
-
C'est résolu normalement. Il faut redémarrer le téléphone par contre.
-
J'ai pas eu besoin de rebooter mon iPhone, l'option appel wifi c'est re-selectionnée toute seule
-
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.
$ 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
$ 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 ?
-
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 :
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
-
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.
-
Je te confirme que ca fonctionne sans souci, sur les deux endpoints. Je peux passer des appels et envoyer/recevoir des SMS.
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.
-
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 (https://x0r.fr/blog/81) 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.
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)
-
Donc même avec l'ipv6 activé côté iphone, ce n'est pas une science exacte...
Non, clairement pas.
Je ne pense pas que le scénario IPv6 only côté wifi soit beaucoup testé par Apple. En tout cas, j'ai pu constater au fil du temps que des bugs corrigés dans une version pouvaient réapparaître dans la suivante, comme par exemple la non prise en compte des DNS recus par RA une fois sur 10... dans ces cas là, je me retrouvais avec une connectivité v6 mais pas de DNS (vu que je n'ai plus de v4 depuis longtemps). L'iPhone était connecté au réseau wifi sans afficher le logo wifi et n'utilisait que la connectivité cellulaire, même si au niveau IP, tout était OK en wifi (!).
Je n'ai pas d'info donc je ne peux que supposer, mais je pense que c'est une des raisons qui leur a fait embarquer un CLAT alors qu'ils obligeaient les devs à rendre leurs apps compatibles IPv6-only depuis longtemps : leur code VoWifi, FaceTime et configuration du réseau a eu pas mal de faiblesses côté IPv6 par le passé. Ca a l'air beaucoup mieux depuis iOS 17/18, mais il reste beaucoup de code Apple qui semble préférer IPv4 pour des raisons obscures.
Je me demande si l'implémentation de qualcomm est bien au point. Car j'ai vu passer un article de x0r (https://x0r.fr/blog/81) 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é.
Qualcomm n'est pas connu pour patcher ses produits après mise sur le marché... c'est même plutôt l'inverse de mon point de vue.
J'ai eu une seule fois une requête avec l'ipv6 du système mais toujours avec un record A.
Donc à priori, il a ce qu'il faut pour en émettre? Dans ce cas, il est resté en v4?
-
À priori, tout la partie vowifi est gérée par le modem et je ne pense pas que ça soit différent côté Apple, du coup y'a peut-être les mêmes bugs (t'as vérifié l'adresse MAC pour voir ? Je suis également affecté par le bug)... Le fait que ça ne prenne l'ipv6 que dans des cas bien précis semble aller dans ce sens. Ils ont peut-être demandé à qualcomm des correctifs spécifiques pour que ça marche un minimum.
Et dans mon cas même avec la requête en ipv6, la résolution reste en v4, oui.
-
Chez moi, pas de souci d'adressage MAC. Ce n'est clairement pas le souci que rencontre x0r: la VoWifi marche bien chez moi, le résolveur est sur le routeur (qu'il soit sur le routeur ou hors du LAN sur lequel se trouve le telephone est équivalent, en termes d'adressage MAC).
C'est juste qu'en IPv6, ca marche beaucoup mieux. Le chemin IPv4 a des pertes de paquets aléatoires. Pas énorme, mais en audio, ca fait vite des craquements ou le sentiment de rater le mot important de la phrase, et je suppose que ca doit créer des timeouts de négo IKE et/ou SIP.
Du coup, soit je fais un override du record epdg.epc.mnc020.mcc208.pub.3gppnetwork.org. pour forcer un AAAA, soit je désactive la VoWifi... à moins que Bouygues ne nous entende et republie ses endpoints v6 comme avant.
-
Alors c'est bizarre parce que de mon côté ça marche nickel. J'ai essayé de saturer ma connexion pour avoir de la perte et même dans ce cas j'ai pas une seule hachure dans le son, c'est impressionnant.
Cela dit j'ai remarqué que les paquets ipsec sont marqués en DSCP EF en envoie, ça doit bien aider. Il manque peut-être ce paramètre sur iphone ?