Femtocell Orange HS depuis 1.16

[Fyr]

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)

Bisou.

PS je ne suis lié en rien avec Orange ou K-Net. Vous avez toute liberté pour copier ce que je raconte pour le filer à Orange ou K-Net. J'ai juste passé un peu plus de 3H sur le truc...

[boz]

Salut,

Je viens d'être relié à la fibre jeudi chez K-net et j'ai le même problème avec mon femto Orange (je précise que c'est celui au boitier noir, logo noir car il y a 3 modèles).

Je n'utilise pas la box knet mais un routeur perso Dual WAN Linksys LRT224 que j'avais déjà depuis un moment avant pour mes 2 box ADSL (une Free et l'autre Orange).
Mon femto fonctionnait parfaitement sur ce routeur perso et même avant ça directement sur l'une ou l'autre des 2 box avant d'avoir ce routeur dual WAN.
J'ai toujours paramétré mon routeur en mode Failover (c'est à dire que tout passait par 1 seul port WAN sauf quand celui ci venait à tomber et alors tout passait sur l'autre port WAN automatiquement), je n'ai jamais fonctionné en load balancing et encore moins aujourd'hui que j'ai un lien en fibre et l'autre en ADSL.
Aujourd'hui j'ai dont branché mon lien k-net sur le port WAN ouvert par défaut mais impossible de faire marcher le Femto
Si je change de port WAN actif (pour celui où est relié ma box Free) alors le femto re-fonctionne.
mon routeur est à l'heure grace à un serveur NTP donc ça ne vient pas de là non plus.

Pour moi le problème ne peut donc pas venir d'un routeur perso et pas non plus du femto car il fonctionne derrière ce routeur sur d'autres FAI.

Le problème vient forcément de chez K-net et si je comprend bien tout ce que j'ai lu plus haut, ça fonctionnait encore il n'y a pas si longtemps.

Comment faire remonter cette info à k-net ?

EDIT: je viens d'avoir le service technique de K-net, ils ont eu comme info que c'était orange qui bloquait l'utilisation du femto orange chez eux et normalement aussi chez les autres opérateurs que orange  et ils étaient étonné que ça fonctionne encore pour moi chez Free.
Il semblerait que des développeur soient encore en train de chez chercher chez knet comment contourner le problème mais il y aura forcément un problème juridique à un moment donc pas sûr qu'ils aillent plus loin...

@+

[halesk2k]

Salut,

Je viens d'être relié à la fibre jeudi chez K-net et j'ai le même problème avec mon femto Orange (je précise que c'est celui au boitier noir, logo noir car il y a 3 modèles).

Je n'utilise pas la box knet mais un routeur perso Dual WAN Linksys LRT224 que j'avais déjà depuis un moment avant pour mes 2 box ADSL (une Free et l'autre Orange).
Mon femto fonctionnait parfaitement sur ce routeur perso et même avant ça directement sur l'une ou l'autre des 2 box avant d'avoir ce routeur dual WAN.
J'ai toujours paramétré mon routeur en mode Failover (c'est à dire que tout passait par 1 seul port WAN sauf quand celui ci venait à tomber et alors tout passait sur l'autre port WAN automatiquement), je n'ai jamais fonctionné en load balancing et encore moins aujourd'hui que j'ai un lien en fibre et l'autre en ADSL.
Aujourd'hui j'ai dont branché mon lien k-net sur le port WAN ouvert par défaut mais impossible de faire marcher le Femto
Si je change de port WAN actif (pour celui où est relié ma box Free) alors le femto re-fonctionne.
mon routeur est à l'heure grace à un serveur NTP donc ça ne vient pas de là non plus.

Pour moi le problème ne peut donc pas venir d'un routeur perso et pas non plus du femto car il fonctionne derrière ce routeur sur d'autres FAI.

Le problème vient forcément de chez K-net et si je comprend bien tout ce que j'ai lu plus haut, ça fonctionnait encore il n'y a pas si longtemps.

Comment faire remonter cette info à k-net ?

EDIT: je viens d'avoir le service technique de K-net, ils ont eu comme info que c'était orange qui bloquait l'utilisation du femto orange chez eux et normalement aussi chez les autres opérateurs que orange  et ils étaient étonné que ça fonctionne encore pour moi chez Free.
Il semblerait que des développeur soient encore en train de chez chercher chez knet comment contourner le problème mais il y aura forcément un problème juridique à un moment donc pas sûr qu'ils aillent plus loin...

@+

Je crois qu'un des problèmes avec les femto, c'est de bien les géolocaliser pour que les numéros d'urgence soient bien routé.

Du coup on comprend pourquoi orange bloque chez les autres fai sachant qu'ils ne peuvent pas garantir l'adresse physique.

[Fyr]

Leur web indique que la femto est paramétrée par defaut  à l'adresse de facuration du mobile Je cite << Lors de votre commande, vous devrez valider l'adresse de livraison de votre Femtocell. L'adresse pré-remplie est l'adresse de facturation de votre offre mobile Orange. Pour modifier l'adresse de livraison (facturation), rendez-vous sur votre Espace client.>>

avec un warning :

<<Attention :  si vous déplacez votre Femtocell à une autre adresse que celle initialement déclarée, les appels émis vers les services d'urgence (15, 17, 18...) pourraient ne plus être correctement acheminés vers le centre d'urgences le plus proche>>

https://assistance.orange.fr/mobile-tablette/tous-les-mobiles-et-tablettes/installer-et-utiliser/optimiser-votre-couverture-avec-la-femtocell/femtocell-presentation-et-souscription_63801-64653#onglet4


Donc en résumé, c'est un "routage statique" des appels  d'urgence, c'est pas ça la cause racine du problème. DE PLUS les GCU de ta FEMTO liste l'ensemble des box "compatibles" :

https://assistance.orange.fr/medias/woopic/files/content/download/65352/2687033/version/3/file/Compatibilites_Femtocell_Box_Modems_Mai2018.pdf : Bouygues, SFR, Free et Orange sont compatibles.  Dans la même liste il y a des équipements en plus avec des notes concernants NAT, DHCP, désactivation de scanning et DOS etc pour ceux qui sont en mode bridge avec leur routeur chez les opérateurs "compatibles".  Il y a aussi en plus une forte suspicion de filtrages de IP des opérateurs non compatibles.

=> la seule façon est de demander à Orange/K-NET de mettre K-NET/les K-BOX dans la liste des "compatibles". Là ca ne marche pas, et d'après les doc c'est "normal" ce n'est pas prévu que ça marche, vous n'êtes pas listé compatible.

PS là globalement je vous en veux de m'avoir fait perdre plusieurs heures à analyser des traces alors que les GCU de base indiquent que ca ne marchera pas. J'espère aussi que les développeurs K-NET sont au courant avant de se faire envoyer balader aux fraises sur un pb technique de leur côté. Là s'il n'y a pas de filtrage des IP sources coté Orange, c'est un pb de compatibilité, et les dev K-NET doivent entre en contact avec ceux d'Orange pour voir où ça coince et rendre le service à leurs clients communs, mais pas essayer de déboguer un non-problème tout seul.

Vous n'êtes pas dans les conditions prevues par Orange pour que ça marche.

[thedark]

C'était nécessaire le message en rouge  et en grande police ? 

[Fyr]

OUI . J'ai perdu BEAUCOUP de temps sur le sujet alors qu'à la base c'etait  écrit noir sur blanc que ca ne marcherait pas dans les GCU de leurs équipements. Et en plus à la 5eme page du thread....

[halesk2k]

OUI . J'ai perdu BEAUCOUP de temps sur le sujet alors qu'à la base c'etait un écrit noir sur blanc que ca ne marcherait pas dans les GCU de leurs équipements. Et en plus à la 5eme page du thread....

CGU que t'as signé, toi, client Orange.

[Fyr]

Moi non j'ai pas de femto. Je me suis juste gentiment tapé l'analyse des traces des membres du forum.

[thedark]

Dans ce cas, pourquoi depuis des années ça fonctionnait très bien. Et là boom 
Tout le monde est touché avec la box k-net ou sans la box k-net.

[Fyr]

Dans ce cas, pourquoi depuis des années ça fonctionnait très bien. Et là boom 
Tout le monde est touché avec la box k-net ou sans la box k-net.

Astuce : lire les trucs au dessus de ce qui est en rouge, gras, souligné, 18pt.

Qu'un truc qui est tombé en marche pendant des années, tombe en rade comme prévu, on est dans le normal.  Après que cette "normalisation" soit dans la période de temps d'une MAJ firmware K-Net, ca n'empêche pas Orange de bricoler de leur coté. Du coup ce n'est plus de mon ressort d'essayer d'apporter mon aide, sur forum, à des collègues clients de K-net. C'est hors de ma portée.

[thedark]

Dans ce cas, pourquoi depuis des années ça fonctionnait très bien. Et là boom 
Tout le monde est touché avec la box k-net ou sans la box k-net.

Astuce : lire les trucs au dessus de ce qui est en rouge, gras, souligné, 18pt.

Qu'un truc qui est tombé en marche pendant des années, tombe en rade comme prévu, on est dans le normal.  Après que cette "normalisation" soit dans la période de temps d'une MAJ firmware K-Net, ca n'empêche pas Orange de bricoler de leur coté. Du coup ce n'est plus de mon ressort d'essayer d'apporter mon aide, sur forum, à des collègues clients de K-net. C'est hors de ma portée.

Mon message n'était pas  contre toi (Si tu l'as mal pris)
En même temps l'application OCS n'est plus disponible pour la PureKTV
Je vois partout des complots 

Bloquer K-NET suite à l'annonce d'orange sur les RIP 

[halesk2k]

Moi non j'ai pas de femto. Je me suis juste gentiment tapé l'analyse des traces des membres du forum.

Dsl j'ai cru que c'était toi a l'origine sur sujet. Après pour l'analyse des tcpdump je l'ai fait aussi a mon bon vouloir, personne ne m'a obligé.

Je trouve ça plutôt intéressant. Partir d'un dump reseau er devoir trouver les causes applicative, je trouve que ça fait un peu mode enquête en tout cas moi je me suis amusé .

[Fyr]

Mon message n'était pas  contre toi (Si tu l'as mal pris)
En même temps l'application OCS n'est plus disponible pour la PureKTV
Je vois partout des complots 

Bloquer K-NET suite à l'annonce d'orange sur les RIP 

Non non juste que je répondais à la partie "plantage soudain" et que dans mon post avec du rouge je parlais d'incompatibilité possible.

Oh mec tu m'as tué avec les 3pt ˆˆ

[steph_54]

Bonjour,
quelle est la situation sur ce sujet ? N'Y-a-t-il aucun moyen de faire fonctionner sa femtocell Orange sur une box K-Net?
Evidemment j'ai souscrit chez K-Net sans imaginer qu'il puisse y avoir un problème, et comme vous, je n'arrive pas à synchroniser ma femtocell. Elle s'initialise bien pendant 10 min, mais après clignotement blanc (pb de connexion au réseau Orange)

Merci pour vos retours,

[gillejeu]

Bonjour,
quelle est la situation sur ce sujet ? N'Y-a-t-il aucun moyen de faire fonctionner sa femtocell Orange sur une box K-Net?
Evidemment j'ai souscrit chez K-Net sans imaginer qu'il puisse y avoir un problème, et comme vous, je n'arrive pas à synchroniser ma femtocell. Elle s'initialise bien pendant 10 min, mais après clignotement blanc (pb de connexion au réseau Orange)

Merci pour vos retours,

Et y'a pas de Vowifi chez Orange? Comme ça pas de besoin de femto.