Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • Status Nouveau
  • Percent Complete
    0%
  • Task Type Anomalie
  • Category Maison connectée → Système d'alarme
  • Assigned To No-one
  • Operating System Freebox V9 (Ultra)
  • Severity High
  • Priority Very Low
  • Reported Version 4.8.17.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 2
  • Private
Attached to Project: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Opened by Hypolepic - 08/01/2025
Last edited by Hypolepic - 08/01/2025

FS#39966 - Périphérique Alarme Diagral DIAG56AAX en RJ45 qui se déconnecte toutes les X secondes

Bonjour,

J’ai eu la Fibre il y a 2 mois avec la Freebox Ultra et depuis ce jour, j’ai un problème de déconnexion de mon alarme Diagral e-one et plus précisément le module DIAG56AAX qui est en RJ45 directement derrière la Freebox (Port 2).

Le voyant du module passe au rouge, au vert, etc etc ce qui indique qu’il arrive à se connecter au server Diagral (quand il est vert) puis est non reconnu par la box donc perd la connexion (quand il est rouge). Je vois le périphérique réseau sur mafreebox.fr apparaître et disparaître continuellement. Comme si la Freebox rejetait ce périphérique. J’ai testé le module chez un voisin et il reste au vert (sur une box Sosh), le problème vient bien de la Freebox.
Dans Réseau local / Switch, je vois le port 2 toujours actif en 100BaseTX-FD mais l’adresse MAC et le nom du périphérique apparaît et disparait tout seul etc.

J’ai 15 autres appareils branchés en RJ45 et pas de soucis sur ceux-là. J’ai testé plusieurs câbles, plusieurs ports, sur un switch, réinitialiser le module DIAG56AAX, rien n’y fait, toujours le même comportement.

J’ai appelé le service client Free, ils ont fait un ticket en m’indiquant qu’ils vont faire un changement sous 72h sur les ports rj45 à distance sur ma box mais je n’ai pas + de détails techniques. Vous sauriez ce que ça pourrait être ?

Pas de bail DHCP fixe (j’ai essayé ça ne change rien), pas de redirection de port, IP V4 Full Stack.

Merci beaucoup pour votre aide.

Ps : ajout, je vois que c’est un problème connu et qui impacte d’autres périphériques depuis au moins l’année dernière ! commentaire de geoff37 : https://dev.freebox.fr/bugs/task/39351 !

Cdt

Bonjour

Vérifiez bien que lors du passage à la fibre vous êtes toujours en IPv4 full stack.
(j'ai déjà vu des centrales d'alarmes qui avaient besoin d'ouvrir en UPNP IGD les ports 49715 → 49735)

Cordialement
nbanba

Bonjour,
J'ai déjà une IPV4 full stack ;) J'ai fait la demande à Free suite au premier appel. C'est ok désormais.
Sur l'autre topic que je mentionne https://dev.freebox.fr/bugs/task/39351 , il y a également le soucis à priori avec une box tahoma somfy. Je pense sincèrement qu'il y a qq chose qui cloche sur la box Ultra avec ce genre de périphérique !

Concernant les ports, vous sauriez m'indiquer comment les ouvrir (je suis pas très doué en réseau…) Merci beaucoup

Cdt

Activer le service Upnp IGD sur la freebox est activé. Il manquerait l'ouverture des ports ?

@geoff37 a le même problème que moi depuis l'année dernière, @nbanda, il y a quelque chose sur la box Ultra qui fait qu'elle n'accepte pas ce périphérique. Pourtant c'est une marque commune vendu à Leroy Merlin entre autre.
A priori, la somfy tahoma a le même soucis en RJ45.

Bonjour

Les ports à ouvrir dépendent du modèle de l'alarme.
Le mieux est d'ouvrir un ticket au support diagral https://www.diagral.fr/assistance/
(formulaire > autre cas)

Puis demandez texto (j'avais obtenu la liste comme ça) :

"Pour faire fonctionner le boitier DIAG56AAX sur mon réseau d'entreprise, l'équipe réseau me demande:
- la liste IP des serveurs de destinations de diagral
- la liste des IP des serveurs pouvant se connecter sur mon alarme
- la liste des ports TCP + UDP à ouvrir en sortie
- la liste des ports TCP + UDP à ouvrir en entrée (DNAT vers le boitier DIAG56AAX)

Pourriez vous me transmettre ces 4 listes ?
"

Le support devrait vous donner les info techniques propres à votre modèle de boitier, après on vous dira quoi faire sur la box

PS: Le boitier se connecte en 10/100Mb/s et je ne suis pas certain que ce soit "toujours" bien supporté par le switch mGIG de la freebox ULTRA
⇒ essayez de mettre 1 switch 1gb (qui fait du 10mb/100mb) entre la freebox ULTRA et le boitier DIAG56AAX

Cordialement
nbanba

Bonjour,
J'ai tenté le switch effectivement GS105E de chez Netgear (elle est tjrs dessus d'ailleurs) mais ça ne change rien.

J'ai trouvé ça sur la documentation Diagral : https://www.diagral.fr/assistance/questions-frequentes/alarmes/alarmes-e-one-connectees/#product-list :

Pour l’utilisation de l’application e-One (permettre l’accès des installations au serveur ) : il faut autoriser les appels sortants vers :

– Le nom de domaine « wsv3.tt-monitor.com », sur Port 6000, c’est mieux de le gérer en nom de domaine mais si ce n’est pas possible l’adresse à ce jour est : 20.160.127.151 sur Port 6000 à utiliser pour les connexions permanentes au serveur e-One.

– Et aussi :
o Adresse IP : 217.109.94.132 sur Port 6000 à utiliser pour les connexions permanentes avec nos serveurs
o Adresse IP : 40.91.228.28 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 40.91.228.105 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 40.91.229.254 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 40.91.228.27 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 51.137.85.68 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs

– Et si utilisation de la vidéo, le port 6001 doit être autorisé également.

Pour les appels d’alarme vers la télésurveillance : le port 3000 est utilisé pour les appels sortants. L’appel sortant lors d’une alarme se fait directement vers l’adresse IP du télésurveilleur qui est configurée sur la box e-One et ne passe pas par le serveur e-One ni par une quelconque autre infrastructure.

Est-ce suffisant ?

ça serait un pb de blocage d'appel ? Car effectivement j'ai vraiment l'impression que c'est la Ultra qui a du mal avec le boitier vu que dans Périphériques Réseaux, je la vois active / ensuite grisée inactive, active etc etc.

Bonjour

0 priori si vous n'avez pas de firewall (un équipement physique supplémentaire entre la box et le boitier d'alarme), tout ce qui est "sortant" est autorisé par votre box .
Je ne vois rien sur les 'flux entrants' dans leur doc, et ce sont les flux entrants qu'il faut paramétrer si votre boitier en utilise (et ça à moins de tracer les flux sur votre réseau, la seule manière d'avoir la réponse c'est de demander au support)

Cependant, déjà depuis une machine du réseau, vous pouvez essayer de voir si vous accédez bien aux endpoints fournis dans la doc (moi oui):

$ nc -vz 217.109.94.132 6000
Connection to 217.109.94.132 6000 port [tcp/x11] succeeded!
$ nc -vz 40.91.228.27 6001
Connection to 40.91.228.27 6001 port [tcp/x11-1] succeeded!
$ nc -vz 40.91.228.28 6001
Connection to 40.91.228.28 6001 port [tcp/x11-1] succeeded!
$ nc -vz 40.91.229.254 6001
Connection to 40.91.229.254 6001 port [tcp/x11-1] succeeded!
$ nc -vz 40.91.228.105 6000
Connection to 40.91.228.105 6000 port [tcp/x11] succeeded!
$ nc -vz 40.91.228.105 6001
Connection to 40.91.228.105 6001 port [tcp/x11-1] succeeded!
$ nc -vz 51.137.85.68 6001
Connection to 51.137.85.68 6001 port [tcp/x11-1] succeeded!
$ nc -vz 51.137.85.68 6000
Connection to 51.137.85.68 6000 port [tcp/x11] succeeded!
$ nc -vz wsv3.tt-monitor.com 6000
Connection to wsv3.tt-monitor.com (20.160.127.151) 6000 port [tcp/x11] succeeded!

Autre point, quand vous connectez votre boitier et qu'il passe du vert au rouge, est ce que des "leases" UPNP sont visivles dans FreeboxOS (dans paramètres avancés > UPNP) ?
Si oui, quels ports sont ouverts ? (passer ces ports en statiques peut aider)

Cordialement
nbanba

Admin
Dans Réseau local / Switch, je vois le port 2 toujours actif en 100BaseTX-FD mais l’adresse MAC et le nom du périphérique apparaît et disparait tout seul etc.

C'est cohérent avec les logs de votre box: le port ethernet faisait des transitions up → down → up en boucle. Cela s'est arrêté, sans doute parce qu'il y a un switch au milieu.

Vu que le comportement persiste, cela suggère que le lien switch ←→ alarme tombe aussi régulièrement.
Cela devrait être visible sur les LEDs du switch (ou dans ses logs, puisqu'il semble s'agir d'un switch managé)

⇒ essayez de mettre 1 switch 1gb (qui fait du 10mb/100mb) entre la freebox ULTRA et le boitier DIAG56AAX

un autre test possible: connecter l'alarme directement à la freebox, et configurer le port en question en 100Mb/s FullDuplex dans FreeboxOS (au lieu de "auto")

Tout à fait, les leds du switch/box Diagral s'éteignent 1 sec et redémarrent à chaque fois.

J'ai fait des telnet et j'accède bien aux endpoints.

Je ne vois rien dans UPNP, Pas de redirections actives.

J'ai demandé les éléments au support Diagral comme vous m'avez demandé.

J'avais déjà essayé de forcer en 100Mb mais je vais retenter.

Je trouve quand même bizarre de devoir galérer autant sur un élément vendu au grand public :s Vous êtes sûr qu'il ne peut rien y avoir en bug du côté Freebox Ultra ? Surtout que je ne suis pas le seul dans ce cas cf l'autre ticket que j'ai indiqué :(

la box Diagral fonctionne sur la Freebox Delta et une box Sosh (elle ne se coupe pas). Du coup je m'interroge réellement sur la Ultra sur une limitation technique/logicielle non ?

Admin
Tout à fait, les leds du switch/box Diagral s'éteignent 1 sec et redémarrent à chaque fois.

il est bien question de led sur le switch indiquant l'état du lien switch ←→ alarme ?

oui les deux petites leds du port RJ45. Elles s'éteignent complètement lors de la coupure et se rallument pour clignoter par la suite.
Là je viens de tester en direct sur le port 4 de la freebox en 100mb full duplex, ça fait la même chose.

le port Ethernet passe en Inactif et repasse en actif etc etc dans la vue Réseau local / Switch de la Freebox

J'ai eu Diagral au téléphone, ils me confirment que c'est bien cette liste là à ouvrir :

– Le nom de domaine « wsv3.tt-monitor.com », sur Port 6000, c’est mieux de le gérer en nom de domaine mais si ce n’est pas possible l’adresse à ce jour est : 20.160.127.151 sur Port 6000 à utiliser pour les connexions permanentes au serveur e-One.

– Et aussi :
o Adresse IP : 217.109.94.132 sur Port 6000 à utiliser pour les connexions permanentes avec nos serveurs
o Adresse IP : 40.91.228.28 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 40.91.228.105 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 40.91.229.254 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 40.91.228.27 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs
o Adresse IP : 51.137.85.68 sur Ports de 20000 à 35000 à utiliser aléatoirement pour les échanges des données avec nos serveurs

– Et si utilisation de la vidéo, le port 6001 doit être autorisé également.

Si jamais je suis preneur d'un petit tuto juste pour une première ligne et je ferai le reste pour voir. Car je ne vois pas comment "ouvrir un port".

Merci beaucoup.

Admin
Là je viens de tester en direct sur le port 4 de la freebox en 100mb full duplex, ça fait la même chose.

le timing semble assez régulier: environ toutes les 60-70s.

oui les deux petites leds du port RJ45. Elles s'éteignent complètement lors de la coupure et se rallument pour clignoter par la suite.

le comportement ici est indépendant de la box (que ce soit une ultra, une delta ou une livebox)

le lien monte, le dhcp se passe bien (puisque vous voyez l'alarme dans Freebox OS > Périphériques réseaux), mais le lien tombe quelques dizaines de secondes après. à croire que quelque chose ne lui plait pas et la connexion est réinitialisée.

Si jamais je suis preneur d'un petit tuto juste pour une première ligne et je ferai le reste pour voir. Car je ne vois pas comment "ouvrir un port".

Les ouvertures de port sur la freebox sont nécessaires pour permettre une connexion depuis l'extérieur vers un équipement qui est dans votre réseau local.

Les instructions de Diagral concerne le sens alarme → internet. La freebox autorise toutes les connexions sortantes, donc pas de configuration particulière à faire.

ok du coup vous n'avez plus de piste ? n'hésitez pas si vous préférez un appel si je peux tester différents trucs en direct.

Bonjour

Ne travaillant pas pour Free je n'ai pas accès à votre box pour faire des captures et avoir des logs.

Si vous disposez d'un équipement actif type switchs mangeable ou un firewall physique à positionner entre le boîtier d'alarme et la freebox, je pourrais vous dire comment capturer le trafic du boîtier d'alarme afin de comprendre ce qu'il fait et ce qui se passe juste avant la déconnexion et pendant tout un cycle connexion → déconnexion → connexion.

Cordialement
nbanba

oui j'en ai un 8 ports TPLINK TL-SG608E, je vais la déplacer dessus demain pour voir ;) Vous pouvez m'indiquer ce qu'il faut que je regarde dessus. Merci beaucoup pour votre aide en tout cas ;)
Cdt

Je ne suis pas certain que je puisse checker ce que vous souhaitez regarder par contre via ce modèle : https://www.manualpdf.in/tp-link/tl-sg608e/manual?p=41, ce n'est pas un gros switch professionnel.

Admin

vous pouvez essayer de connecter un PC et l'alarme sur le même switch, lui même connecté à la box.

Sur le PC, installez wireshark (à télécharger sur wireshark.org). Quand vous le lancer, saisissez le filtre suivant:

  ether host ff:ff:ff:ff:ff:ff or ether host <la MAC du module>

Attention à bien saisir le filtre dans le "capture filter" plutôt que "display filter".

Double cliquer sur l'interface ethernet pour démarrer la capture. Laissez tourner quelques minutes (vous devrier voir à minima des paquets DHCP décodés par wireshark). Arrêtez la capture, enregistrez au format pcap ou pcapng.

Une capture réseau peut contenir des éléments personnels. Si vous ne voulez pas partager la capture en public, vous pouvez l'uploader sur dl.free.fr et m'envoyer le lien de partage par mail

Bonjour

Sur le TPlink vous pouvez mettre le port de l'alarme en miroir avec un autre port sur lequel vous branchez un laptop / un pc avec wireshark pour capturer les paquets (comme décrit par @mmakassikis)

https://www.tp-link.com/us/support/faq/3235/

Aussi regardez l'état des ports dans l'interface web du switch (regarder si il y a des messages d'erreurs, regardez les logs, etc…)

PS: moi aussi je vous recommande de ne pas poster un pcap ou un core dump sur un forum publique

Cordialement
nbanba

Mail envoyé, je n'ai pas fait le mirroring, tout était branché sur le switch. si besoin je peux refaire ;)

Admin

il y a un truc étonnant dans la capture: je ne vois pas de réponses ARP.

ARP est le protocole qui permet d'associer une MAC à une adresse IP.

Par exemple: l'alarme a appris par DHCP que la passerelle par défaut est la box qui a l'adresse 192.168.1.254. Elle ne connaît pas sa MAC, donc elle envoie une requête ARP "qui a l'adresse 192.168.1.254 ?". S'il n'y a pas de réponse, elle ne sait pas comment communiquer avec la box.

Cela est aussi vrai dans l'autre sens: la box envoie des requêtes ARP auxquelles l'alarme de répond jamais.

Est-ce que vous pinger l'alarme depuis votre PC (ping -t 192.168.1.2) ?

Si oui, l'ARP fonctionne, auquel cas il faudrait refaire la capture en utilisant le mirroring.

oui je ping l'alarme quand elle est verte, non quand elle est rouge.

Envoi d’une requête 'Ping' 192.168.1.2 avec 32 octets de données :
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.2 : octets=32 temps=1000 ms TTL=255
Réponse de 192.168.1.2 : octets=32 temps=7 ms TTL=255
Réponse de 192.168.1.2 : octets=32 temps<1ms TTL=255
Réponse de 192.168.1.2 : octets=32 temps<1ms TTL=255
Réponse de 192.168.1.2 : octets=32 temps<1ms TTL=255

J'ai refait le capture avec le mirroring, je vous l'ai envoyé, j'ai vu + de choses en source 192.168.1.2

Admin

dans la nouvelle capture la box répond aux requêtes ARP de l'alarme. Ce n'est pas le cas pour les requêtes ARP de la box, mais cela n'empêche pas l'alarme d'interroger le DNS pour trouver le serveur wsv3.tt-monitor.com et initier une connexion TCP … et après plus rien.

est-ce que vous avez testé dans un setup minimal? C'est à dire: désactiver le wifi depuis l'afficheur, et ne laisser brancher que l'alarme sur la box (sans switch intermédiare). Est-ce que le voyant reste vert ?

Bon… j'ai trouvé le coupable, le répéteur wifi pop qui est branché sur le switch 8 ports en RJ45! Dès que je l'enlève du switch, ça fonctionne. Tout le reste est branché là. Et elle reste verte.

Je me sens bête, j'aurai du commencer par là, enlever un par un les éléments voir si ça viendrait d'un d'entre eux.

Mais pour le coup j'en ai besoin, la box free est dans le garage, le répéteur dans le salon, je veux qu'il créé un signal pour toute la maison.

Vous auriez la raison du conflit ?

Bonjour

Envoi d’une requête 'Ping' 192.168.1.2 avec 32 octets de données :
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.2 : octets=32 temps=1000 ms TTL=255

9 ping de perdu c'est 8 de trop:

normalement on a 1 requête :
arp who-has xx:xx:xx:xx:xx:xx
arp reply yy:yy:yy:yy:yy:yy at 192.168.a.b
Et là s'arrête la requête ARP. Pour faire simple ensuite les machines communiquent par IP puis la mac sert juste à savoir à quelle hôte physique on adresse les paquets au niveau ethernet, en utilisant la fameuse "mac address table" ou "arp table" (la couche ethernet et la couche IP sont mutuellement agnostiques et correspondent grâce à cette table de correspondance en "cache")

Donc 1 ping de perdu de par la nature de la requête ARP c'est normal, le premier et en général et on à un temps de retour "long" au 2è ping comme sur le 10è ping (même si là il est très long) :
Réponse de 192.168.1.2 : octets=32 temps=1000 ms TTL=255

Il n'y aurait pas une duplicate IP sur votre réseau ?
Si depuis votre PC vous pingez la box en continue, est ce que vous perdez autant de ping que vers le boitier d'alarme ?

Que dit sur votre PC pour la mac et pour l'IP de l'alarme ?

arp -a

est ce que vous avez une ligne avec un '-' en face de la mac de l'alarme ?
Autre question, avez vous la possibilité d'afficher la configuration IP du boitier après récupération d'une IP par le DHCP ? si oui le boitier à t'il une IPv6 ?

@mmakassikis la requete DNS se fait elle en IPv4 ou en IPv6 ? (il n'y a pas de résolution IPv6 pour les serveurs de l'alarme):

$ host -t AAAA wsv3.tt-monitor.com
wsv3.tt-monitor.com has no AAAA record

lors des tests, que dit le switch ?
est ce que le port tombe sur le switch TP-LINK ?
et que disent les logs du switch (s'il en possède)?
Est ce qu'il y a des discard sur les ports ?
Des "invalid checksums" ?
Des "CRC errors" ?

Dernière question, est ce que l'activité CPU du switch TP-LINK ou de la ULTRA semble élevés ? voyez vous des trames de broadcast bombarder sur les ports des switchs ?
Idem pour le boitier de l'alarme (si vous avez un moyen de le savoir ou s'il est anormalement chaud) ?

Cordialement
nbanba

Bonjour

désolé je n'ai aps vu votre précédent message.

Je pense que la raison du conflit est dans mon dernier post : "duplicate IP sur l'IP 192.168.1.2"

Les éléments et questions de mon dernier poste visaient entre autre à mettre au jour ce type de soucis.

⇒ changez l'IP du player, mettez lui par exemple 192.168.1.252 (en vérifiant d'abord qu'aucun équipement n'a cette IP

Cordialement
nbanba

je change l'ip du répéteur wifi vous voulez dire ou celui de l'alarme ? je le change dans l'interface ? si je peux juste être sûr d'ou le changer :s redirection de port ?

JE vois actuellement dans l'onglet DHCP :
192.168.1.199 en IPV4 pour le répéteur wifi freebox (que je n'ai pas rebranché en RJ45 pour le moment vu qu'il me fait tout planter). Du coup elle n'a pas la même que la diagral? je comprends pas trop.
192.168.1.2 pour la diagral

Bonjour

Oui du repeater (ou de l'alarme)

En fait peu importe, il faut juste s'assurer que chaque machine à bien une IP différente sur le réseau.

Mais je vous recommanderais plutôt de changer l'IP du repeater car en cas de factory reset de l'alarme, elle risque de toujours vouloir reprendre 192.168.1.2

Cordialement
nbanba

Bonjour

Une machine connectée en wifi sur le répeater doit avoir 192.168.1.2.

Quelle est la plage DHCP de votre box ?

mettez un truc comme :
start-ip 192.168.1.10
end-ip 192.168.1.210

et assurez vous qu'aucune machine n'est configurée en IP fiwe avec l'IP 192.168.1.2

Cordialement
nbanba

Bonjour

PS: vérifiez tous les équipements, le player, etc… Aucun ne doit avoir l'IP 192.168.1.2 sauf l'alarme

Dans tous les cas, ça (pour les raisons déjà décrites)

Envoi d’une requête 'Ping' 192.168.1.2 avec 32 octets de données :
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.16 : Impossible de joindre l’hôte de destination.
Réponse de 192.168.1.2 : octets=32 temps=1000 ms TTL=255

+ ce que @mmakassikis à décrit à la lecture de la capture c'est caractéristique d'une duplicate IP sur le réseau

Cordialement
nbanba

Bon j'ai fait dans DHCP :
début de plage d'adresse : 192.168.1.10
fin de la plage d'adresse : 192.168.1.210

la diagral a maintenant : 192.168.1.26

Répéteur wifi non branché en RJ45. et IP : 192.168.1.199

Et dès que je le branche : la diagral passe en rouge, c'est un truc de fou cette histoire !
Je désespère !

Admin

je vous invite à configurer un bail statique pour le diagral.

Au niveau de votre installation, vous avez:
- diagral connecté en direct sur la box
- switch connecté sur le deuxième port
- switch connecté sur le troisème port
- répéteur

Si le répéteur est connecté (en ethernet via un switch intermédiaire ou en wifi), l'alarme redémarre toute les minutes. Est-ce correct ?

Avez-vous le même comportement si le répéteur est connecté en ethernet à la box (sans switch) ?

Est-ce que dans la configuration des switchs, il y a des paramétrages pour le type de trafic à authoriser ? Si oui, il faut tout autoriser.

Est-ce que vous pouvez également tester en désactivant le "Loop prevention" s'il y en a?

Bonjour

Est ce que la DIAGRAL à une carte wifi ?
Si oui, la désactiver !

Ça semblerait TRÈS bizarre pour ne pas dire impossible, mais est ce que la MAC du repeater est la même que la mac de la DIAGRAL ?

Le répeater et la DIAGRAL sont branchés sur le même switch ? le TP-LINK ?

Cordialement
nbanba

Je ne peux rien faire sur la box Diagral, c'est du plug and play. Pas de configuration sur ce module.

Ce ne sont pas les mêmes MAC entre les deux. Et les deux sont branchés différemment, la Diagral direct derrière la box Ultra et le répéteur sur le switch tp-link.

Je viens de tester en direct derrière la box et effectivement je n'ai plus de pb. Donc le coupable serait le switch ?

J'ai désactivé Loop prévention, désactiver IGMP Snooping, je vois pas ce qu'il resterai à désactiver :s

J'ai ça mais je ne sais pas ce que c'est QoS Mode: Port ou Based 802.1P Based ou DSCP/802.1P Based


											

DHCP setting dans le switch, tout est par défaut.

DHCP Setting enable
IP Address 192.168.1.13
Subnet Mask 255.255.255.0
Default Gateway 192.168.1.254

Bonjour

Ici la doc en mode "lisible"
https://transfert.free.fr/aMw0IFO

port status p37
Et loop guard c'est page 43

Regardez aussi les valeurs du storm control et si c'est activé sur les ports (page 65 et page 67)

Regardez aussi quelle IP à le TP-LINK, je crois qu'il a par défaut 192.168.1.1 ou 192.168.1.2 et comme tout équipement actif, son IP doit être maîtrisée (par exemple une IP fixe unique hors plage DHCP (entre .1 et .9 ou entre .211 et .253)
–> page 9

Cordialement
nbanba

Bonjour

DSCP c'est les classes de tagging des paquets permettant de prioriser les paquets et d'identifier des services :

https://fr.wikipedia.org/wiki/Differentiated_services https://datatracker.ietf.org/doc/html/rfc2474

N'y touchez pas !

Cordialement
nbanba

le storm control est désactivé, c'est ok ? Pas besoin de l'activer ?

Loop guard je l'ai désactivé.

J'ai désactivé le DHCP sur le switch et fixer une IP à 192.168.1.222

ça ne change rien. je vais essayer de le bouger de switch pour voir.

Bonjour

Avez vous bien vérifier que TOUS les équipements du réseau ont bien une IP différente ?

Car quand on débranche 1 truc et que ça se met à fonctionner c'est à 95% que :
- soit on a une boucle ethernet
- soit on a une duplicate IP sur le réseau

Il n'est pas impossible qu'un repeater défectueux créé une boucle s'il est connecté en RJ45 à un switch :

 
     /-->FREEBOX-)))<-----câble_virtuel_en_wifi----\
     |                                             |
     |                                             | 
     \-->SWITCH<-------rj45------->REPEATER<-------/

Cordialement
nbanba

Bonjour

@mmakassikis :
Pourriez vous SVP confirmer que le 802.11s tombe quand la connexion RJ45 du repeater est active et que le repeater joint sa gateway au travers du RJ45 ?
(je ne capte pas de BPDU donc je suppose que spanning-tree est désactivé)

Merci
Cordialement
nbanba

Bonjour

Pourriez vous valider également que vous n'avez pas fait un branchement de ce type :


     /------rj45-------->FREEBOX<-------rj45-------\
     |                                             |
     |                                             | 
     \-->SWITCH_1<-----rj45------->SWITCH_2<-------/



Cordialement
nbanba

Bonjour

On réactivera le storm-control quand ça fonctionnera normalement.
Pour le moment on désactive au mximum les feature pour troubleshoot, mais à terme faudra tout réactiver quand la root cause aura été nettement identifiée puis corrigée (notamment loop-guard)

Cordialement
nbanba

Verdict : Sur un petit switch netgear 4 ports dans mon bureau (qui est branché via une liaison murale sur ma Ultra, je n'ai pas le pb!

Sur le switch Tp-link 8 ports dans mon salon (qui est branche via une liaison murale sur ma Ultra, j'ai le pb!
Même après reset factory donc sans modification de ma part

Je me tate à commander un Netgear 8 ports pour voir… Car là je comprends pas la différence.

Freebox Ultra

   Port 1 -> Prise murale -> Switch 4 ports Bureau Netgear GS105E
   Port 2 -> Prise murale -> Switch 8 ports Salon TPLINK

J'ai déplacé le répéteur d'un à l'autre et l'alarme n'a pas le pb quand le répéteur est sur le switch 4 ports du bureau !

Bonjour

Pour moi le TP-LINK est mieux qu'un netgear et dans tou sles cas je vous recommande de choisir un équipement manageable (surtout pas passif: cf : https://dev.freebox.fr/bugs/task/39964 )

Avez vous un second repeter ? le vôtre est peut être déffectueux
Aussi peut être qu'il est hors de portée wifi de la box lorsqu'il est connecté sur le switch 4P et qu'il ne peut pas créer de boucle réseau et que le schéma devient :

 
 /-->FREEBOX-)))   ! trop loin !          <-----câble_virtuel_en_wifi----\
 |                                                                       |
 |                                                                       |
 \------------------------------>SWITCH_4P<--rj45------->REPEATER<-------/

au lieu de

     /-->FREEBOX-)))<------câble_virtuel_en_wifi------\
     |                                                |
     |                                                |
     \-->SWITCH_8P<-------rj45------->REPEATER<-------/

Notez également que l'alarme fonctionne sur le TP-LINK quand le repeater est débranché ce qui pousse à penser que le repeater est en cause.

À votre place et avant d'acheter quoi que ce soit j'attendrais la réponse de @mmakassikis à la question que j'ai posée ici : https://dev.freebox.fr/bugs/task/39966#comment186634

Et j'essayerai avec un autre repeater au cas ou le vôtre soit déffectueux.

PS: comme visiblement vous avez vérifié et vous n'avez pas de duplicate IP sur votre réseau, d'après les symptômes une boucle réseau est fort probable telle que décrit ici : https://dev.freebox.fr/bugs/task/39966#comment186633

Cordialement
nbanba

Admin
Sur le switch Tp-link 8 ports dans mon salon (qui est branche via une liaison murale sur ma Ultra, j'ai le pb!
> Même après reset factory donc sans modification de ma part

Est-ce que suite a un factory reset, le 'loop detection' est activé par défaut sur le TP-Link ?

J'ai fait encore plus simple !

J'ai tout débranché, les deux switchs !

Et ce qui est étrange : Le répéteur wifi branché en direct dans le bureau, tout fonctionne (il est assez proche de la Ultra, le bureau étant au dessus du garage)

Le répéteur wifi branché dans le salon, ça fonctionne plus !! (20mètres de cable réseau jusqu'au garage) … Mais ma prise fonctionne vu que tout le reste avec le switch est ok.

Info en + je capte le wifi de la Ultra dans le salon sans le répéteur. Je vais demander à un amis de me prêter son répéteur.

Je continue les tests demain ! Même mon alarme a détecté trop de connexion donc je peux plus continuer. Merci à vous :)

Bonjour

De mon côté je vais double connecter mon répéteur en rj45 sur 1 switchs possédant spanning-tree + en 802.11s (aujourd'hui il est juste en 802.11s) et je vais regarder ce que dit spanning-tree sur le port du switch branché au répéteur :
- si state = FORWARDING ⇒ pas de boucle causée par le repeater
- si state = BLOCKING ⇒ le repeater fait une boucle ethernet quand il est "double connectés"

Je vous dis après les tests

Cordialement
nbanba

Note pour moi demain : je vais vérifier que ce soit pas le mode Ethernet du répéteur qui fait déconner l'alarme.

Actuellement il est branché en RJ45 sur une prise murale mais proche de la box (mode Wifi affiché dans Freebox Connect). Et l'alarme fonctionne.

Demain je le remets loin de la box et en RJ45 pour voir s'il change en mode Ethernet sur l'appli, et surtout si l'alarme redéconne. Ca ferait une piste sérieuse. J'ai vu pas mal de sujets sur ce point précis sur divers tickets.

Bonjour,
Je confirme donc mon hypothèse ce matin.

Lorsque le répéteur Wifi Free se met en mode Ethernet (visible sur Freebox Connect) parce qu'il est trop loin de la Ultra, c'est lui qui me met le bordel avec mon alarme.

Dès que je rapproche le répéteur de la Ultra et qu'il passe en mode "wifi", ça fonctionne…

Je vais donc essayer avec un autre répéteur Free voir si c'est le mien qui déconne mais j'ai réellement besoin de recréer un wifi à partir du ethernet, car la Ultra est trop loin du centre de la maison.

J'ai lu pas mal de cas similaire à mon problème, est-ce qu'un patch est prévu ?

Cdt

Et je confirme, aucun doublon d'IP, et physiquement impossible d'avoir une boucle internet, car j'ai réduit mes tests à une architecture au plus simple : Freebox et uniquement l'alarme & le répéteur branché sur deux ports différents dans plusieurs endroits de la maison pour voir (je n'ai pas de baie de brassage, c'est de la rénovation donc seulement des cables tirés et qui arrivent tous vers des prises murales indépendantes dans le garage).

Bonjour

Alors … comment dire … ça merde !

Bon j'ai déplacé le repeater de chez moi pour qu'il soit à porté de câble d'un switch avec spanning-tree

Et depuis, impossible de voir le répeter UP :
Je trouve 2 nouveaux devices sur le réseau :
1 correspondant à la mac de l'AP 2.4Ghz du répeter (ce device obtien une IP)
1 correspondant à la mac de l'AP 5Ghz du répeter (ce device obtien une IP)

Par contre plus de device UP avec la mac écrite sous le repeater et 1 joli point rouge est présent sur le repeater

Donc il y bien un truc qui merde avec les repeater …

Quelques données :

Requête sur la MAC écrite sous le repeater : KO les IP ne sont pas joignables surtout l'IP du repeater 192.168.100.89 !

$ MAC=8C:97:EA:55:BB:B6; get_freebox_api lan/browser/pub | jq --arg mac "$MAC" '.result[] | select (.l2ident.id == $mac)' 
{
  "l2ident": {
    "id": "8C:97:EA:55:BB:B6",
    "type": "mac_address"
  },
  "active": false,
  "persistent": true,
  "names": [
    {
      "name": "Repeteur-Wifi-Freebox",
      "source": "mdns"
    },
    {
      "name": "Repeteur Wifi Freebox",
      "source": "mdns_srv"
    }
  ],
  "vendor_name": "Freebox Sas",
  "host_type": "freebox_wifi",
  "interface": "pub",
  "id": "ether-8c:97:ea:55:bb:b6",
  "last_time_reachable": 1736585014,
  "primary_name_manual": true,
  "l3connectivities": [
    {
      "addr": "192.168.100.89",
      "active": false,
      "reachable": false,
      "last_activity": 1736583145,
      "af": "ipv4",
      "last_time_reachable": 1736583145
    },
    {
      "addr": "192.168.100.116",
      "active": false,
      "reachable": false,
      "last_activity": 1645853071,
      "af": "ipv4",
      "last_time_reachable": 1645853071
    },
    {
      "addr": "192.168.100.90",
      "active": false,
      "reachable": false,
      "last_activity": 1658672725,
      "af": "ipv4",
      "last_time_reachable": 1658672725
    },
    {
      "addr": "fe80::8e97:eaff:fe55:bbb6",
      "active": false,
      "reachable": false,
      "last_activity": 1736585014,
      "af": "ipv6",
      "last_time_reachable": 1736585014
    },
    {
      "addr": "fd0f:ee:b0:0:8e97:eaff:fe55:bbb6",
      "active": false,
      "reachable": false,
      "last_activity": 1736585009,
      "af": "ipv6",
      "last_time_reachable": 1736585009
    }
  ],
  "default_name": "Repeteur Wifi Freebox",
  "first_activity": 1717322640,
  "reachable": false,
  "last_activity": 1736585014,
  "model": "fbxwmr",
  "primary_name": "14RV-FBXAP"
}

Requête sur la MAC 8C:97:EA:9B:1F:90 de la carte réseau 2.4GHz du repeater : OK mais ANORMAL en 802.11s !
Cette mac est joignable au travers de l'IP 192.168.100.71 !!

$ MAC=8C:97:EA:9B:1F:90; get_freebox_api lan/browser/pub | jq --arg mac "$MAC" '.result[] | select (.l2ident.id == $mac)' 
{
  "l2ident": {
    "id": "8C:97:EA:9B:1F:90",
    "type": "mac_address"
  },
  "active": true,
  "persistent": false,
  "access_point": {
    "rx_bytes": 39360,
    "type": "gateway",
    "tx_bytes": 62404,
    "tx_rate": 624,
    "uid": "537a6346d3b00881f6994f0411e7c8a5",
    "connectivity_type": "wifi",
    "wifi_information": {
      "band": "2d4g",
      "sess_duration": 984,
      "phy_rx_rate": 1444,
      "ssid": "14RV_AP-2.4GHZ",
      "standard": "n",
      "bssid": "34:27:92:D9:E0:30",
      "phy_tx_rate": 1444,
      "signal": -48
    },
    "rx_rate": 99,
    "mac": "34:27:92:63:39:90"
  },
  "vendor_name": "Freebox Sas",
  "host_type": "workstation",
  "interface": "pub",
  "id": "ether-8c:97:ea:9b:1f:90",
  "last_time_reachable": 1736586025,
  "primary_name_manual": false,
  "l3connectivities": [
    {
      "addr": "192.168.100.71",
      "active": true,
      "reachable": true,
      "last_activity": 1736586025,
      "af": "ipv4",
      "last_time_reachable": 1736586025
    },
    {
      "addr": "fe80::8e97:eaff:fe9b:1f90",
      "active": true,
      "reachable": true,
      "last_activity": 1736586023,
      "af": "ipv6",
      "last_time_reachable": 1736585997
    }
  ],
  "default_name": "",
  "first_activity": 1731525209,
  "reachable": true,
  "last_activity": 1736586025,
  "primary_name": ""
}

Requête sur la MAC 8C:97:EA:9B:1F:94 de la carte réseau 5GHz du repeater : OK mais ANORMAL en 802.11s !
Cette mac est joignable au travers de l'IP 192.168.100.67 !!

$ MAC=8C:97:EA:9B:1F:94; get_freebox_api lan/browser/pub | jq --arg mac "$MAC" '.result[] | select (.l2ident.id == $mac)' 
{
  "l2ident": {
    "id": "8C:97:EA:9B:1F:94",
    "type": "mac_address"
  },
  "active": true,
  "persistent": false,
  "access_point": {
    "rx_bytes": 65172,
    "type": "gateway",
    "tx_bytes": 102601,
    "tx_rate": 787,
    "uid": "537a6346d3b00881f6994f0411e7c8a5",
    "connectivity_type": "wifi",
    "wifi_information": {
      "band": "5g",
      "sess_duration": 1058,
      "phy_rx_rate": 8667,
      "ssid": "14RV_AP",
      "standard": "ac",
      "bssid": "34:27:92:D9:E0:34",
      "phy_tx_rate": 8667,
      "signal": -37
    },
    "rx_rate": 184,
    "mac": "34:27:92:63:39:90"
  },
  "vendor_name": "Freebox Sas",
  "host_type": "workstation",
  "interface": "pub",
  "id": "ether-8c:97:ea:9b:1f:94",
  "last_time_reachable": 1736586110,
  "primary_name_manual": false,
  "l3connectivities": [
    {
      "addr": "192.168.100.67",
      "active": true,
      "reachable": true,
      "last_activity": 1736586092,
      "af": "ipv4",
      "last_time_reachable": 1736586092
    },
    {
      "addr": "192.168.100.71",
      "active": true,
      "reachable": false,
      "last_activity": 1736586093,
      "af": "ipv4",
      "last_time_reachable": 1736586093
    },
    {
      "addr": "fe80::8e97:eaff:fe9b:1f94",
      "active": true,
      "reachable": true,
      "last_activity": 1736586111,
      "af": "ipv6",
      "last_time_reachable": 1736586110
    }
  ],
  "default_name": "",
  "first_activity": 1731525211,
  "reachable": true,
  "last_activity": 1736586111,
  "primary_name": ""
}

Donc il y a bien un truc qui merde, et pour le moment je ne suis malheureusement pas en mesure de faire le test avec spanning-tree

Cependant, si on regarde de plus près ce que je viens de poster, et notamment pour la caret 5GHz du répeater, eh bien on y détecte tout de suite un problème majeur : Le repeater créé une boucle ethernet avec lui même entre ses 2 cartes réseaux :

{
  "l2ident": {
    "id": "8C:97:EA:9B:1F:94",
    "type": "mac_address"
  },
  "active": true,
...
...
"l3connectivities": [
    {
      "addr": "192.168.100.67",
      "active": true,
      "reachable": true,
      "last_activity": 1736586092,
      "af": "ipv4",
      "last_time_reachable": 1736586092
    },
    {
      "addr": "192.168.100.71",
      "active": true,
      "reachable": false,
      "last_activity": 1736586093,
      "af": "ipv4",
      "last_time_reachable": 1736586093
    },
...

Comme vous le constatez, l'IP 192.168.100.71 précédemment associée à la carte 2.4GHz du repeater (mac 8C:97:EA:9B:1F:90) est également associée à la mac de la carte réseau 5GHz ce qui créé une boucle dans le repeater lui même

Pour preuve la qualité déguelasse du ping vers l'IP 192.168.100.71 qui est portée par 2 mac address différentes : (entre 1 et 1254 ms de jigue, perte de plus de 20 paquets entre le hop 994 et le hop 1006, BREF tout ce qui caractérise une boucle :

64 bytes from 192.168.100.71: icmp_seq=748 ttl=63 time=1.57 ms
64 bytes from 192.168.100.71: icmp_seq=749 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=750 ttl=63 time=205 ms
64 bytes from 192.168.100.71: icmp_seq=751 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=752 ttl=63 time=204 ms
From 192.168.100.239 icmp_seq=756 Destination Host Unreachable
From 192.168.100.239 icmp_seq=757 Destination Host Unreachable
From 192.168.100.239 icmp_seq=758 Destination Host Unreachable
From 192.168.100.239 icmp_seq=759 Destination Host Unreachable
From 192.168.100.239 icmp_seq=760 Destination Host Unreachable
From 192.168.100.239 icmp_seq=761 Destination Host Unreachable
From 192.168.100.239 icmp_seq=762 Destination Host Unreachable
From 192.168.100.239 icmp_seq=763 Destination Host Unreachable
From 192.168.100.239 icmp_seq=764 Destination Host Unreachable
64 bytes from 192.168.100.71: icmp_seq=765 ttl=63 time=1097 ms
64 bytes from 192.168.100.71: icmp_seq=766 ttl=63 time=82.0 ms
64 bytes from 192.168.100.71: icmp_seq=767 ttl=63 time=2.22 ms
64 bytes from 192.168.100.71: icmp_seq=768 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=769 ttl=63 time=104 ms
64 bytes from 192.168.100.71: icmp_seq=770 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=771 ttl=63 time=2.08 ms
64 bytes from 192.168.100.71: icmp_seq=772 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=773 ttl=63 time=4.30 ms
64 bytes from 192.168.100.71: icmp_seq=774 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=775 ttl=63 time=1.96 ms
64 bytes from 192.168.100.71: icmp_seq=786 ttl=63 time=207 ms
64 bytes from 192.168.100.71: icmp_seq=787 ttl=63 time=28.5 ms
64 bytes from 192.168.100.71: icmp_seq=788 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=789 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=790 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=791 ttl=63 time=181 ms
64 bytes from 192.168.100.71: icmp_seq=792 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=793 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=794 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=795 ttl=63 time=1254 ms
64 bytes from 192.168.100.71: icmp_seq=796 ttl=63 time=251 ms
64 bytes from 192.168.100.71: icmp_seq=808 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=809 ttl=63 time=107 ms
64 bytes from 192.168.100.71: icmp_seq=810 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=811 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=812 ttl=63 time=205 ms
64 bytes from 192.168.100.71: icmp_seq=813 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=814 ttl=63 time=109 ms
64 bytes from 192.168.100.71: icmp_seq=815 ttl=63 time=207 ms
64 bytes from 192.168.100.71: icmp_seq=816 ttl=63 time=206 ms
64 bytes from 192.168.100.71: icmp_seq=817 ttl=63 time=205 ms
64 bytes from 192.168.100.71: icmp_seq=829 ttl=63 time=1118 ms
64 bytes from 192.168.100.71: icmp_seq=830 ttl=63 time=94.7 ms
64 bytes from 192.168.100.71: icmp_seq=831 ttl=63 time=2.70 ms
64 bytes from 192.168.100.71: icmp_seq=832 ttl=63 time=1.37 ms
64 bytes from 192.168.100.71: icmp_seq=833 ttl=63 time=1.37 ms
64 bytes from 192.168.100.71: icmp_seq=834 ttl=63 time=1.85 ms
64 bytes from 192.168.100.71: icmp_seq=835 ttl=63 time=1.56 ms
64 bytes from 192.168.100.71: icmp_seq=836 ttl=63 time=3.56 ms
64 bytes from 192.168.100.71: icmp_seq=837 ttl=63 time=2.97 ms
64 bytes from 192.168.100.71: icmp_seq=838 ttl=63 time=3.01 ms
64 bytes from 192.168.100.71: icmp_seq=839 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=852 ttl=63 time=179 ms
64 bytes from 192.168.100.71: icmp_seq=853 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=854 ttl=63 time=49.6 ms
64 bytes from 192.168.100.71: icmp_seq=855 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=856 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=857 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=858 ttl=63 time=104 ms
64 bytes from 192.168.100.71: icmp_seq=859 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=860 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=861 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=862 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=875 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=876 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=877 ttl=63 time=111 ms
64 bytes from 192.168.100.71: icmp_seq=878 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=879 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=880 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=881 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=882 ttl=63 time=158 ms
64 bytes from 192.168.100.71: icmp_seq=883 ttl=63 time=205 ms
64 bytes from 192.168.100.71: icmp_seq=884 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=895 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=896 ttl=63 time=102 ms
64 bytes from 192.168.100.71: icmp_seq=897 ttl=63 time=1.77 ms
64 bytes from 192.168.100.71: icmp_seq=898 ttl=63 time=39.4 ms
64 bytes from 192.168.100.71: icmp_seq=899 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=900 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=901 ttl=63 time=1.91 ms
64 bytes from 192.168.100.71: icmp_seq=902 ttl=63 time=104 ms
64 bytes from 192.168.100.71: icmp_seq=903 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=904 ttl=63 time=102 ms
64 bytes from 192.168.100.71: icmp_seq=905 ttl=63 time=107 ms
64 bytes from 192.168.100.71: icmp_seq=917 ttl=63 time=5.44 ms
64 bytes from 192.168.100.71: icmp_seq=918 ttl=63 time=2.14 ms
64 bytes from 192.168.100.71: icmp_seq=919 ttl=63 time=102 ms
64 bytes from 192.168.100.71: icmp_seq=920 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=921 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=922 ttl=63 time=87.2 ms
64 bytes from 192.168.100.71: icmp_seq=923 ttl=63 time=102 ms
64 bytes from 192.168.100.71: icmp_seq=924 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=925 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=926 ttl=63 time=1.80 ms
64 bytes from 192.168.100.71: icmp_seq=927 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=939 ttl=63 time=109 ms
64 bytes from 192.168.100.71: icmp_seq=940 ttl=63 time=102 ms
64 bytes from 192.168.100.71: icmp_seq=941 ttl=63 time=104 ms
64 bytes from 192.168.100.71: icmp_seq=942 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=943 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=944 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=945 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=946 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=947 ttl=63 time=104 ms
64 bytes from 192.168.100.71: icmp_seq=948 ttl=63 time=102 ms
64 bytes from 192.168.100.71: icmp_seq=949 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=962 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=963 ttl=63 time=205 ms
64 bytes from 192.168.100.71: icmp_seq=964 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=965 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=966 ttl=63 time=207 ms
64 bytes from 192.168.100.71: icmp_seq=967 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=968 ttl=63 time=205 ms
64 bytes from 192.168.100.71: icmp_seq=969 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=970 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=971 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=984 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=985 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=986 ttl=63 time=203 ms
64 bytes from 192.168.100.71: icmp_seq=987 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=988 ttl=63 time=104 ms
64 bytes from 192.168.100.71: icmp_seq=989 ttl=63 time=3.17 ms
64 bytes from 192.168.100.71: icmp_seq=990 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=991 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=992 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=993 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=994 ttl=63 time=204 ms
64 bytes from 192.168.100.71: icmp_seq=1006 ttl=63 time=207 ms
64 bytes from 192.168.100.71: icmp_seq=1007 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1008 ttl=63 time=104 ms
64 bytes from 192.168.100.71: icmp_seq=1009 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1010 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1011 ttl=63 time=53.3 ms
64 bytes from 192.168.100.71: icmp_seq=1012 ttl=63 time=99.4 ms
64 bytes from 192.168.100.71: icmp_seq=1013 ttl=63 time=99.0 ms
64 bytes from 192.168.100.71: icmp_seq=1014 ttl=63 time=96.8 ms
64 bytes from 192.168.100.71: icmp_seq=1015 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=1016 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=1028 ttl=63 time=105 ms
64 bytes from 192.168.100.71: icmp_seq=1029 ttl=63 time=1.84 ms
64 bytes from 192.168.100.71: icmp_seq=1030 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1031 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1032 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1033 ttl=63 time=1.53 ms
64 bytes from 192.168.100.71: icmp_seq=1034 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1035 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1036 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1037 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1038 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1051 ttl=63 time=4.67 ms
64 bytes from 192.168.100.71: icmp_seq=1052 ttl=63 time=103 ms
64 bytes from 192.168.100.71: icmp_seq=1053 ttl=63 time=1.52 ms
64 bytes from 192.168.100.71: icmp_seq=1054 ttl=63 time=107 ms

Donc désolé, je reprend les tests dès que j'aurais réussi à refaire fonctionner ce repeater avec 1 IP unique : 192.168.100.89 associée à la MAC qui est SOUS le repeater: 8C:97:EA:55:BB:B6 et pas d'IP sur les cartes internes 2.4GHz et 5GHz internes au repeater

Cordialement
nbanba

Bonjour,

Ok, De mon côté je n'ai pas de voyant rouge par contre, peu importe s'il est loin de la box ou non, en Wifi ou Ethernet.

En Ethernet, il arrive bien à recréer un réseau ultra puissant via le Ethernet. C'est seulement le problème de boucle avec mon alarme qui me pose soucis. Et c'est ce qui m'étonne d'ailleurs, c'est que seule mon alarme est impactée ! Tous les autres appareils, je n'ai pas l'impression. La télé ne coupe pas, quand je télécharge idem. C'est étrange.

Juste pour ma connaissance, il faut que le répéteur arrive à détecter le wifi de la box Ultra même s'il est en Ethernet pour fonctionner ? C'est bien le Ethernet backhaul ? ça permet de d'augmenter la puissance mais il faut tout de même qu'ils se captent entre eux. Ce qui dans mon cas est normalement bon. Je capte bien le wifi du garage même s'il n'est pas puissant.

Bonjour

@mmakassikis : Il y a bien un problème majeur avec les repeater, même sur les DELTA (lire mon dernier post ici)

Mon répeater reste en status "reboot_failiure" :

$ get_freebox_api repeater | jq
{
  "success": true,
  "result": [
    {
      "connection": "disconnected",
      "ip": {},
      "boot_time": 0,
      "led_activated": true,
      "status": "reboot_failure",
      "main_mac": "8C:97:EA:55:BB:B6",
      "enabled": true,
      "advice": {
        "too_close": false
      },
      "sn": "399904J202042344",
      "id": 1,
      "api_ver": 2,
      "last_seen": 1736585031,
      "name": "Entrée",
      "model": "fbxwmr-r1",
      "backhaul": [],
      "last_bh_type": "wifi",
      "fronthaul": [],
      "firmware_version": "2.5.8"
    }
  ]
}

Pour info, j'ai juste débranché électriquement le repeater de sa position (dans l'entrée) pour le rebrancher dans un des rack à côté d'un switch

Le repeater ne remonte pas pour le moment
Je tente un reset

PS: même en erreur, un repeater NE devrait PAS créer une boucle interne entre ses 2 cartes réseaux ⇒ un FIX semble nécessaire

Cordialement
nbanba

Bonjour

Alors ce ticket commence à faire un peu cours de réseau… mais pour vous répondre à mon sens: NON

2 modes (je vais essayer d faire un "joli" schéma):

1) simple AP:


    ((((( FREEBOX ---------------------> RJ45 ----> REPEATER )))))))

2) 802.11s = mesh


   ((((( FREEBOX ))))))                        ((((( REPEATER_1 )))))


                               
                        ((((( REPEATER_2 )))))

...

 ((((( REPEATER_N-1 ))))))                        ((((( REPEATER_N )))))

Normalement en mode "Simple AP" la liaison 802.11s doit se couper à chaque endroit ou elle peut créer une boucle car le "cost spanning-tree" est plus important en 802.11s que par le câble car le "cost" dépend du 'link-speed" qui est supérieur en RJ45 (https://www.hojmark.net/stp-port-cost)

Cordialement
nbanba

Bonjour

Alors là, MAGIQUE !

Après 1h30 de de déconnade complète du repeater, sans rien faire il est remonté:

$ get_freebox_api repeater | jq
{
  "success": true,
  "result": [
    {
      "connection": "connected",
      "ip": {
        "v6": "fd0f:ee:b0:0:8e97:eaff:fe55:bbb6",
        "v4": "192.168.100.89"
      },
      "boot_time": 1736585939,
      "led_activated": true,
      "status": "running",
      "main_mac": "8C:97:EA:55:BB:B6",
      "enabled": true,
      "advice": {
        "too_close": true
      },
      "sn": "399904J202042344",
      "id": 1,
      "api_ver": 2,
      "last_seen": 0,
      "name": "Entrée",
      "model": "fbxwmr-r1",
      "backhaul": [
        {
          "mac": "8E:97:EA:9B:1F:91",
          "type": "wifi",
          "placement": 13,
          "placement_str": "good",
          "too_close": true,
          "band": "2d4g",
          "throughput": 54436,
          "best": false,
          "signal": -32
        },
        {
          "mac": "8E:97:EA:9B:1F:95",
          "type": "wifi",
          "placement": 100,
          "placement_str": "strong",
          "too_close": true,
          "band": "5g",
          "throughput": 663849,
          "best": true,
          "signal": -35
        },
        {
          "mac": "06:48:69:B0:4E:CC",
          "type": "eth",
          "best": false
        }
      ],
      "last_bh_type": "unknown",
      "fronthaul": [
        {
          "enabled": true,
          "bssid": "8C:97:EA:9B:1F:90",
          "ssid": "14RV_AP-2.4GHZ",
          "band": "2d4g"
        },
        {
          "enabled": false,
          "bssid": "8E:97:EA:9B:1F:90",
          "ssid": "",
          "band": "2d4g"
        },
        {
          "enabled": true,
          "bssid": "8C:97:EA:9B:1F:94",
          "ssid": "14RV_AP",
          "band": "5g"
        },
        {
          "enabled": false,
          "bssid": "8E:97:EA:9B:1F:94",
          "ssid": "",
          "band": "5g"
        }
      ],
      "firmware_version": "2.5.8"
    }
  ]
}

Et les IP associées aux 2 cartes réseaux (2.4GHz et 5GHz) ne sont plus joignables…

Même si c'est remonté tout seul, il y a bien un truc qui n'est pas normal (la coupure aurait du durer 1 minute, pas 95 minutes en créant une boucle interne au repeater pendant 93 minutes …!)

BREF, je peux enfin faire le test de brancher un RJ45 car le repeater est en 802.11s

switch: port ethernet 1/0/18
bon je branche 1 RJ45 et je reviens avec les résultats

Cordialement
nbanba

Bonjour

C'est sans appel :

Eth 1/0/18  ALTN BLK   32768.74:AC:B9:A0:EF:81      128.2        128    20000 EN 

Le chemin est bloqué :

Eth 1/0/18 Information
---------------------------------------------------------------
 Stp Status                        : Enabled
 Port Role/State                   : Alternate/Discarding
...

Et les logs sont claires:

11:01:48 2025-01-11 STP port state: MSTID 0, Eth 1/0/18 becomes non-forwarding.  

En bref, quand un répeater est en 802.11s et qu'on branche un RJ45 dessus depuis un switch qui implémente spanning-tree ⇒ alors spanning-tree détecte une boucle et BLOQUE LE PORT RJ45 du repeater (par sécurité)

Quand on fait le même chose avec un switch qui N'implémente PAS spanning-tree, alors ON A UNE BOUCLE qui se créé et rien pour empêcher cette boucle de faire dysfonctionner le réseau

@free: je crois qu'il est temps d'implémenter spanning-tree sur les switchs, les AP des box et les repeaters

PS: ça ne concerne pas que les ULTRA, j'ai une DELTA avec repeater de 1è génération et le constat est sans appel, ça boucle

Cordialement
nbanba

bon ça me rassure que vous constatiez un problème ;) (désolé pour les questions de réseaux, j'arrête^^)

J'ai essayé avec le répéteur de mon ami mais c'est une ancienne version RP01A et il n'a pas voulu se connecter du tout à la Ultra, que ce soit en Ethernet ou en Wifi, même après un reset. Le mien RP02A est reconnu.

Je vais essayer avec potentiellement un autre répéteur wifi d'une autre marque si j'en trouve un. Qui gérerait mieux ce cas.

Bonjour

Pas de problèmes pour les questions de réseaux, je préfère quelqu'un qui s'intéresse à comment ça fonctionne que quelqu'un qui dit juste : "ça ne marche pas" et qui veut qu'on résolve son problème sans que lui même ne s'y investisse.
Je déteste la paresse intellectuelle ⇒ vos questions sont plutôt bienvenues elle démontrent une réelle envie de comprendre comment ça fonctionne et ça permet d'aller plus loin dans les analyses.

PS: je n'ai pas essayé mais à mon avis il faut un repeater qui supporte le WIFI6 minimum (peut être le WIFI7) et le WPA3 Personnal en plus du 802.11s pour que ça fonctionne, à moins que Free n'ait véroullié et que seul les repeaters FREE soient utilisable

Cordialement
nbanba

@nbanba
Bonjour,
Juste un point qui me questionne, je n'arrive pas à comprendre pourquoi seulement le module Diagral déconne dans mon cas et tous les autres périphériques n'ont pas le soucis ? Vous auriez une idée ?

Je reçois un deuxième répéteur ce jour, je répéterai seulement le signal wifi pour le moment et non en point d'accès (j'espère que ça va suffire pour couvrir la maison) mais j'espère qu'un correctif sera mis en place vis à vis de votre analyse et de vos retours.

@free , @mmakassikis vous avez reproduis le soucis ?

Merci beaucoup,
Cdt

Admin

@Hypolepic

Merci pour les différents tests.

Quand le répéteur est connecté en ethernet à la box, c'est ce lien là qui est préféré plutôt que du wifi.

Si j'ai bien suivi les résultats des différents tests, le problème sur votre alarme se présente quand les deux conditions suivantes sont vraies:
- le répéteur est connecté en ethernet à la box (en direct ou via un switch)
- le switch TP-Link est également connecté à la box

Autrement dit, pas de problème dans les scénarios suivants:
- le répéteur est en wifi
- répéteur en ethernet, mais pas de switch TP-Link connecté au réseau local

Est-ce correct ?

Avez vous fait le test avec le répéteur connecté en ethernet, et en désactivant le protocole de détection de boucle sur le switch ?

Bonjour

@makassikis : merci pour votre aide.
Indépendamment du présent incident, j'ai bien détecté un comportement anormal avec le repeater de ma delta + spanning-tree, comportement pouvant êtres en rapport avec ce ticket.
Voir les messages de ce thread à partir de : https://dev.freebox.fr/bugs/task/39966#comment186648

@Hypolepic : il faudrait des données plus précises depuis les autres devices pour expliquer le phénomène (des captures de paquets par exemple). Je réfléchis à un protocole de test

Cordialement
nbanba

@mmakassikis, non dans mon cas, c'est encore plus simple, j'ai réduit mon test au plus simple, sans switch :

- Freebox Ultra
- Répéteur Wifi branché sur une prise murale Ethernet (sans switch) dans le salon pour pas qu'il soit trop proche de la box, prise qui est directement reliée à la Freebox par un grand cable, une autre prise murale dans le garage et un petit cable entre la prise et la freebox.
- Alarme en direct sur la freebox ou bien prise murale du bureau.

Je résume :
Garage :
Freebox ⇒ petit câble ⇒ PRISE MURALE RJ45 GARAGE ⇒ grand câble ⇒ PRISE MURALE RJ45 SALON ⇒ petit câble ⇒ répéteur

Freebox ⇒ petit câble ⇒ PRISE MURALE RJ45 GARAGE ⇒ grand câble ⇒ PRISE MURALE RJ45 SALON ⇒ petit câble ⇒ alarme

Testé également en branchant directement l'alarme derrière la Freebox dans le garage.

C'est tout !

Et j'ai le problème de coupure d'alarme mais j'ai l'impression moins longues que quand ça passe par les switchs.

Freebox ⇒ petit câble ⇒ PRISE MURALE RJ45 GARAGE ⇒ grand câble ⇒ PRISE MURALE RJ45 SALON BUREAU⇒ petit câble ⇒ alarme

Ethyn commented on 14.01.2025 21:50

J’ouvre des tickets en appelant au secours pour exactement la même problématique avec ma delta (alarme d’une autre marque) depuis l’installation de mon deuxième répéteur et je tombe sur ce ticket!!! Merci je ne suis pas fou, je tente une dernière manipulation et je reviens vers vous pour faire mon retour.

Moi c'est dès le premier^^ en Ethernet. Du coup en attendant les réponses, je fonctionne avec deux répéteurs en mode wifi mais bon la vitesse c'est pas la même.

Ethyn commented on 15.01.2025 17:37

Depuis mi décembre j’ai testé ma centrale d’alarme chez mes parents server pop avec un répéteur ethernet, centrale jamais déconnectée pendant 15 jours, je mets la centrale chez des voisins server delta avec un répéteur ethernet centrale jamais déconnectée pendant 15 jours. Je branche la centrale chez moi server delta avec 2 répéteur wifi en ethernet. Elle a tenue 5 minutes! Et tous les autres appareils fonctionnent correctement. Il y a un dev pour sauver le soldat Ryan les gars? C’est matériel c’est logiciel? Je lache pas Free c’est la famille alors me lâcher pas please

Admin

@Ethyn

Quelle est l'adresse MAC de votre box ?

Pouvez-vous préciser le modèle de centrale d'alarme ? Est-elle branchée en direct sur la box, ou y a-t-il des switchs par exemple ?

Elle a tenue 5 minutes

Que se passe-t-il concrètement au bout des 5 minutes ?

Est-ce qu'elle se comporte normalement si les répéteurs sont en wifi ?

Ethyn commented on 15.01.2025 18:54

Bonsoir,
Mac du server dc:00:B0:3B:88:92
Modèle alarme: SHBi de Tike Sécurité
Centrale branchée en direct sur le server
Aucun switch présent sur l’installation
Symptômes: centrale visible sur Freebox Connect comme si « tout allait bien » mais quand je vais sur l’application pour la mettre en fonction plus aucune communication entrante ou sortante possible avec la centrale.
Je vais faire le test dès ce soir en débranchant les 2 répéteurs pour une communication only wifi et je reviens vous faire un retour dès que le symptôme reviens ou plus tard si la centrale « tiens le coup »
Merci de votre intérêt pour ce ticket

Ethyn commented on 16.01.2025 18:03

Bonsoir,

Après 24h d’activitée only wifi des répéteurs, ma centrale d’alarme répond parfaitement. Je peu recréer ce bug à volonté si vous avez besoin voir bêta testé les maj si besoin

@mmakassikis

Bonjour, j'ai l'impression qu'effectivement nous sommes dans le même cas @Ethyn et moi. Vous n'avez pas eu d'autres retours dans ce sens ?

Même en ayant l'installation la plus simple possible (sans switch), le répéteur en mode point d'accès via Ethernet génère une boucle qui perturbe certains appareils.

Est-ce que le diagnostic et le bug découvert par @nbanba est testé de votre côté ?

Merci beaucoup :)

Ethyn commented on 17.01.2025 16:41

Un collègues à repérer ce problème il y a de ça déjà un petit moment et ne voyant aucun correctif arrivé il a investi dans un réseau mesh tiers et a plus aucun problème, la particularité de ce bug est qu’il touche (pour une obscure raison à mes yeux) seulement quelques rare configuration, dans notre cas les alarmes avec répéteurs. Le restant du matériel étant parfaitement opérationnel les remontées comme les nôtres ont de ce fait pas inondé le bugtracker. Un p’tit correctif à tester les devs?

Ethyn commented on 26.01.2025 19:05

Bonjour,

la nouvelle màj a rien changé au problème de boucle des répéteurs

Cordialement

Bonjour @free,

Est-ce que ce bug est programmé dans une version :) ?

Merci,

Cdt

Ethyn commented on 31.01.2025 16:06

Bonjour,

Je dois choisir entre avoir une alarme défaillante ou un débits à 12Mbit en wifi avec la fibre. Je ne peux pas changer d’oc (cqfd!) et ce bug de boucle réseau a pu être trouver et répété à la demande. Sans en dire trop, juste savoir si c’est bien mis sur la to do list d’un dev? est ce que c’est trop demandé?

Bonjour,

Un petit up, nous sommes obligé de laisser les répéteurs en mode wifi et non en point d'accès, ce n'est pas les mêmes performances…

Est-ce que ce point fait parti de votre todo list ?

Merci beaucoup,

cdt

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing