CoolRaoul

Bien entendu tu as fait "grep 10002" et pas "grep PORT_INTERFACE_WEB_DRIVE" comme on me l'a demandé D'ailleurs je l'ai refait un peu plus tard avec "grep 6690" et j'ai posté le résultat ici : Ca y ressemble Je viens de faire un test avec mon smartphone connecté uniquement sur le réseau mobile Le port 5001 de mon NAS n'est pas accessible en IPV6 mais c'est OK en IPV5 Faut que je vérifie le firewall (et reboote ma box aussi j'imagine)

Complément: sur l'appli smartphone, en utilisant le nom qui résout en IPV6, si je patiente jusqu'à ce que la connexion se fasse, une fois le lien établi tout fonctionne et avec fluidité en plus.

C'est quand même un peu pénible d'avoir à installer le client local sur mon poste pour ce problème sur l'appli mobile et je n'ai pas trop d'espoir que ca donne quoi que ce soit Mais je vais tester (et apres arrête, j'ai le workaround IPV4 qui me dépanne) ***EDIT*** Test effectué avec le client Windows, ça fonctionne sans probleme en local sans ralentissements Et j'ai bien du traffic détecté sur le port 6690 (wireshark sur le poste Windows) Mais je ne vois pas qu'en conclure

Reste que je trouve étrange de ne rien capturer étant donné que pendant que la capture était en cours j'ai visualisé un fichier du drive via l'appli Synology Drive via mon smartphone. Il sert à quoi ce port?

Une seule interface sur mon NAS. En outre je maitrise cette commande que j'utilise régulièrement en particulier dans mon boulot. Pour capturer sur toutes les interfaces j''utilise la syntaxe "-i any" plutôt.

Et j'attends combien de temps qu'il se passe quelque chose? Note: j'ai lancé cette capture avec ma connexion Drive active en IPV4 (pendant laquelle j'ai fait un transfert de fichier) et je n'ai rien vu passer Et le port 6690 est bien en écoute autant en IPV4 qu'en IPV6 tcp 0 0 0.0.0.0:6690 0.0.0.0:* LISTEN 19730/syncd tcp6 0 0 :::6690 :::* LISTEN 19730/syncd [root@fserv_~]$ ps -fp 19730 UID PID PPID C STIME TTY TIME CMD root 19730 1 0 Jan18 ? 00:27:49 /var/packages/SynologyDrive/target/sbin/syncd

le grep ne capture rien Je l'ai initialement constaté avec le smartphone connecté au WIFi, même LAN sur mon NAS.

Rien qui ne ressemble à ça dans la version Android

C'est bien ça Le nom que j'utilisais pour me connecter était déclaré dans la console d'admin de domaine de mon hébergement sous forme d'enregistrement de type "A" (IPV4) avec l'IP correspondante *et* sous forme d'enregistrement de type "AAA" (IPV6, avec l'IP du NAS lui-même) J'ai créé un enregistrement avec un autre nom (type "monnas-V4.<mondomaine>.com") et, en utilisant ce FQDN dans le formulaire de connexion Drive ce qui force l'utilisation de l'IP V4 la connexion se fait normalement (ne prend pas des plombes)

Oui j'ai compris entre temps, tu voulais dire ne pas utiliser https. Mais entre-temps j'ai pu déterminer que mon problème est lié à IPV6 et pas SSL (et ça reste mystérieux)

Oui: Ce n'est forcément pas un pb d'autorisation puisque ça marche si on patiente (beaucoup) non? ***EDIT*** Suis parvenu à cerner le périmètre du PB C'est bien IPV6 qui déconne (le passage par l'IP V4 "en dur" m'avait mis sur la voie) J'ai ajouté une entrée IPV4 de type "A" sans alias de type "AAAA" dans ma zone DNS et en utilisant celle-là plus de timeout Mais la raison pour laquelle le phénomène n'impacte que Drive et pas les autres applis Syno m'échappe complètement.

Impossible: je suis chez Free Par contre j'ai remplacé le dom de mon NAS par son IP (V4) dans le formulaire de connexion (ce qui revient au même). Pas de changement Il est important de noter que dans tous les cas la connexion finit par aboutir (j'avais mon smartphone laissé sur "connexion en cours" hier et ce matin Drive était connecté) mais le temps d'établissement de session est ridiculement long. Effectivement, en HTTP je suis parvenu à obtenir une connexion quasi est immédiate. Mais étrangement uniquement si j'utilise l'IP et pas le nom. Allez comprendre. (faudra quand même faire d'autres expériences pour valider) En quoi consiste cette opération?

Ce n'est pas une solution applicable pour moi: Docker pas supporté par mon petit NAS. Je cherche une solution simple à mettre en oeuvre, non seulement pour moi (et encore je me débrouille, merci) mais pour d'autres utilisateurs de mon NAS (des membres de la famille). Drive correspond à mon utilisation et dans ce contexte fonctionnait parfaitement jusqu'ici. Je ne cherche pas de fonctionnalités supplémentaires.

Oui j'y penserai dans l'avenir (à noter que je n'ai eu qu'un seul blocage pour le moment lors de mes tests en cours) Mais pour l'instant c'est ce probleme de lenteur extrème qui me préoccupe. Et voilà maintenant un nouveau mystère: La version de Drive qui s'affiuche sur le Play Store est la 2.2.0: Cette que je viens d'installer s'annonce comme la 2.3.0: Et je découvre une 2.5 ici sur le site Synology! https://community.synology.com/enu/forum/1/post/149404 je vous avoue être un peu perdu!

Résultat du test (apres avoir réinstallé application) • Activation (user+pass) à 16:15 • Terminée à 16:21 Dernière chance : je vais refaire un essai après redémarrage du téléphone

Je suis reparti à zero. La connexion a fini par se faire mais ça a pris un temps fou. Et une fois connecté tout est extrêmement lent, carrément inutilisable Et je répète : DS File (meme adresse , meme compte NAS) fonctionne sans aucun problème! C'était l'IP de mon routeur (coté interne). Je l'ai supprimé de la liste des blocages autos. Reste ces lenteurs inexplicables (alors que c'est OK via QuickConnect je rappelle alors que ça devrait être le contraire) Je viens de refaire à nouveau une connexion, entre le moment où je saisis le MdP et celui ou l'interface s'affiche sur le smartphone il ne se passe pas moins de 8mn, chrono en main.

J'ai laissé tourner la connexion drive et ça se termine par ça Dingue non?

De retour à la maison, et la redirection de port n'a pas sauté Et un test externe d'ouverture de port le démontre aussi: Confirmé par un "tcpdump port 6690" en session shell en live sur le NAS (je vois le traffic lors du test de port mais pas du rout lors de la connexion du client Drive)

Je vais vérifier ça dès que je suis de retour chez moi. Reste que ça me semble bizarre que seulement cette redirection soit impactée et pas 5001 par exemple. De plus si c'etait bien ça j'aurais reçu un refus immédiat ("connexion refused" ou similaire) et pas ce truc qui tourne en rond.

Bonjour, M'arrive soudain un truc étrange . Je ne peux plus connecter mon smartphone à mon NAS via Synology Drive en utilisant mon nom de domaine en https (ça tourne en rond sur "connexion en cours"). Ça marche en utilisant quickconnect par contre. Le plus étrange est que ça reste fonctionnel pour les autres applications synology, DS File par exemple. Je ne parviens pas à imaginer une explication à ce comportement.

Oh je n'avais pas fait gaffe à ça dans les releases notes 😮 Après, mon DS213j et ses 512MB semble quand même supporter.

Que se passe-t-il pour toi quand tu cliques sir le bouton "download" ?

Le support m'a donné ce lien pour mon modèle, ds213J : https://www.synology.com/en-global/support/download/DS213j?version=7.0#system Je simplement téléchargé le .pat et lancé upgrade tour simplement. Je ne suis étonné que ce soit impossible

Faite hier pour ma part, manuellement à la demande du support dans le cadre d'un ticket en cours. J'espère ne rien avoir cassé.

ah bon? Le minimum ne serait il pas d'avoir au moins un message d'erreur explicite ? Sans oublier que ça rend caduque l'option de mise à jour automatique aussi.