Auteur Sujet: Qualité VoWiFi  (Lu 11825 fois)

0 Membres et 1 Invité sur ce sujet

Mogette

  • Abonné Orange Fibre
  • *
  • Messages: 1 694
Qualité VoWiFi
« Réponse #36 le: 27 août 2022 à 10:20:47 »
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.

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Qualité VoWiFi
« Réponse #37 le: 29 août 2022 à 10:29:58 »
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.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Qualité VoWiFi
« Réponse #38 le: 01 octobre 2022 à 16:38:07 »
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.

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Qualité VoWiFi
« Réponse #39 le: 01 octobre 2022 à 20:38:04 »
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.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Qualité VoWiFi
« Réponse #40 le: 02 octobre 2022 à 18:41:53 »
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à  :(
« Modifié: 03 octobre 2022 à 01:42:16 par renaud07 »

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Qualité VoWiFi
« Réponse #41 le: 02 octobre 2022 à 22:31:34 »

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.

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Qualité VoWiFi
« Réponse #42 le: 03 octobre 2022 à 10:29:24 »
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).


renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Qualité VoWiFi
« Réponse #43 le: 03 octobre 2022 à 15:48:17 »
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>;
« Modifié: 03 octobre 2022 à 17:04:45 par renaud07 »

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Qualité VoWiFi
« Réponse #44 le: 03 octobre 2022 à 17:29:56 »
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  :-\

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Qualité VoWiFi
« Réponse #45 le: 19 octobre 2022 à 21:18:30 »
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.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Qualité VoWiFi
« Réponse #46 le: 20 octobre 2022 à 00:08:30 »
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
« Modifié: 20 octobre 2022 à 02:04:16 par renaud07 »

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Qualité VoWiFi
« Réponse #47 le: 20 octobre 2022 à 15:17:36 »
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).