Recherchez dans la Communauté

Vous avez une question ?

Interrogez la communauté

internet & fixe mes services Orange

FEMTOCELL indispo depuis 1 mois

Thats42
contributeur
641  

FEMTOCELL indispo depuis 1 mois

Bonjour,

 

depuis début mars le femtocell est en erreur (blanc clignotant, orange fixe, éteint, orange fixe,) : Synchronisation réseau non réalisée dans la Femtocell d'Orange.

 

Après vous avoir contacté et avoir eu un rdv avec un soit disant technicien qui lit juste sa procédure en vous insultant et dénigrant (j'attends toujours le mail d'évaluation de cette prise en charge pour dire le reste tellement cette personne était puante et méprisante), après avoir échangé la femto et après avoir eu mon fournisseur d'accès (K-Net) le problème reste identique. De votre côté tout est ok (c'est là où je ne comprends pas pourquoi vous ne la voyez pas en erreur) et du côté du FAI tout est ok : so what ? Tout le monde se renvoie la balle sans avancer sur le sujet.

 

Le femtocell a cependant bien fonctionné pendant 3 mois et il est à noter que j'ai un femtocell Bouygues qui ne rencontre aucun problème.

 

Après analyse d'un dump, voici une piste relayée par un internaute :

"Les requetes ntp ne sont pas logiques, les champs "reference" et "receive" ne devraient pas être en 1970 à partir de la 2ème requête, au moins pour le champs "receive".
Si on regarde la RFC (https://tools.ietf.org/html/rfc5905 , pages 18 et 22):

Reference Timestamp: Time when the system clock was last set or
   corrected, in NTP timestamp format.

Receive Timestamp (rec): Time at the server when the request arrived
   from the client, in NTP timestamp format.

Hypothèse : le démon ntp de la femto plante et est relancé en boucle en n'arrivant jamais a "set" l'heure sur la femto. Comme la femto n'est pas à l'heure et que l'authentification IPSec se fait par certificat, le certificat des serveurs chez Orange ne sont pas bon du point de vue de la femto car elle pense qu'elle est en Janvier 1970 et le certificat du serveur IPSec, lui, est bon (j'imagine). Donc le certificat n'est pas encore valide, et refuse de se connecter.

 

Est-ce qu'un vrai technicien pourrait regarder cette piste éventuellement ? De plus, je ne suis pas seul dans ce cas présent : d'autres internautes (avec d'autres FAI) ont exactement le même souci.

 

Merci de votre diligence pour faire avancer les choses et de faire remonter en interne aux bonnes personnes.

 

P.S : pas la peine de me redonner un rdv avec un soit disant techos chez vous: j'ai donné. Quand vous mettrez un vrai technicien qui connait quelque chose, ok.

5 RÉPONSES 5
johann
#TopMembre
#TopMembre
633  

Re: FEMTOCELL indispo depuis 1 mois

Salut @Thats42 

 

Voir la listes des livebox compatibles avec les autres opérateurs .

https://assistance.orange.fr/medias/woopic/files/content/download/65352/2687033/version/3/file/Compa...

 

Autre possibilité, utiliser ,le mobile en wifi via la livebox .

 

 

 

Linuxien mint depuis 2006 version 21.3 Virginia, y'a moins bien mais c'est plus cher.

Thats42
contributeur
630  

Re: FEMTOCELL indispo depuis 1 mois

La box ne l’est pas je le sais. Toutefois cela n’a pas empêché la femto de fonctionner jusqu’à présent.

Pour le vowifi, cela n’est pas fonctionnel car si vous perdez le réseau mobile (aucun service) l’appel se coupe.

Dans mon cas la femto n’était pas du luxe mais le seul moyen.
johann
#TopMembre
#TopMembre
603  

Re: FEMTOCELL indispo depuis 1 mois

@Thats42 

 

Tu as déjà posté dans leur forum .

https://forum.caps.services/

 

 

 

Linuxien mint depuis 2006 version 21.3 Virginia, y'a moins bien mais c'est plus cher.

Thats42
contributeur
573  

Re: FEMTOCELL indispo depuis 1 mois

Bonjour.

Oui à l’origine, étant donné qu’Orange renvoyait sur le fai j’ai abonder un post existant sur Knet. Mais maintenant on sait que :
1) ce n’est pas lié à la box
2) ce n’est pas lié au FAI

Le point commun demeure donc Orange donc si un vrai technicien passait par là et pouvait regarder le sujet....
Thats42
contributeur
550  

Re: FEMTOCELL indispo depuis 1 mois

Bonjour,

 

je quote un contributeur sur l'autre post :

Truc simple : pouvez-vous vérifier que les équipements qui négocient le tunnel sont bien à l'heure, et savent se maintenir à l'heure ? Trop de différence de temps c'est une raison valable pour l'échec de la négo du tunnel. Déjà vu des trucs foirer avec ~5 minutes  de décallage. Pareil il y à certains NTP qui ne se mettent pas à jour s'il y a plus d'une heure de décallage à ratraper (pour ça qu'on balance souvent un ntpdate avant de lancer le service ntp)

Dans le tcpdump.txt ça me raconte que la clock n'est pas synchro, champ :"Leap Indicator : unknown (clock unsynchronized), en 2036 à la fin des temps avec tous les bits à zero pour les reference et receive timestamp. Et ce temps ne changera pas dans aucun des paquets NTP de cette source, sur toutes les traces. Les Origin et Transmit Timestamp sont à l'heure. Il n'y a aucune réponse des serveurs NTP dans la trace, ou bien la commande tcpdump a filtré seulement la source. Au début d'une négo on peut avoir tout à zero sur le client, sauf le Transmit. Par comparaison Windows 10 envoie un paquet NTP avec Origin et Receive à 2036 fin des temps tous les bits à zero, et le transmit à l'heure de la machine demandeuse.

Reference timestamp : This field is the time the system clock was last set or corrected, in 64-bit time-stamp format. (dans le cas qui nous occupe : jamais)
Originate Timestamp  :This value is the time at which the request departed the client for the server, in 64-bit time-stamp format. (l'heure actuelle de soi même correcte dans la trace)
Receive Timestamp    : This value is the time at which the client request arrived at the server in 64-bit time-stamp format. (idem : jamais)
Transmit Timestamp   : This value is the time at which the server reply departed the server, in 64-bit time-stamp format. (l'heure actuelle d'en face, ou soit meme si c'est le premier paquet)

(https://i.ibb.co/6H1TH7w/timestamp.png)


La version restart est plus sympa. Deja il y a deux serveurs NTP que la clé/femto (?) 192.168.1.164 tente de joindre  80.12.25.237 et .239, sans réponse ou trace manquante.
Après c'est l'inconnu avec une histoire de protocole WireGuard qui a des paquets malformés. Et en plus le premier paquet un TTL de 1 !   Les paquets seront discard au delà de la route par defaut qui va décrementer de 1 le TTL. Les  paquets WinGuard suivant ont un TTL de 2 puis 3... Je suppose (je suis 100% sûr) que la femto a fini en rade avec une échec de la montée du tunnel. Y a des ports 33434/33444 d'impliqués qui sont pas dans la listes des ports à ouvrir.  D'ailleurs il n'y a aucune réponse à ces paquets, ou alors vous n'avez que vos paquets à vous dans le tcpdump avec un filtre sur la source ? Le 192.168.1.164 affirme toujours ne pas être synchro en ntp.

Et oui je confirme le chamgement d'heure le 31/03 quand tu as perdu ta femto.

Le dump OK est en tout point similaire à un dump PAS OK. Y a pas le début de la négo (avec les IKE_SA_INIT and co) . Une fois le tunnel établi  ca peut rester up longtemps… Je suis aussi étonné de n'avoir que des paquets d'une seule source comme si vous parliez à un mur sans réponse. Ou la commande tcpdump vire tout le reste qui n'est pas la source en 192.198.1.164. Même les serveurs NTP ne répondent pas dans cette trace. Vous avez peut être des voyants OK mais le dump dit juste que vous parlez dans le vide.

Sur la 3eme trace tcpdump_2019_04_04_17h57, il a y a bien un dialogue NTP, ta source 192.168.1.164 en 2036 fin des temps tous les bits à 0, les réponses des 2 serveur NTP 80.12.25.237 et .239 à la bonne heure  mais tu continues à être en 2036 fin des temps pour les champs reference/Receive, sans synchronization ntp. L'heure locale de Origin du 192.198.1.164  est dans la même seconde que le serveur NTP en face. Donc pas de décallage d'heure monstrueux. On a un dialogue avec 3 sources différentes, HOURRA ! Trace de loin la plus intéressante, la syntaxce du dump était la même que les autres traces ? On a même des traces de dialogue en ESP du tunnel 80.12.25.230. Les requetes NTP n'ont pas toutes des réponses, on a des plages de silence de plusieurs secondes, parfois seulement l'un des deux réponds. C'est de l'UDP ca pue la perte de paquet à plein nez. C'est facile dans la réponse NTP le wireshark vous affiche le paquet de la requete et dans la requete du client ca affiche le numero du paquet de réponse. Quand y a pas le lien, y a pas de réponse et ca sent mauvais.

Donc sur le protocole NTP on a un client femto qui begaye, à l'heure apparement, qui se synchro pas ou du moins mentionne ca dans les paquets qu'il émet. Que les serveur NTP répondent un peu quand il veulent vu de la trace, ou bien de la perte de paquet dans un sens ou dans l'autre. Sur les protocoles tunnel c'est non concluant on  parle à un mur. Et la seule trace tcpdump_2019_04_04_17h57, où on voit les paquet ESP en retour, le tunnel serait down, malgré les paquets du NAT-Keepalive qui confirme un tunnel en marche. Pareil pour l'ISAKMP y a des aller/retour et ca sent les renégociation periodique du PFS Avez vous tentez de passer un appel pour être sûr et pas se fier au voyant ?



Je suis étonné que sur les 4 traces, 3 n'ont aucune réponse aux paquets. La source est toujours 192.198.1.164, même le restart qui dure plus de 5 minutes. Quel est la syntaxe de ton tcpdump ? Evidement Orange filtre le ping sur les 80.12.25.237/239/230 du coup on peut pas tester si c'est up, traceroute idem, je ne suis même pas en  mesure d'affimer que leur service est UP vu de l'extérieur de leur réseau. En utilisant un traceroute en UDP sur le port 450 qu'on espere ouvert pour le tunnel c'est tout autant inerte, y compris avec le proto ESP. Looking glasss depuis le reseau Orange ou Opentransit le ping est NOK donc down ou filtré sur l'IP qu'on voit en trafic ESP 80.12.25.230. 

Donc 2 choses :
- gros pb software sur le service NTP/temps de la femto. Ca doit remonter à leurs devs/intégrateurs/sous-traitant. Deja rien que le begayage  sans ralentissement etc. on est en dehors des clous protocolaires sur de nombreux points.
- un gros soupçon sur la qualité Internet et/ou du service, entre la source et les serveurs Orange on a la trace de perte de paquet NTP sur UDP, sans pouvoir conclure ou incriminer l'un, l'autre ou les deux, ou des tiers transitaires. Et sous réserve de confirmation des syntaxes des tcpdump ou filtrage excluant, on a un service Orange invisble totalement plusieurs minutes, ou pendant de looongues périodes de plusieurs secondes quand les choses fonctionnent dans les deux sens, avec la femto qui ne serait pas fonctionnelle malgré des indices de fonctionnement d'un tunnel. Je n'ai pas vu de perte dans les séquences ESP pour les deux SPI visibles de la trace bi-directionnelle.  En plus les filtrages à la noix ultra-violent d'Orange n'aident pas au diagnostic, ICMP c'est un protocole utile, le filtrer totalement sans discernement ca fait foirer beaucoup de choses. Accessoirement la taille des paquets vus dans les traces est trop petite pour percuter un pb de MTU.

Ce que j'aimerai : un tcpdump total de la femto, sans filtrage, de 24H ou plus, avec un restart après le lancement du dump. Eventuellement remise à config d'usine et parametrage login/mdp pour la montée du tunnel si besoin. Et tenter de passer des appels. Si rien ne marche tenter un looking glass depuis Orange vers chez vous (l'inverse est filtré selon toute vraissemblance) pour voir si Orange vous voit… Noter les heures (depart, looking glass ok ou pas etc)

Vous avez une question ?

Interrogez la communauté

Déjà 753055 membres inscrits 🧡

2742 personnes actuellement en ligne

Tous les membres en ligne