La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Orange / Sosh => 
5G/4G Orange => Discussion démarrée par: ro78 le 09 février 2022 à 22:34:16
-
Bonjour à tous,
Depuis plus d’un an, à cause d’un signal 4G très moyen à l’intérieur de mon domicile, j’ai activé le VoWiFi.
Malgré une fibre Orange 1 Gbps, du Wi-Fi 6 et de très bons débits (500+ Mbps) sur deux iPhones récents et à jour, lors d’un appel dans la même pièce que la box ou que le répéteur Wi-Fi (6 aussi), la voix coupe souvent et parfois l’appel est coupé avec « échec de l’appel ».
J’en viens souvent à désactiver le Wi-Fi avant de rappeler mon correspondant pour avoir une qualité d’appel convenable (stable), en tout cas meilleure qu’en Wi-Fi.
Est-ce que ça fonctionne bien chez vous en général cette fonctionnalité ? Des idées pour améliorer la situation ?
-
Bonjour
Oui ça fonctionne bien. Faut peut-être utiliser un autre retour WiFi que la box. Il n’y a pas de QoS qui priorise la VoWiFi sur les box/routeurs de base. Et les Box opérateurs sont pas toujours un modèle de fiabilité quand la connexion est sollicitée par plusieurs postes en même temps, même si ça ne sature 100% de la connexion. Le fait qu’il y ait pleins de connexions ou momentanément des gros transferts, la VoWiFi se dégrade car il y a des paquets perdus ou droppés.
J’ai aussi remarqué des fois qu’un redémarrage box/routeurs WiFi permettait souvent de remettre tout ça d’équerre.
Enfin les répéteurs WiFi peuvent aussi poser pb, ça fait bcp de bonds radios pour joindre la connexion donc risques de brouillages et risques de coupures. De même il n’est pas impossible que la comm soit initiée sur un relais WiFi et en se déplaçant dans une autre pièce ou même de quelques mètres, le signal du répéteur ou d’un des routeurs WiFi faiblit et ça coupe. Je ne crois pas qu’il y ait de Hand over en cours de comm en VoWiFi.
Et des fois on est plus proche de la box on pense être dessus mais en fait on est accroché à un WiFi plus éloigné.
-
Le répéteur Wi-Fi est relié à la box en Ethernet, et quand je passe un appel, je fais justement exprès de rester au même endroit (à proximité de la box ou du répéteur) pour ne pas risquer de changer l'AP auquel je suis connecté...
-
Bonjour,
Aucun soucis d'appels sur un abo Orange en wifi sur un abo RED fibre chez moi.
J'ai installé ceci chez des amis qui captent rien en 2/3/4G -> https://www.amazon.fr/gp/product/B07XY7WJ4W/
C'est très efficace et apporte une vraie redondance pas celle des el famoso répéteurs wifi6 vendus et fournis par les FAI ;)
On branche, on configure et on désactive son wifi de box, le système prend le relai.
On peut même paramétrer aux petits oignons des plages horaires d'accès et spécifier des débit max pour un client (smartphone enfants etc).
Reboot à distance depuis le chalet à Megève et tout le tintouin 8)
C'est pas donné mais ça vaut son prix :P
-
Je pense que le Wi-Fi n'est pas le coupable, celui de la box est bien coupé pour laisser deux AP Wi-Fi 6 (by Orange) prendre le relais, et j'ai le même problème avec du matériel plus conséquent (2 x Netgear Orbi Wi-Fi 6 RBK752).
-
Avez vous possibilité de tester avec un Android phone ?
Et de tester en direct sur la box, orbi et répéteurs complètement débranchés pour ne laisser que la box gérer le wifi le temps du test ?
-
Je n'ai pas d'appareil Android pour tester malheureusement... et non j'ai coupé le Wi-Fi de la box depuis le Wi-Fi 6 mais le problème était déjà présent quand je n'utilisais que celui-ci.
-
Je suppose que les téléphones sont sur la bande des 5 GHz ? est ce le même soucis sur la bande 2,4 GHz ?
-
Effectivement ils sont par défaut en 5 GHz. Je tenterai le 2.4 quand je pourrais, c'est une piste.
-
De mon côté pas de problème particulier en VoWifi sur les 3 iPhones de la maison, Fonctionnement irréprochable. Par contre je n’utilise aucun équipement de mon opérateur fibre mais un EdgeRouter ER4 et 2 Ubiquiti U6-Lite répartis dans l’appartement.
-
Le répéteur Wi-Fi est relié à la box en Ethernet, et quand je passe un appel, je fais justement exprès de rester au même endroit (à proximité de la box ou du répéteur) pour ne pas risquer de changer l'AP auquel je suis connecté...
Ça peut tout simplement être le switch ou le routeur de la Box qui ne suit pas quand il y a du trafic.
-
Le même téléphone connecté au même point d'accès me sort des speed-tests à 800+ Mbps... je pense pas que ça soit la bonne piste ?
-
C'est pas le débit qui est important avec la VoIP c'est la latence et la gigue.
J'ai un iPhone, Wi-Fi exclusivement Ubiquiti avec du Band Steering vers le 5Ghz, WPA3, sur les bandes 36 et 149 en 80 MHz respectivement sur 2 AP et je n'ai absolument aucun soucis en VoWiFi, même avec du roaming entre bornes, pas de soucis de voix.
-
Je sens que je vais craquer pour les Ubiquiti :)
Il faut un UDM pour gérer les AP Wi-Fi ?
-
Non en réseau ou Bluetooth avec l'appli Unifi Network pour des réglages basiques, sinon machine virtuelle Linux pour avoir un contrôleur avec toutes les fonctions avancées, le monitoring etc...
C'est pas forcement la source du soucis, mais en tous cas moi ça fonctionne très bien comme ça.
-
C'est pas forcement la source du soucis, mais en tous cas moi ça fonctionne très bien comme ça.
Ils me faisaient déjà de l'oeil de toute façon ;)
-
C'est pour poser sur un meuble ou fixer au mur/plafond ?
-
Sur un meuble probablement.
-
Faut peut-être attendre ce modèle qui sera, par sa forme, possible de poser sur un meuble :
https://eu.store.ui.com/collections/unifi-network-wireless/products/access-point-wifi-6-mesh (https://eu.store.ui.com/collections/unifi-network-wireless/products/access-point-wifi-6-mesh)
-
Samsung galaxy S21 FE sur SOSH , VoWifi via mon TPLink AX50 connecté sur ma livebox 4 en VDSL2. RAS. Idem sur mon ancien Iphone 12 et le S20 FE de madame! A peine le numéro composé, ça sonne direct et le son est excellent !
Aucun problème également lorsque je suis chez mon beauf sur sa 4G box Free ( Forfait illimité avec un TPLINK Archer MR 600 )
-
Je constate pareil, ça sonne immédiatement quand on commence l’appel, c’est vraiment juste la voix hachée par moment dans les conversations, et de temps en temps une coupure total de l’appel pour « échec d’appel ». Dès que je peux je test avec un autre matériel Wi-Fi.
-
Aucun problème chez moi que ce soit sur le WiFi de la LB5 ou sur l'un des répéteurs WiFi Orange.
Et pas non plus de coupure d'appel en passant d'un répéteur à l'autre.
-
Je constate pareil, ça sonne immédiatement quand on commence l’appel, c’est vraiment juste la voix hachée par moment dans les conversations, et de temps en temps une coupure total de l’appel pour « échec d’appel ». Dès que je peux je test avec un autre matériel Wi-Fi.
Je ne sais plus si cela a été dit plus haut mais as tu essayé le VoWifi sur une autre box, genre chez un ami ?
-
Je constate pareil, ça sonne immédiatement quand on commence l’appel, c’est vraiment juste la voix hachée par moment dans les conversations, et de temps en temps une coupure total de l’appel pour « échec d’appel ». Dès que je peux je test avec un autre matériel Wi-Fi.
Hum Hum ::)
Je pense que le Wi-Fi n'est pas le coupable, celui de la box est bien coupé pour laisser deux AP Wi-Fi 6 (by Orange) prendre le relais, et j'ai le même problème avec du matériel plus conséquent (2 x Netgear Orbi Wi-Fi 6 RBK752).
C'est bien, au moins vous n'êtes pas buté comme certains ;)
-
Hum Hum ::)
C'est bien, au moins vous n'êtes pas buté comme certains ;)
Le problème des appels VoWifi est que dès que l'on a un appel en étant en Wifi, ensuite si on se trouve en limite de couverture de la borne wifi mais pas assez pour basculer l'appel en 4G c'est souvent dans ce cas que la voix est pas de bonne qualité....
A moins d'avoir un super réseau wifi pro avec pleins de bornes et do roaming à la maison dans ce cas les appels VoWifi sont intéressants (pour couvrir un sous-sol, une zone sans 4G) mais dès que l'on va se connecter à un réseau wifi de mauvaise qualité (magasin , aéroport, gare, hotel, etc...) tous les appels en VoWifi seront pourris...
Idéalement il faudrait une option pour activer les appels VoWifi uniquement sur une liste de réseau wifi et pas les autres, la ce serait top !
-
Petit HS désolé ;D
Je suis repassé aujourd'hui sur Orange ( Sosh ) après un bref passage sur Bouygues ( B&You ) et la par contre la VoWifi quand elle veut fonctionner est vraiment pas top car ça coupe sans arrêt, le son est bof. Depuis ce matin que du bonheur de retrouver le réseau Orange ;) Et je ne vous parlerais pas des débits pourri de Bouygues :o
HS terminé ! ;D
-
Je remonte le sujet.
Chez moi la VoWifi orange c'est aussi une catastrophe. Ça coupe de manière totalement aléatoire, ça peut tenir 30 min comme couper ou bout d'une minute. J'ai aussi pensé que ça venait de la bascule entre mes points d'accès, j'en ai donc laissé qu'un, mais ça persiste.
Suite à une discussion sur hardware.fr hier, un membre m'a fait part également de son expérience désastreuse et m'a dit qu'avec Bouygues tout fonctionnait parfaitement. Ayant justement souscrit un forfait b&you y'a 1 mois je décide de tester : l'appel a tenu 2h25 sans broncher (après quoi j'ai raccroché). Mon dernier test avec Orange a tenu 30 min sans bouger le téléphone d'un mm.
Y'a donc réellement un problème quelque part... peut-être pas partout certes.
Je ferais bien une capture mais je sais pas si on verrait grand chose de plus ?
EDIT : Je vois qu'orange dispose de 6 IP distinctes et autant d'ePDG derrière je suppose :
~$ dig A epdg.epc.mnc001.mcc208.pub.3gppnetwork.org
; <<>> DiG 9.16.1-Ubuntu <<>> A epdg.epc.mnc001.mcc208.pub.3gppnetwork.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3038
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. IN A
;; ANSWER SECTION:
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. 2806 IN A 80.12.36.221
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. 2806 IN A 80.12.36.253
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. 2806 IN A 80.12.26.24
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. 2806 IN A 80.12.36.249
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. 2806 IN A 80.12.25.138
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org. 2806 IN A 80.12.25.143
;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: mer. août 10 13:58:27 CEST 2022
;; MSG SIZE rcvd: 167
Si ça se trouve certains on une conf différente ? D'où le fait que ça soit aléatoire ?
Je vais essayer chaque IP voir si ça bug sur toutes ou pas.
-
Me concernant c'est plus l'inverse ;D
-
Abo Orange 4G+ -> Samsung 20FE 4G firmware SFR -> aucun problème, ça tient 5h sur une co RED WiFi 5Ghz ;)
-
Bon, un truc semble se dessiner.
J'ai testé en appelant ma ligne OVH et voici les résultats :
80.12.36.221 : 6m14s
80.12.36.253 : 23m10s
80.12.25.138 : 24m32s
80.12.36.249 : 24m39s
80.12.26.24 : 24m21s
Il semble que ça coupe toujours autour des 25 min, sauf la première faut que je réessaie. Après en usage "normal" donc en appelant divers numéros, ça coupait bien avant. Genre l'autre fois ça m'a jeté au bout de 3min sur un appel important >:(
Franchement je sais pas quoi penser. J'ai aussi tenté une capture, mais on ne voit absolument rien (genre un reset de connexion ou quoi) juste les paquets ESP qui défilent et s'arrêtent sans rien d'autre...
Le plus frustrant c'est que la VoLTE marche nickel, je suis resté plusieurs fois jusqu'aux 3h réglementaires sans le moindre problème. D'ailleurs, j'ai remarqué que RED avait baissé le seul à 2h/appel il a quelques semaines.
-
Y'a un moyen de faire une capture du trafic vowifi depuis le smartphone ? J’aimerais bien voir ce qui se passe à l'intérieur.
Problème : aucune interface ne semble liée, je pensais retrouver une ip privée attribué aux interfaces vti (il me semble bien que c'est celles-là pour ipsec ?) mais à la place j'ai ça :
4: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
5: ip6_vti0@NONE: <NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
6: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
7: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
-
Après plus amples recherches : Apparemment le trafic du tunnel se fait sur une interface cachée, appelée epdg1. Sauf que j'ai beau lancer un tcpdump dessus, il me dit qu'elle est introuvable... J'ai aussi tenté 0 ou 2 (étant donné que j'ai aussi bouygues actif en même temps, sans résultat). Ou alors il faut un paramètre spécifique ?
Pour voir un semblant d'activité, j'ai vu qu'il existait un "onglet" dans network signal guru qui indique l'état SIP, sauf que lorsque ça coupe, j'ai rien de spécifique... donc on ne peut pas en savoir plus.
J'ai tout de même pu découvrir que la bascule VoWifi > VoLTE fonctionne très bien lorsque je désactive volontairement, donc à priori ce n'est même pas lié à une perte du signal wifi vu que ça ne bascule pas en VoLTE lorsque ça coupe.
-
Chez sosh meme sur une ADSL bancale chez mes parents, je n'ai pas de soucis, j'ai deja fais des appels de plus de 1h30.
-
Le fonctionnement de la VoWifi semble différencier entre mobile/marque.
J'ai installé un PA wifi 6 ( TPlink AX50 ) au sous sol de ma maison centré le mieux possible. Le wifi de la lb4 est désactivé.
Tous mes mobiles sont sur le wifi 5ghz ( j'ai différencié les 2 )
J'en remplacé hier mon S21 FE par un Iphone 13 pro. Ce dernier reste parfaitement en Vowifi partout dans la maison avec une qualité audio des voix incroyable. Le samsung a peine éloigné du PA , perte du Vowifi. C'est un peu mieux en wifi 2.4 mais sans plus. Avec le S20 FE de madame, ça tient pas trop mal sans toute fois être du niveau de l'iphone. Un ami sur Oneplus ça tient relativement bien. Mais la aussi on est pas au niveau de l'iphone. Pourtant tous les mobiles gardent un niveau de réception assez bon qui
Je ne fais bien sur pas la pub d'Iphone mais il est étonnant de voir avec le même réseau une telle différence.
-
Les iPhones sont probablement les plus testés dans les labos des opérateurs (peu de modèles différent, grosse part de marché) et Apple qui doit faire de même lors de la validation des configuration VoLTE/VoWifi avec les opérateurs ...
-
Y'a un moyen de faire une capture du trafic vowifi depuis le smartphone ? J’aimerais bien voir ce qui se passe à l'intérieur.
Problème : aucune interface ne semble liée, je pensais retrouver une ip privée attribué aux interfaces vti (il me semble bien que c'est celles-là pour ipsec ?) mais à la place j'ai ça :
4: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
5: ip6_vti0@NONE: <NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
6: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
7: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
Sous linux, tu peux soit faire de l'IPSec VTI (en routant le traffic sur une interface virtuelle dédiée au tunnel: les *_vti que tu observes), soit en utilisant la méthode traditionnelle d'interception des packets par la stack IPsec lors du routage (visible avec ip xfrm policy / ip xfrm state).
La methode VTI est plus récente et a été ajoutée pour permettre la capture des packets traversant le tunnel ainsi que de faciliter le firewalling, mais elle n'est en pratique que très peu utilisée.
À mon avis, elle n'est pas utilisée sur ton mobile. tcpdump devrait normalement voir le traffic entrant avant et après déchiffrement IPSec sur l'interface wifi.
Par contre, il ne pourra pas capturer le traffic sortant avant chiffrement. Peut-être que tu pourrais logguer ce traffic par une autre méthode, comme des règles xtables/iptables avec -J LOG ?
Sur iOS, je vois bien des interfaces ipsec[0-4] dédiées à la VoWIFI. On doit pouvoir capturer des choses intéressantes sur ces dernières après un jailbreak (je n'ai jamais tenté le jailbreak par souci de sécurité).
Rien à voir avec Orange mais puisqu'on parle de qualité VoWIFI, l'activation par Bouygues d'ipv6 sur sa passerelle IMS IPSec a fait une énorme différence pour moi (sur un iphone 6 qui commence à sérieusement montrer des rides...).
$ 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
Avant, le VoWIFI s'activait/se désactivait aléatoirement, j'avait pas mal de hachures ou de call drops, et je ratais pas mal d'appels entrants. Je n'ai maintenant plus aucun drop ou appel manqué, et la qualité audio est aussi bonne qu'en LTE.
Je n'ai jamais pu tester la VoWIFI d'Orange car ils ne supportent pas l'iphone 6...
-
Petit bug de l'antenne de ma commune, pas de réseau (comme souvent). Mon iphone est en VoWifi mais comme de par hasard , la VoWifi bug, ça décroche. Pourtant jusque la RAS.
-
Petit bug de l'antenne de ma commune, pas de réseau (comme souvent). Mon iphone est en VoWifi mais comme de par hasard , la VoWifi bug, ça décroche. Pourtant jusque la RAS.
Vu que pas mal de soucis de VoWifi chez Orange sont habituellement remontés, ca ne serait pas simplement qu'en temps normal (quand l'antenne LTE qui te couvre fonctionne), si un problème de qualité en VoWifi survient, ton téléphone bascule automatiquement sur la LTE?
Et que dans ce cas précis, la LTE n'étant pas disponible, ton téléphone est resté en VoWifi tout du long ?
Tu peux éventuellement essayer de laisser tourner un ping vers la ou les passerelle(s) IMS utilisée(s) pour la VoLTE pendant un appel VoWifi problématique, pour observer une gigue ou perte de paquets éventuels qui pourraient influer sur la qualité de l'appel.
-
Sous linux, tu peux soit faire de l'IPSec VTI (en routant le traffic sur une interface virtuelle dédiée au tunnel: les *_vti que tu observes), soit en utilisant la méthode traditionnelle d'interception des packets par la stack IPsec lors du routage (visible avec ip xfrm policy / ip xfrm state).
La methode VTI est plus récente et a été ajoutée pour permettre la capture des packets traversant le tunnel ainsi que de faciliter le firewalling, mais elle n'est en pratique que très peu utilisée.
À mon avis, elle n'est pas utilisée sur ton mobile. tcpdump devrait normalement voir le traffic entrant avant et après déchiffrement IPSec sur l'interface wifi.
Par contre, il ne pourra pas capturer le traffic sortant avant chiffrement. Peut-être que tu pourrais logguer ce traffic par une autre méthode, comme des règles xtables/iptables avec -J LOG ?
Sur iOS, je vois bien des interfaces ipsec[0-4] dédiées à la VoWIFI. On doit pouvoir capturer des choses intéressantes sur ces dernières après un jailbreak (je n'ai jamais tenté le jailbreak par souci de sécurité).
Rien à voir avec Orange mais puisqu'on parle de qualité VoWIFI, l'activation par Bouygues d'ipv6 sur sa passerelle IMS IPSec a fait une énorme différence pour moi (sur un iphone 6 qui commence à sérieusement montrer des rides...).
$ 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
Avant, le VoWIFI s'activait/se désactivait aléatoirement, j'avait pas mal de hachures ou de call drops, et je ratais pas mal d'appels entrants. Je n'ai maintenant plus aucun drop ou appel manqué, et la qualité audio est aussi bonne qu'en LTE.
Je n'ai jamais pu tester la VoWIFI d'Orange car ils ne supportent pas l'iphone 6...
Merci beaucoup. J'avais totalement loupé ton message.
J'ai enfin pu mettre la main sur les clés de chiffrement. J'ai fait quelques tests hier et si j'arrive bien à déchiffrer le trafic, il y a toute une partie au début qui ne veut rien savoir, j'imagine que c'est la phase 1 dont j'ai raté la clé.
Sinon j'ai remarqué des trucs intéressants : J'ai passé la commande ip xfrm state dans watch actualisé toutes les secondes. Et lors de la coupure, j'ai remarqué qu'elle ne renvoyait plus rien avant de revenir quelques secondes plus tard avec de nouvelles clés. J'en déduis donc que le tunnel coupe brutalement... reste à savoir pourquoi.
Autre bizarrerie, je m'attendais à trouver au milieu du trafic RTP un peu de SIP hors j'ai rien du tout, seulement de temps en temps un paquet RTCP.
-
Si tu ne vois que le média RTP/RTCP, es-tu sûr qu'il n'y a qu'une session IPSec/ESP d'établie ?
Il peut potentiellement y en avoir plusieurs, par exemple une avec l'IMS pour le signalling et une autre avec un media proxy pour le RTP/RTCP, et ce même si tu ne vois qu'une seule adresse IP avec laquelle des paquets ESP sont échangés.
Et lors de la coupure, j'ai remarqué qu'elle ne renvoyait plus rien avant de revenir quelques secondes plus tard avec de nouvelles clés. J'en déduis donc que le tunnel coupe brutalement... reste à savoir pourquoi.
Sais-tu quel soft est utilisé sur ton téléphone pour négocier la phase1 et les clefs? openswan? strongswan? openiked? raccoon ?
Tu dois pouvoir trouver une raison à cette fin de session en regardant dans les logs de ce soft, si il y en a.
Je n'ai jamais fait de reverse engineering sur un téléphone android donc mes connaissances à ce niveau sont maigres...
On peut éventuellement aussi tenter de savoir qui entre ton téléphone et la passerelle IPSec met fin à l'associaton en analysant la capture. Serais-tu prêt à la partager (avec les clefs de session IPSec évidemment) ? Je serai assez intéressé d'y jeter un oeil :)
A priori, même en déchiffrant le traffic IPSec, on ne devrait pas y trouver de mots de passe : c'est normalement EAP-SIM qui est utilisé pour authentifier le téléphone (la carte SIM, en fait) auprès de la passerelle IPSec.
-
Alors, j'ai continué mes tests et il en ressort que :
- J'ai le début de la séquence SIP jusqu'au 401 Unauthorized puis de nouveau chiffré puis ma séquence RTP. Donc ton hypothèse semble juste ça doit chiffrer en plus lors de l'envoie des "secrets" de la SIM je suppose. Mais pour le coup, je ne sais pas comment récupérer ces clés là.
-à priori c'est racoon qui est utilisé
-je n'ai pas réussi à trouver les logs correspondants (si c'était pas autant le bor*el dans l'arborescence...) ni avec logcat.
EDIT : A priori pour les autres clés, c'est pas la même limonade, faut aller fouiller la RAM avec un logiciel et ensuite convertir les données avec un script... Je crois que je vais m'arrêter là :(
-
Rien à voir avec Orange mais puisqu'on parle de qualité VoWIFI, l'activation par Bouygues d'ipv6 sur sa passerelle IMS IPSec a fait une énorme différence pour moi (sur un iphone 6 qui commence à sérieusement montrer des rides...).
$ 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
Avant, le VoWIFI s'activait/se désactivait aléatoirement, j'avait pas mal de hachures ou de call drops, et je ratais pas mal d'appels entrants. Je n'ai maintenant plus aucun drop ou appel manqué, et la qualité audio est aussi bonne qu'en LTE.
En parlant d'ipv6, chez moi, la connexion se fait toujours en ipv4 alors que j'ai bien de l'ipv6 sur mon réseau. J'imagine qu'il doit falloir mettre le profil à jour. J'aimerais bien savoir où ça se trouve d'ailleurs histoire de voir si on peut le modifier.
-
En parlant d'ipv6, chez moi, la connexion se fait toujours en ipv4 alors que j'ai bien de l'ipv6 sur mon réseau. J'imagine qu'il doit falloir mettre le profil à jour. J'aimerais bien savoir où ça se trouve d'ailleurs histoire de voir si on peut le modifier.
Aucune idée de si il y a un paramètre sur le téléphone pour ca, mais dans tous les cas il faut que la gateway IPSec de ton opérateur soit configurée pour, et pour Orange ca n'a pas l'air d'être le cas:
$ 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
$ host epdg.epc.mnc001.mcc208.pub.3gppnetwork.org.
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org has address 80.12.25.143
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org has address 80.12.26.24
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org has address 80.12.36.221
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org has address 80.12.36.249
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org has address 80.12.36.253
epdg.epc.mnc001.mcc208.pub.3gppnetwork.org has address 80.12.25.138
mnc001 est Orange, mnc020 est Bouygues.
- J'ai le début de la séquence SIP jusqu'au 401 Unauthorized puis de nouveau chiffré puis ma séquence RTP. Donc ton hypothèse semble juste ça doit chiffrer en plus lors de l'envoie des "secrets" de la SIM je suppose. Mais pour le coup, je ne sais pas comment récupérer ces clés là.
Quand tu dis "puis de nouveau chiffré", vois-tu des paquets UDP/SIP dont le contenu est chiffré, ou simplement du traffic ESP sans en-tête UDP?
-à priori c'est racoon qui est utilisé
-je n'ai pas réussi à trouver les logs correspondants (si c'était pas autant le bor*el dans l'arborescence...) ni avec logcat.
Okay, si raccoonctl est présent sur ton device tu devrais pouvoir faire "raccoonctl show-event -l" avant d'activer la VoWifi pour voir ce qui se passe au niveau IPSec.
Ces évènements, si tu arrives à les obtenir, devraient pouvoir nous permettre de comprendre ce qui coupe la session IPSec pendant tes appels.
Note que raccoon ne s'occupe que de la couche IPSec, tout ce qui est SIP et RTP va certes passer dans l'un de ces tunnels IPSec, mais va être gérés autre part (IPSec n'est là que pour chiffrer et authentifier ce traffic).
-
Aucune idée de si il y a un paramètre sur le téléphone pour ca, mais dans tous les cas il faut que la gateway IPSec de ton opérateur soit configurée pour, et pour Orange ca n'a pas l'air d'être le cas:
[...]
mnc001 est Orange, mnc020 est Bouygues.
Je parle de bouygues pour le coup (le tel ne fait qu'une requête A pour les deux). Orange c'est mort en effet.
Quand tu dis "puis de nouveau chiffré", vois-tu des paquets UDP/SIP dont le contenu est chiffré, ou simplement du traffic ESP sans en-tête UDP?
Alors en fait je me suis mélangé les pinceaux ::) Au début je capturais bouygues au lieu d'orange... Le trafic redevient chiffré avec BT. Et dans ce cas, le paquet est déchiffré partiellement, j'ai toujours de l'ESP mais les adresses IPv6 sont visibles. Je suppose donc qu'on est en mode transport. Par contre pas de distinction entre RTP et SIP, j'ai UDP uniquement.
Pour Orange : finalement ça à l'air plus simple : j'ai toujours une partie du trafic chiffré (environ 4 pour un déchiffré, qui cette fois est bien détecté comme étant en AMR) mais cette fois j'ai presque la séquence SIP complète : register, subscribe, invite... par contre les paquets chiffrés le sont totalement : aucune ipv6 visible
EDIT : C'est ultra bizarre, cette fois Orange se comporte comme Bouygues. Lors de la coupure et du nouveau tunnel, j'ai cette fois les paquets chiffrés à moitié après le 401. Et lors du test avec le premier tunnel, aucune trace de register
Bref, un joyeux bordel...
Okay, si raccoonctl est présent sur ton device tu devrais pouvoir faire "raccoonctl show-event -l" avant d'activer la VoWifi pour voir ce qui se passe au niveau IPSec.
Ces évènements, si tu arrives à les obtenir, devraient pouvoir nous permettre de comprendre ce qui coupe la session IPSec pendant tes appels.
Note que raccoon ne s'occupe que de la couche IPSec, tout ce qui est SIP et RTP va certes passer dans l'un de ces tunnels IPSec, mais va être gérés autre part (IPSec n'est là que pour chiffrer et authentifier ce traffic).
Pas de racoonctl. J'ai racoon tout court mais qui donne très peu d'options :
willow:/ # racoonctl
/system/bin/sh: racoonctl: inaccessible or not found
127|willow:/ # racoon
Usage: racoon <interface> <server> [...], where [...] can be:
udppsk <identifier> <pre-shared-key> <port>;
udprsa <user-private-key> <user-certificate> \
<ca-certificate> <server-certificate> <port>;
xauthpsk <identifier> <pre-shared-key> \
<username> <password> <phase1-up> <script-arg>;
xauthrsa <user-private-key> <user-certificate> \
<ca-certificate> <server-certificate> \
<username> <password> <phase1-up> <script-arg>;
hybridrsa <ca-certificate> <server-certificate> \
<username> <password> <phase1-up> <script-arg>;
-
Après un coup de bol monstrueux, tous les paquets veulent bien se faire déchiffrer ! Il devait donc y avoir un problème dans mes autres captures...
Au moment de la coupure, on voit que le smartphone envoie un dernier paquet voix puis demande l'initiation d'un nouveau tunnel et l'epdg renvoie la dernière séquence juste après.
Il semble donc que c'est le smartphone qui coupe et pas Orange :-\
-
J'ai repris mes investigation car je compte bien trouver la source du problème.
Après avoir un peu plus fouillé, je suis tombé sur un topic intéressant : https://forums.digitalspy.com/discussion/2313701/ee-wi-fi-calling-dropping-the-connection-every-25-minutes
Bizarrement, c'est exactement ce qu'il m'arrive. Et j'ai compris une chose : ce n'est pas l'appel le problème, mais le tunnel qui coupe toutes les 25 min et revient et donc forcément si je passe un coup de fil 5 min avant la coupure... d'où le fait que ça me jette aléatoirement.
L'explication pourrait bien être celle-ci :
I'm pretty up with networking and have a pfSense router and have replicated this on a completely different network also (different router, Wi-Fi point and ISP). DHCP leases are 3 hours on my system, no other connections drop on the phone, and it remains connected to Wi-Fi.
Using pfSense diagnostics and packet capture I can see the connection drop at the 25 minute mark, the phone then re-establishes the connection and new ports are opened back out to EE, and the next 25 minute cycle continues, if I'm on a call at the time it drops out, the call also drops of course, very annoying.
I have just bog standard software on the phone, nothing special and no security software, phones aren't even rooted, and trying on the Nexus 5X then I factory reset just before I tested it which is running the software version I knew had been working fine.
It should be noted this had been working perfectly for many months on my Pixel 2 XL with connections remaining up for 10s of hours if the phone remained on the same Wi-Fi network, although prior to then a similar problem was going on, although it wasn't a set 25 minute drop, just random drops, maybe every 10 or 30 minutes during the day, overnight was okay, I'm guessing capacity issues that had since been fixed.
My thoughts are something has changed at EEs end and now there is some incompatibility. The connection drop appears, from the packet capture, to be around key renewing on the VPN (I'm not 100% sure about this), that seems to fail, causing the connection to drop.
I'm sure it can't just be me seeing this issue, but I suspect the odd dropped call every 25 minutes just gets brushed under the carpet as general flakiness. It seems iPhones are not affected.
Disappointing that EE don't do better testing on changes they apply. As I don't get a mobile signal, well a very weak one that drops out if I dare to move, I'm reliant on Wi-Fi calling, the whole reason I joined EE in the first place, and it's been constant issues with a spell where it was all working brilliantly and I didn't think about it, now back to dropping calls every 25 minutes, 24/7.
Regards
Il y aurait donc un problème au moment du renouvellement des clés, provoquant la coupure.
Pour confirmer, est-ce quelqu'un avec un téléphone rooté, pourrait vérifier si les clés changent au bout de 25 min également ? Je soupçonne bouygues d'avoir un lifetime beaucoup plus long, d'où le fait que ça fonctionne sans problème.
D'ailleurs est-ce qu'il existe une commande pour voir le temps restant ? (genre comme un bail DHCP) J'ai rien trouvé... ip xfrm ne renvoie pas ce genre d'info apparemment.
-
Après 2 heures d'enregistrement continue sur la sortie de ip xfrm state, c'est plus clair :
-Orange : disparaît totalement pendant près de 8 secondes puis revient (c'est bien toutes les 25 min du coup)
-Bouygues : les clés changent d'une seconde à l'autre sans décrochage (au bout d'1h45 !)
Je crois qu'on commence à voir enfin le bout... du tunnel ;D
Reste à savoir ce qui cloche, car au moins niveau clés c'est la même config : AES-CBC et HMAC-SHA-256-128
-
Ca fait un peu échec de rekeying, mais difficile d'en être sûr.
Ce que tu vois dans ip xfrm n'est que le state ipsec du kernel, c'est à dire les clefs de session ESP, les endpoints (adresses IP) et les sélecteurs de traffic (permettant de savoir quel traffic doit être routé dans le tunnel). Le chiffrement du traffic se fait dans le kernel.
Par contre, l'authentification et l'échange de clefs, c'est l'userspace qui s'en charge (raccoon, dans ton cas). Une fois une phase 2 négociée, raccoon dispose de clefs et de configuration ESP qu'il peut passer au kernel.
On voir d'ailleurs dans ton screenshot wireshark que ton téléphone tente un rekeying (packet #28966) et que la gateway IPSec Orange répond (packet #28968), comme tu l'as bien identifié avec ton encadrement. Cette procédure est bien initiée par ton téléphone, probablement suite à l'expiration d'un timer de rekeying.
Ensuite, quelques packets plus tard, le téléphone renégocie une phase 1 en se ré-authentifiant, renégocie une phase 2 pour créer un nouveau tunnel, puis se ré-enregistre en SIP à travers ce tunnel fraichement établi.
Bien évidemment, ca ne devrait pas se passer comme ca : la renégo devrait se faire tout comme chez Bouygues sans nécessiter une interruption du traffic. D'ailleurs, aurais-tu une capture wireshark du même évènement sur le réseau Bouygues?
Plusieurs possibilités me viennent à l'esprit:
- soit la renégo échoue côté Orange et le tunnel existant est détruit,
- soit le remplacement du contexte ESP du kernel par raccoon échoue et il décide de repartir de zéro,
- soit raccoon crash/panique.
Il n'y a pas un moyen d'obtenir des logs en temps réel sous Android avec un câble USB ? Avec les logs de raccoon on aurait une bien meilleure idée de ce qu'il se passe (et tu peux les poster ici sans souci, il n'y aura pas d'identifiant ou de clefs réutilisables dedans).
En tout cas, on sait que la SA lifetime chez Orange est de 30 min, et qu'elle est grosso modo de 2h chez Bouygues (on rekey avant la deadline pour éviter l'interruption du traffic, c'est normal, et l'intervalle entre rekeying et expiration a un caractère aléatoire pour éviter que la gateway IPSec ne se prenne toutes les requêtes de rekeying en même temps).
-
Merci beaucoup pour ces infos. J'ai bien essayé de chopper des logs, mais je n'ai pas l'impression que ce soit actif. J'ai essayé plusieurs trucs comme racoon, ike, ipsec... rien ne ressort. Je n'ai en gros que l'état de l'IMS qui se déco/reco
Je vais faire une capture pour bouygues ;)
J'ai trouvé d'autres éléments qui semble corroborer ce que tu dis (c'est d’ailleurs la même personne que j'ai cité juste avant mais avec un autre téléphone) : https://community.ee.co.uk/t5/Android-Devices/Xiaomi-11T-Pro-Wi-Fi-calling-disconnects-every-50-minutes/td-p/1099572/page/2
I can monitor this on my router in real time and see the connection on port 4500 to EE drop at the point it starts exchanging ISAKMP packets for CREATE_CHILD_SA. : C'est exactement ce qui se passe.
Et le plus intéressant :
So I've been doing some debugging and investigation into this 50 minute drop, this possibly affects a lot of devices using standard Qualcomm supplied modem configuration binaries as I've seen the same settings in many modem.bin files for different manufacturers on Qualcomm phones.
The issue is the settings in the /modem_pr/mcfg/configs/mcfg_sw/generic/EU/EE/Commercial mcfg_sw.mbn file, this has various configuration settings but the ones in question are in the XML for <IWLAN_S2B_CONFIG>. There are two elements in this XML file called <esp_rekey_time> and <ikev2_sa_rekey_timer>, the esp_rekey_timer is set to 3000 seconds for soft and 3600 for hard. Now 3000 seconds is 50 minutes!
At the 50 minute mark the initial keys are exchanged for new ones, this is failing, I think because no group or hash algorithms are in this configuration file (they are in other carrier configuration settings).
A work around I have tested is to simply set these timeout values both to soft:64800/hard:64900 (as seen in other operator config files, e.g. Vodafone), this means the initial keys will last around 45 days, in other words under normal usage the Wi-Fi calling VPN will never get to that age as the connection is dropped and reset on moving around and leaving the Wi-Fi network, but now it will no longer drop every 50 minutes as it never attempts to 'rekey' and so fail. However to implement these changes requires a rooted device and a Qualcomm PST debug port enabled, along with the Qualcomm PST software.
Mon téléphone (qui est aussi un xiaomi) utilise bien un Qualcomm... ça sent le fichier de config foireux.
-
Tu peux joindre le fichier xml en question ici ? Tu as la possibilité de le modifier, éventuellement ?
-
J'aimerais bien, mais même avec un accès root, je ne trouve aucun fichier qui corresponde... En fait je me demande si on peut y accéder directement, les ROMS android sont tellement différentes entre elles que ce qui est valable pour une ne l'est pas pour une autre.
Le seul truc que j'ai trouvé c'est un semblant de conf pour chaque opérateur (carrierconfig), mais la plupart des .xml sont identiques et ne concernent pas les paramètres vowifi.
-
A priori si tu peux activer le developper mode tu n'as pas besoin de root pour collecter les logs : https://support.citrix.com/article/CTX232375/how-to-install-and-collect-adb-logs-on-android-device
-
C'est exactement ce que j'ai fait, mais rien de pertinent.
Et sinon c'est bon j'ai récupéré les .mbn. En fait ça n’apparaît pas dans l'explorateur (comme il me semblait), il faut passer en ligne de commande et là c'est bon. Maintenant faut pouvoir les extraire et les modifier.
Je vais tenter QPST comme mentionné, j'espère que je vais pas faire de gaffe...
-
Suite des investigations.
J'ai extrait les .mbn et j'ai eu quelques surprises : Le xml d'orange ne contient aucun paramètre relatif au rekeying. J'ai comparé avec la ROM constructeur la plus récente : ça contient la même chose. Seuls quelques fichiers diffèrent mais je ne sais pas si ça a une influence dessus. Chez Bouygues au contraire j'ai bien 2 paramètres soft_sec et hard_sec pour ike et esp.
Orange :
<?xml version="1.0" ?>
<IWLAN_S2B_CONFIG>
<GENERIC_VARIANT>
<epdg_addr_info>
<static_fqdn_enabled>FALSE</static_fqdn_enabled>
<plmn_list/>
<dns_retries>
<dns_retry_series_type>EXPONENTIAL</dns_retry_series_type>
<dns_retry_series_exp_factor>2</dns_retry_series_exp_factor>
<dns_max_retries>5</dns_max_retries>
<timeout_error_dns_retry_timer_series>
<seconds random="TRUE">60</seconds>
<seconds>120</seconds>
<seconds>480</seconds>
<seconds>900</seconds>
</timeout_error_dns_retry_timer_series>
<name_error_dns_retry_timer_series>
<seconds>1</seconds>
<seconds>2</seconds>
<seconds>4</seconds>
<seconds>8</seconds>
<seconds>16</seconds>
<seconds>32</seconds>
<seconds>64</seconds>
<seconds>128</seconds>
<seconds>256</seconds>
</name_error_dns_retry_timer_series>
<block_iwlan_for_dns_timeout_error>FALSE</block_iwlan_for_dns_timeout_error>
<block_iwlan_for_default_dns_error>FALSE</block_iwlan_for_default_dns_error>
<block_iwlan_for_dns_name_error>TRUE</block_iwlan_for_dns_name_error>
</dns_retries>
</epdg_addr_info>
<ikev2_info>
<self_id>
<id_type>ID_RFC822_ADDR</id_type>
<mac_enabled>FALSE</mac_enabled>
<identifier/>
</self_id>
<ke_payload_enabled>FALSE</ke_payload_enabled>
<ikev2_dh_group_list>
<dh_group value="14"/>
<dh_group value="5"/>
</ikev2_dh_group_list>
<ikev2_encr_algo_list>
<encr_algo value="12"/>
</ikev2_encr_algo_list>
<ikev2_hash_algo_list>
<algo value="12"/>
</ikev2_hash_algo_list>
<ikev2_prf_algo_list>
<prf_algo value="5"/>
</ikev2_prf_algo_list>
<esp_encr_algo_list>
<encr_algo value="12"/>
</esp_encr_algo_list>
<esp_auth_algo_list>
<algo value="12"/>
</esp_auth_algo_list>
<dpd_info>
<liveness_check_enabled>TRUE</liveness_check_enabled>
</dpd_info>
</ikev2_info>
<err_code_info>
<level_throttling_disabled>FALSE</level_throttling_disabled>
<pdn_throttling>
<throttling_series type="default">
<throttling_values>
<seconds>4</seconds>
<seconds>8</seconds>
<seconds>16</seconds>
<seconds>32</seconds>
<seconds>64</seconds>
<seconds>128</seconds>
<seconds>256</seconds>
<seconds>512</seconds>
<seconds>1024</seconds>
</throttling_values>
</throttling_series>
</pdn_throttling>
</err_code_info>
</GENERIC_VARIANT>
<WP_VARIANT>
<ikev2_info>
<esp_auth_algo_list>
<algo value="1"/>
<algo value="2"/>
</esp_auth_algo_list>
<configured_ike_port>4500</configured_ike_port>
</ikev2_info>
</WP_VARIANT>
</IWLAN_S2B_CONFIG>
Bouygues :
<?xml version="1.0" ?>
<IWLAN_S2B_CONFIG>
<GENERIC_VARIANT>
<epdg_addr_info>
<static_fqdn_enabled>FALSE</static_fqdn_enabled>
<plmn_list/>
</epdg_addr_info>
<ikev2_info>
<self_id>
<id_type>ID_RFC822_ADDR</id_type>
<mac_enabled>FALSE</mac_enabled>
</self_id>
<ke_payload_enabled>FALSE</ke_payload_enabled>
<peer_id>
<id_type>ID_FQDN</id_type>
</peer_id>
<ikev2_dh_group_list>
<dh_group value="14"/>
</ikev2_dh_group_list>
<ikev2_encr_algo_list>
<encr_algo value="12">
<key_size>256</key_size>
</encr_algo>
</ikev2_encr_algo_list>
<ikev2_hash_algo_list>
<algo value="12"/>
</ikev2_hash_algo_list>
<ikev2_prf_algo_list>
<prf_algo value="5"/>
</ikev2_prf_algo_list>
<esp_encr_algo_list>
<encr_algo value="12">
<key_size>256</key_size>
</encr_algo>
</esp_encr_algo_list>
<esp_auth_algo_list>
<algo value="12"/>
</esp_auth_algo_list>
<ikev2_sa_rekey_timer>
<soft_sec>14700</soft_sec>
<hard_sec>14800</hard_sec>
</ikev2_sa_rekey_timer>
<esp_rekey_timer>
<soft_sec>7300</soft_sec>
<hard_sec>7400</hard_sec>
</esp_rekey_timer>
</ikev2_info>
</GENERIC_VARIANT>
<WP_VARIANT>
<ikev2_info>
<esp_auth_algo_list>
<algo value="1"/>
<algo value="2"/>
</esp_auth_algo_list>
<configured_ike_port>4500</configured_ike_port>
</ikev2_info>
</WP_VARIANT>
</IWLAN_S2B_CONFIG>
Il serait intéressant de comparer avec d'autres smartphones qui fonctionnent.
-
Peux-tu modifier ces fichiers .mbn ?
Un échec de renégo CHILD_SA en IKEv2, ca sent le mismatch de DH group ou PRF. J'essayerai bien d'éditer cette partie:
<ikev2_dh_group_list>
<dh_group value="14"/>
<dh_group value="5"/>
</ikev2_dh_group_list>
En enlevant d'abord le <dh_group value="5"/>, puis <dh_group value="14"/> si ca n'aide pas.
Pour vérifier les paramètres spécifiés, pourrais tu poster le résultat d'un ip xfrm state ? (tu peu masquer les clefs si tu veux, elles n'ont pas d'intérêt. C'est pour voir quelles combinaisons d'algorithmes de chiffrement et d'intégrité sont utilisés)
Tu peux aussi essayer d'ajouter des sections rekey timers comme dans le fichier de Bouygues:
<ikev2_sa_rekey_timer>
<soft_sec>14700</soft_sec>
<hard_sec>14800</hard_sec>
</ikev2_sa_rekey_timer>
<esp_rekey_timer>
<soft_sec>7300</soft_sec>
<hard_sec>7400</hard_sec>
</esp_rekey_timer>
en dernier recours pour essayer de retarder le rekeying, qui devrait finir par être initié par la gateway IPSec Orange plutôt que par ton téléphone, si ca marche.
Il est aussi possible que la gateway ne rekey pas, et dans ce cas les CHILD_SA vont simplement expirer...
On tire un peu dans l'obscurité car on a pas les logs.
-
Merci pour ta réponse. A priori oui, je peux modifier les mbn.
Le gros problème, c'est qu'il est impossible d'écrire sur la partition, elle est bloquée en read only. J'ai tenté plusieurs trucs comme un remount, rien ne marche... Je ne suis pas le seul dans ce cas. A priori il y a eu des modifications depuis android 10 empêchant le remount en R/W. En guise de workaround il faut passer par magisk via ses "modules" qui permettent de remplacer un fichier par je ne sais quel mécanisme.
Je suis en train de tester voir si ça fonctionne.
-
Bon, je n'arrive à rien :-\
Je soupçonne que les fichiers sont chargés avant la modification par magisk ou alors il manque un truc (j'ai vu des tutos concernant la 5G sur des google pixel, et il fallait tout un script d’installation, pas juste un bête remplacement de fichier copié au bon endroit, pourtant ça à l'air d'être pris en compte puisque ça apparaît dans l'application).
C'est effrayant de voir que tout ceci est encore en beta depuis des années et qu'on doive nous même bidouiller des fichiers "bas niveau" pour que ça marche. Je prédis un beau bordel le jour où la 3G coupe pour de bon. Heureusement que ça ne touche que la Vowifi et que je peux facilement m'en passer.
Elle est bien bancale cette soit disante compatiblité officielle...
EDIT : Contre toute attente, j'ai réussi à avancer : après moult manip, j'ai enfin réussi à faire reconnaitre le téléphone par QPST et j'ai pu accéder au xml directement et l'éditer. SAUF que ça n'a pas l'air d'être pris en compte.
Le fichier est bien modifié dans le logiciel (même après déco/reco ou reboot du tel), mais si je vais voir le mbn et que j'extrais le contenu : on retrouve le fichier d’origine (de même on voit que la date de modif n'a pas changé). Je ne sais pas si y'a un mécanisme qui conserve le mbn d'origine mais prend bien en compte la modif, toujours est-il que ça ne fonctionne pas mieux en supprimant <dh_group value="5"/>.
EDIT2 : le type de clés :
# ip xfrm state
src 80.12.36.221 dst 192.168.1.76
proto esp spi 0x39d1e4ba reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc hmac(sha256) 0x99c75ecdac418ecf0c1e093xxxxxxxxxdc20b50eebb4c174a48c99bf5698410bf8d3 128
enc cbc(aes) 0x440cde566dfff01b697f7cc40xxxxxxx9d6d7df0ac335650a36f17a799ef9921
encap type espinudp sport 4500 dport 44073 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 192.168.1.76 dst 80.12.36.221
proto esp spi 0x800b932e reqid 0 mode tunnel
replay-window 0 flag nopmtudisc af-unspec
auth-trunc hmac(sha256) 0xe6713023b41ac8195cce54xxxxx9281e5738de2a0317c18bd19c973cd46c96f15 128
enc cbc(aes) 0x85d37c3aac9844fff624a73c4fb5xxxx6d9398f096c6e861e93d20af01de37cd
encap type espinudp sport 44073 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x1683, bitmap 0x00000000
-
Le fichier est bien modifié dans le logiciel (même après déco/reco ou reboot du tel), mais si je vais voir le mbn et que j'extrais le contenu : on retrouve le fichier d’origine (de même on voit que la date de modif n'a pas changé). Je ne sais pas si y'a un mécanisme qui conserve le mbn d'origine mais prend bien en compte la modif, toujours est-il que ça ne fonctionne pas mieux en supprimant <dh_group value="5"/>.
Et si tu enlèves <dh_group value="14"/> ?
À mon avis le fichier n'est en effet pas modifié, et la modif n'est pas prise en compte.
# ip xfrm state
src 80.12.36.221 dst 192.168.1.76
proto esp spi 0x39d1e4ba reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc hmac(sha256) 0x99c75ecdac418ecf0c1e093xxxxxxxxxdc20b50eebb4c174a48c99bf5698410bf8d3 128
enc cbc(aes) 0x440cde566dfff01b697f7cc40xxxxxxx9d6d7df0ac335650a36f17a799ef9921
encap type espinudp sport 4500 dport 44073 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 192.168.1.76 dst 80.12.36.221
proto esp spi 0x800b932e reqid 0 mode tunnel
replay-window 0 flag nopmtudisc af-unspec
auth-trunc hmac(sha256) 0xe6713023b41ac8195cce54xxxxx9281e5738de2a0317c18bd19c973cd46c96f15 128
enc cbc(aes) 0x85d37c3aac9844fff624a73c4fb5xxxx6d9398f096c6e861e93d20af01de37cd
encap type espinudp sport 44073 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x1683, bitmap 0x00000000
Okay, les valeurs encr et hash algo sont bien correctes dans le fichier de config.
Elle est bien bancale cette soit disante compatiblité officielle...
Ces fichiers de conf sont-ils fournis par Orange ? Ou distribués par les serveurs de google et poussés à google par Orange, comme sous iOS ?
Est-ce que tu aurais moyen de les récupérer sur un téléphone Android sur lequel la renégo se passe bien, pour comparer ?
-
Et si tu enlèves <dh_group value="14"/> ?
À mon avis le fichier n'est en effet pas modifié, et la modif n'est pas prise en compte.
Faut que j'essaie, mais je n'y crois pas non plus. Le pire c'est que même si le logiciel constructeur ne modifie pas réellement les fichiers, je ne vois pas quoi faire de plus à part reflasher... mais pour ça il faut pouvoir modifier et reconstruire sans erreur.
Ces fichiers de conf sont-ils fournis par Orange ? Ou distribués par les serveurs de google et poussés à google par Orange, comme sous iOS ?
Est-ce que tu aurais moyen de les récupérer sur un téléphone Android sur lequel la renégo se passe bien, pour comparer ?
Sur android d'après ce que j'ai compris les fichiers sont fournis au fabricant du SoC/tel par chaque opérateur et c'est ensuite en dur dans la ROM. Pas de MAJ poussée en OTA, il faut mettre toute la ROM à jour (ou au moins la partition EFS/modem) pour les changer.
EDIT : Je vois que l'outil PDC, utilisé pour activer les profils permet d'en charger d'autres (le .mbn entier donc), mais j'ai un peu peur de tenter la manip et j'ai pas très envie si jamais ça foire pour de bon de devoir tout reflasher. Bref, je crois que je vais laisser tomber c'est plus prudent.
-
Si tu peux ajouter des profils, fais un backup et si ca se passe mal, ré-ajoute le profil actuel ? Je n'ai pas l'impression que tu risques grand chose, surtout si tu pars d'un état où la VoWifi est plus ou moins inutilisable.
-
Bon ben, on va tenter...
-
Test effectué : le mbn modifié n'est pas pris en compte (je m'en doutais). Aucune erreur n'est remontée mais il n’apparaît pas dans la liste et une fois reboot, le soc active le profil orange poland me faisant perdre la 4G.
Du coup, j'en ai profité pour remettre (je crois) le mbn du dernier firmware, je vais voir si ça coupe toujours.
EDIT : Ça coupe toujours, on ne change pas une équipe qui gagne... là je crois que j'ai fait tout ce que j'ai pu :( A moins de récupérer un autre profil d'un téléphone qui fonctionne (en espérant que ça se soit pas dépendant du modèle de SoC), je vois pas ce que je peux faire d'autre.
-
Changer de téléphone ou d'opérateur.
-
Suite et (à priori) fin de cette histoire : Ces jours-ci je me suis dit que j'allais repasser sous MIUI pour voir si ça résolvait le soucis. Mais avant dans un ultime essai, j'ai tout reflashé, sans plus de résultat.
Et c'est là que j'ai eu une idée que j'aurais du tester depuis le début : copier bêtement le xml de bouygues sur orange vu que les différents algos sont identiques. Je remplace donc le xml d'orange avec l’utilitaire EFS explorer. Je vérifie qu'un reboot conserve la config et que la vowifi est bien active : c'est le cas.
Lancement d'un appel de test et... on dépasse les 25 min... ça continue de tourner ! J'ai coupé au bout de 2h, sans problème 8)
-
Bonjour,
Pour ma part (je ferai d'autres essais), sur une configuration Netgear Orbi (version basique avec 1 routeur et 1 satellite), une connexion fibre Sosh :
- Avec un Galaxy A12
Souvent les appels sont hachés, parfois clairs sans problèmes, et parfois alors que la VoWifi est activée, les appels entrants basculent sur messagerie...
- Avec un Xiaomi Redmi Note 11
Cela semble beaucoup mieux (il a été acquis récemment donc je dois faire d'autres tests), la voix est parfaitement claire lorsque j'ai fait les essais.
L'opérateur est YouPrice (sur réseau Orange).
La seule différence flagrante que je vois entre les deux téléphones c'est l'absence de réseau 5 Ghz sur le Samsung... Tous deux sont notés comme parfaitement compatibles avec la VoWifi sur le site d'Orange.
-
Un smartphone sorti en 2020, qui n'a pas de 5GHz, wow, je savais pas que c'était possible. Le pire c'est que le P35 supporte parfaitement le 5 Ghz, bridage artificiel, bonjour... Honteux.