En complément, le logiciel est sur une machine qui est sur un réseau d’entreprise, est-ce possible que les ports concernés sont bloqués (comment puis-je tester pour savoir si c’est le cas et y a-t-il une solution le cas échéant ?)
Effectivement ça a l’air que l’accès au serveur turn est impossible depuis ce réseau comme en témoigne le message d’erreur. Le serveur TURN utilise une plage de ports UDP choisis aléatoirement entre 10000 et 30000.
C’est embêtant, je suis sur un réseau d’université… il y aurait beaucoup d’utilisateurs potentiels parmi les professeurs et chercheurs vu le contexte avec les États-Unis. Quelle serait la solution ? Je peux faire des tests si c’est utile.
Une solution serait de migrer de Microsoft Windows vers GNU LINUX … vu le contexte avec les États -Unis … Surtout sur un réseau d’université, et donc de partage du savoir…
C’est juste un point de vue personnel, que je partage ici avec vous.
Jamicalement
Oui, vous avez raison, utiliser Linux est idéal. Le problème c’est que pour les postes professionnels, nous sommes dépendants de notre employeur et selon ce que je vois, ce n’est pas demain que les universités vont migrer sous Linux, même si personnellement je trouverais ceci intéressant. Tout (à l’exception de quelques Macs) tourne sous Windows 10/11. Donc, si nous voulons utiliser Jami sur ces ordinateurs, il faut se rabattre vers une solution qui fonctionne sous Windows (à moins d’utiliser une machine virtuelle).
Nous comprenons, “la bataille du libre” est loin d’être gagnée MAIS plutôt que “se battre” vers une solution qui fonctionne sous Windows, nous vous proposons de coopérer au projet commun jami pour améliorer jami sous windows.
Plusieurs solutions
ouvrir des tickets rapports de bugs en joignant le “journal de logs de jami” ici https://git.jami.net/savoirfairelinux c’est l’espace de travail de tous les développeurs jami répartis sur la surface de la planète
vous joindre à nous sur l’essaim (swarm) Jami Test Communauté, sur lequel se retrouvent des utilisateurs jami et des développeurs de jami.
Notre pseudo jami est orevlucanje notre ID a93cc53e35092bdb3cc731fc3ec8ca72c187187c
Envoyez-nous une demande à partir de votre jami et nous vous inviterons à rejoindre cet essaim francophone sympathique et convivial, d’abeilles à l’ouvrage pour améliorer jami sur tous les OS gnulinux, windows et mac. Il y a parmi nous des utilisateurs jami sous windows
Pouvez-vous confirmer qu’il s’agit bien du serveur TURN et que son enregistrement dans les DNS est correct? J’ai remarqué que certains outils utilisés en entreprise (Cisco Umbrella par exemple) vont bloquer les IP associées à *.JAMI.NET, possiblement parce qu’il ne peuvent effectuer un reverse DNS lookup.
Bien que l’architecture de Jami soit fondamentalement P2P, elle a besoin de pouvoir s’appuyer sur des serveurs initiaux pour se mettre en place, et il faut que ces serveurs soient disponibles. On peut aussi utiliser n’importe quel serveur TURN mais il faut avoir confiance dans qui l’exploite.
Un grand merci pour votre réponse détaillée. Je me suis rendu compte que quand je suis hors réseau WiFi avec mon téléphone, Jami ne parvenais pas à se connecter quand j’étais sur des données cellulaires (avec Télus, au Québec). J’ai donc mis l’IP numérique que vous avez fourni et j’ai constaté immédiatement que jami parvenait à se connecter ainsi (avec 51.79.146.53) à la place de turn.jami.netJe suspecte donc que plusieurs utilisateurs devraient avoir aussi cet enjeu et cela voudrait la peine de suggérer cette solution dans l’aide en ligne multilingue (à moins qu’elle soit déjà documentée, mais je n’ai rien trouvé de tel). Je vais tester cette solution demain sur mon PC au travail pour voir si cela résout le problème que vous mentionnez (problème de reverse DNS lookup).
la résolution DNS turn.jami.net est géolocalisée, selon l’emplacement de l’utilisateur la liste des adresses IP renvoyée par le DNS n’est pas la même. 144.217.83.140 fait partie des adresses turn.jami.net mais en Amérique du Nord seulement. La liste exacte des adresses IP peut changer de temps en temps. J’ai créé un PTR dans le domaine jami.net pour cette adresse, mais ça peut prendre un peu de temps pour se propager sur Internet. Merci pour la suggestion.
Je suis de retour sur mon poste professionnel à l’université et j’ai fait quelques tests; la connexion au réseau JAMI ne fonctionne toujours pas sur ce réseau. Voici les lignes concernées dans le log (avec la commande jami.exe -d dans le terminal Windows pour démarrer JAMI):
J’ai essayé aussi sur Linux avec mon portable sur Zorin OS 17.3, via le réseau sans fil de mon université cette fois-ci. J’obtiens le même résultat avec "cache for turn resolution failed". Le problème me semble être externe au système d’exploitation. Testé aussi avec téléphone iPhone (iOS) et Android, avec des résultats similaires.
Malheureusement cette proposition de solution n’a pas fonctionné, merci toutefois d’avoir essayé. Y a-t-il autre chose à tester pour tenter de trouver une issue ?
L’enregistrement PTR au niveau du DNS n’est pas suffisant semble-t-il. Voici un exemple où un firewall d’entreprise Cisco Umbrella bloque l’accès au forum. Pourtant, d’autres forums de discussion tels que https://forum.openwrt.org sont accessibles.
Cisco utilise OpenDNS pour catégoriser les noms de domaine (dans l’exemple ci-dessus FORUM.JAMI.NET) et décider de retourner ou non une adresse IP valide. Si l’entreprise a défini une liste noire de catégories interdites (ex. drogue, sexe, suicide, etc.) ou de domaines interdit et que le nom demandé fait partie de cette liste noire, alors l’adresse retournée affichera la page de blocage de la capture d’écran.
Je n’utilise pas OpenDNS et je n’y ai pas de compte, mais un premier pas pour éviter que ces firewalls (en fait, les résolveurs de noms qui s’appuient sur ces listes de noms de domaines) n’empêchent le bon fonctionnement de l’écosystème Jami serait que quelqu’un (de l’équipe Jami?) aille sur la page de soumission des domaines OpenDNS Community > Domain Tagging > Details for jami.net, menu Submit Domain et vote pour catégoriser correctement tous les noms de domaines et sous-domaines utilisés par le projet.
Un palliatif serait d’avoir sur une page Web qui ne peut être modifiée par le public, toutes les adresses IPv4 et IPv6 utilisées par le projet avec les noms associés. Ainsi, dans certains cas, on pourrait contourner la résolution de noms.
Est-ce que ça serait le traffic UDP qui serait bloqué? Il y a plusieurs adresses IP dans le log pour lesquelles la connexion échoue, toutes hébergées chez OVH. Comme je l’ai mentionné dans un autre post, ça serait bien si l’équipe du projet @Jami avait une page qui liste toutes les adresses utilisées par le projet.
Pour commencer, dans une fenêtre de terminal de la machine linux, quels résultats fournissent les commandes:
Voici le résultat des quatre commandes sur le PC où JAMI ne parvient pas à obtenir une connectivité réseau :
C:\>ping turn.jami.net
Envoi d’une requête 'ping' sur turn.jami.net [144.217.83.140] avec 32 octets de données :
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
C:\>ping 144.217.83.140
Envoi d’une requête 'Ping' 144.217.83.140 avec 32 octets de données :
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
Réponse de 144.217.83.140 : octets=32 temps=4 ms TTL=50
Statistiques Ping pour 144.217.83.140:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 4ms, Maximum = 4ms, Moyenne = 4ms
C:\>ping 2607:5300:205:200::35a1
Envoi d’une requête 'Ping' 2607:5300:205:200::35a1 avec 32 octets de données :
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
PING : échec de la transmission. Défaillance générale.
Statistiques Ping pour 2607:5300:205:200::35a1:
Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),
C:\>tracert turn.jami.net
Détermination de l’itinéraire vers turn.jami.net [144.217.83.140]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 172.20.12.220
2 17 ms 21 ms 21 ms uqtr-membre.risq.net [206.167.253.219]
3 <1 ms <1 ms <1 ms uqtr-internet.dtsrv-uq.risq.net [132.202.61.205]
4 * * * Délai d’attente de la demande dépassé.
5 3 ms 3 ms 3 ms imtrl-uq-ic-co-gw.risq.net [192.77.63.65]
6 6 ms 4 ms 5 ms ovh.peer.qix.ca [198.179.18.33]
7 * * * Délai d’attente de la demande dépassé.
8 * * * Délai d’attente de la demande dépassé.
9 * * * Délai d’attente de la demande dépassé.
10 4 ms 5 ms 5 ms be106.bhs-g1-nc5.qc.ca [142.44.208.173]
11 * * * Délai d’attente de la demande dépassé.
12 * * * Délai d’attente de la demande dépassé.
13 * * * Délai d’attente de la demande dépassé.
14 * * * Délai d’attente de la demande dépassé.
15 4 ms 4 ms 4 ms 149.56.50.4
16 * * * Délai d’attente de la demande dépassé.
17 4 ms 4 ms 4 ms turnca2.jami.net [144.217.83.140]
Itinéraire déterminé.
… vu le contexte avec les États -Unis … Surtout sur un réseau d’université, et donc de partage du savoir…
