CoolRaoul

Peut-être qu'il manque les redirections des ports 55536 à 55539 ... Et ça c'est pas bon, faut utiliser le port 21 pour la connexion!

En effet, oublié d'ajouter qu'il faut ajouter dans la box des redirections de ports alloués au ftp passif pour dans la config ftp du NAS

Commencer par désactiver le chiffrement (tu verras plus tard comment l'activer) et forcer le mode passif (onglet "parametres de transfert")

Dans ce cas, quelle que soit la méthode tu ne dépassera pas ce que ta ligne peut donner. 0,42Mbps => 0,042 MBytes => environ 43 KBytes / seconde Il n'y a pas de miracle. A la limite, en sftp (pas ftp hein!) tu pourrais bénéficier de la compression intégrée au protocole, mais si tes données sont déja compressés (cas des fichiers média images, audio et video) ça ne changera rien. Même en utilisant un NAS de compétition il n'y aurait aucune amélioration. **EDIT** Je ne peux que te conseiller d'éviter les protocoles "riches" (en terme d'infos échangés) comme webdav, et de privilégier ceux plus "rustiques" (ftp). Mais le mieux est de tester et de mesurer ce qui rend le mieux sur ta propre configuration. Par contre, l'utilisation ou non du WIFI a l'autre bout ne devrai pas avoir d'impact.

Si tu nous donnais les caractéristiques de ta ligne ADSL? (à mesurer sur un site de test de débit) Le goulot d'étranglement est tres probablement la!

Enfin, on est quand même dans des chiffres de l'ordre de 30MB par seconde (env 300Mbits donc) , ceux qui disposent d'une ligne ADSL avec une telle bande passante ne doivent pas courir les rues.

Dans tout les cas, en accès distant, ne pas oublier que les performances en terme de vitesse de transfert seront limitées par la capacité en débit sortant de ta ligne adsl (qui est typiquement une fraction de ton débit entrant)

Dans mon exemple, les caracteres '<' et '>' ne sont pas a conserver! C'est une convention d'écriture pour identifier les parties qui doivent être remplacées dans la commande pour l'exécuter. C'est comme si j'avais écrit echo "<votre nom ici>" qui doit donc devenir: echo "FabriceC" et pas echo "<FabriceC>" voila...

Ce n'est pas la faute du NAS mais du protocole de browsing réseau SMB, hérité de lan manager qui est foireux. Déja évoqué ici:

C'est pas très clair (pour moi) ce que tu entends par "joindre le NAS" En outre je t'ai demandé de faire une manip via l'explorateur windows, et tu ne nous dis pas ce que ça a donné: pourquoi? (avec le message d'erreur éventuel *exact* stp!) As-tu essayé de connecter le lecteur réseau en utilisant l'IP du NAS plutôt que son nom également?

Je ne serais pas aussi catégorique: il peut se révéler utile dans certains cas, comme par exemple pour restreindre l'acces a certaines plages d'IP spécifiques dans le cas de services dont le port a été redirigé sur la freebox.

Essayer une connexion avec l’adresse IP du NAS plutôt que son nom (par exemple dans la barre d’adresse de l'explorateur, saisir "n.p.q.r" , "n.p.q.r" correspondant a l'ip du NAS Le résultat de ce test pourra suggérer des pistes de résolution.

Me semble que les Syno peuvent être configurés pour assurer la fonction routeur. Et donc, en configurant son modem/routeur (ou sa box) en mode "bridge" on est capable de reproduire l'architecture que tu décrit. Bien entendu le syno ne fait pas modem, le modem/routeur continue à assurer ce rôle tout en se retrouvant déchargé de la fonction routeur

En ayant activé l'agent SNMP de DSM, il devient possible d'utiliser un n'importque quel logiciel de monitoring/métrologie s'appuyant sur ce protocole (comme l'exemple de cacti sonné ci dessus). En outre ce dernier n'a pas besoin de tourner directement sur le synology. Ce qui te donnerait l’accès à des métriques bien plus fines Par contre les métriques réseau individuelles par utilisateur je pense qu'il ne faut pas trop espérer: les métriques tcp sont relevées au niveau des modules réseau et remontés par le kernel (accessibles via le filesystem "/proc") et au niveau où ces compteurs sont tenus à jour, aucune corrélation avec l'utilisateur ne me semble possible. Faut aussi bien garder a l'idée qu'il faut alors d'abandonner toute idée de mise en veille du NAS (même sans aller jusqu'à l'hibernation des disques, ce qui est déconseillé) puisqu'il va être régulièrement sollicité pour répondre aux demandes de métriques. Va falloir accepter des petits pics de consommation cpu (bien que très légers), à chaque cycle de métrique, Cela pourrait avoir pour conséquence d'empécher le NAS de se mettre en mode basse consommation (ce dernier point sous réserve de confirmation par plus spécialiste que moi )

C'est le cas pour moi: tous les noms de sites d'IP dynamiques sont bloqués.

Oui, Adblock mais nas-forum est dans ma white list (je ne veux pas faire perdre des revenus publicitaires aux admins ) A noter que le problème a disparu pour le moment!

Pas trouvé l'option à modifier dans les préférences du forum Ce n'est pas la: http://www.nas-forum.com/forum/index.php?app=core&module=usercp ?

Moi aussi j'ai adblock (pensé tout de suite a lui), mais je l'avais désactivé pour nas-forum. Peut-être une autre plug-in Mais comme Bud retrouve à aussi cet en-tete et n'a que adblock .... Je suis sous chrome configuré comme ceci: donc je n'ai pas "en" en premier non?

Damned, les symptomes ont disparu et le facebook dans l'en-tête aussi N'ayant pas fermé la fenetre, voici un screenshot Typiquement un probleme d'encodage (mismatch ansi vs utf8) Ici on est bardé d'antivirus et de filtres dans tous les sens, je ne vois pas ce qui a pu causer ce truc!

Je pense que ca serait plus simple et sans risque. étonnant de n'avoir rien trouvé dans la log avec le grep... Le ssh natif de DSM accepte les connexions sur le compte root en utilisant le mot de passe du compte admin (ou bien entendu par clé) Si tu veux essayer effectue les opérations dans cet ordre déinstaller le openssh optware ("ipkg remove openssh") activer le ssh dsm via le panneau de configuration (ne devrait pas être activé, si c'est le cas d'abord le désactiver et ensuite le reactiver) (je ne pense pas qu'un reboot soit nécessaire)

L'en-tete des pages du forum ressemble à <!DOCTYPE html> <html lang="en" xmlns:fb="http://www.facebook.com/2008/fbml"> <head> Le probleme est que lorsque je me connecte a partir de mon taff, je suis derrière un proxy qui bloque facebook.com (ce qui ne me pose pas le moindre probleme, bien au contraire) Par contre je remarque pas mal de problèmes d'affichages (balises qui apparraissent dans les messages, problemee d'encodage utf8). Je me demande si il n'y aurait pas un lien entre les deux?

Si tu penses utiliser le openssh d'optware (AKA ipkg) et que les connexions ssh ne marchent autant le désinstaller alors non? Sinon je n'ai pas vu la réponse a mes autres questions ca c'est sans importance

Pour le "officiellement supporté", c'est ton interprétation... Je ne m'avancerai pas trop pour utiliser ce genre d'argument face au support Synology.. Et d'ailleurs, tout le monde te confirmera que l'on pouvait déja se connecter auparavant en root sans avoir à modifier le sshd_config.

Pas normal, quel est le message d'erreur? Tu utilises bien le ssh intégré à DSM et pas un ssh alternatif au moins? Sinon, en étant connecté telnet essaie de chercher dans la log comme ceci: grep sshd /var/log/messages Ca pourrait donner une piste

Mouais.. une trace d'option laissé en commentaire dans le contenu d'un fichier de configuration ne peut pas être considéré comme une doc officielle. Synology a conservé une bonne partie des commentaires du sshd_config contenu dans la distrib OpenSSH utilisée comme base de leur propre implémentation Ce n'est pas pour cela qu'il faut en conclure que leur version du serveur gère toutes les options. D'autre part, le compte root a toujours pu se connecter en ssh sur DSM (et meme plus, par défaut *seul* le compte root peut se connecter en ssh)