CoolRaoul

Plus "natif" d'un coté que de l'autre quand même ... Si c'est uniquement disponible de base sous Windows 7 Intégrale, qui est quand même une version "elitiste" de Windows (ne serait ce que le tarif), le coté "natif" devient encore plus discutable. Je déduis donc que tu préconise d'utiliser de préférence NFS même pour les clients Windows. Je doute que cette approche fasse l'unanimité (on verra si d'autres intervenants viennent donner leur avis) Avec CIFS aussi, ne je pense donc pas que ce soit un avantage décisif.

Etonnant d'avoir titré "Connexion Ssh - Permission Denied" alors que l'échec que tu constates (tentative d'exécution d'un *répertoire*) n'a aucun rapport avec ssh Que tu veux dire par "accéder" au fichier? Le lire ou le modifier? Dans les deux cas, , mieux vaut que tu utilise le package "config file editor" (me souviens plus trop ou le trouver mais on en parle sur le forum), parque tu donnes l'impression de ne pas maîtriser pleinement la ligne de commande sous unix, et connecté en shell sous root , une simple faute de frappe pourrait provoquer une catastrophe.

C'est ce que je dis toujours mais il n'est pas question de Linux dans ce fil jusqu'ici (je cite "Je suis sous windows 7") D'autant plus qu'entre temps, j'ai un peu cherché et il me semble bien que NFS client ne soit pas vraiment un composant de base sous Windows.

Il y avait mieux, en deux mots seulement : "host 192.168.0.2" , quoique tant qu'a tout capturer, autant ne pas mettre de filtre du tout. 800 paquets seulement c'est peut être pas suffisant, d'autant que tu captures là *tout* le traffic entrant et sortant du NAS (pourquoi ne pas s'etre limité au traffic NAS <-> imprimante puisque c'est celui que tu te cherches à analyser?) (c'était pas besoin de flouter les addresses MAC) Doit manquer des choses plus loin comme je l'ai dit, si la Canon fait une requête ARP c'est pour connaitre l’adresse MAC de la machine d'IP 192.168.0.2 (le syno), et pour engager des échanges TCP par la suite. Hors, ces derniers n'apparaissent pas sur ta capture. En quoi c'est étonnant? Si on connait comment fonctionne et à quoi sert le protocole ARP il n'y a pas de raison de s'étonner, et dans le cas contraire ... ben ... encore moins! Voir ici: http://fr.wikipedia.org/wiki/Address_Resolution_Protocol L'IP où doit être envoyée la réponse figure dans la requête (192.168.0.254) donc facile de savoir si c'est la BBOX. Apparemment l'erreur FCS n'a pas de conséquence puisque le Syno répond à la question juste après. Sinon, une petite analogie pour te montrer que tu ne cibles pas ce qu'il faut: quand les RG ont mis quelqu'un sur écoute, si cette personne appelle les renseignements pour avoir le numéro d'un correspondant, il est probable qu'elle va joindre ce correspondant peu après. L'enregistrement de conversation que les RG vont étudier, à ton avis, c'est celui avec les moustachus de toutouyoutou (équivalent de l'échange ARP donc) ou le suivant? Et bien la c'est pareil; ce qui pourrait éventuellement donner des pistes, c'est le trafic TCP (et UDP si y en a) entre la canon et la syno, pas les trames de service type ARP. Mais, de toutes façons, tu devrais éviter de focaliser sur les trames ARP : comme j'ai expliqué, il s'agit d'un protocole de bas niveau qui sert à la gestion des tables d’adresses MAC <> TCP. Lorsqu'on en voit dans la capture, c'est que la machine source s’apprête à faire des échanges IP avec une machine dont elle a "oublié" l’adresse MAC (explication ici) Ce qui peut éventuellement être intéressant est le contenu de ces échanges qui vont forcément, pas le dialogue ARP lui-même. Et surtout, aucun risque que ce dialogue-ci ait le moindre impact sur l'hibernation des disques, tu peut en être sur. Si tu es bien sur de la totale corrélation avec le fait que l'imprimante soit active , c'est qu'elle doit provoquer de façon indirecte une l'activité disque sur le NAS. C'est de ce coté qu'il s'agirait de creuser. Ne pas aussi laisser de coté l'éventualité que l'état sous tension de l'imprimante ne soit qu'une condition *nécessaire* (mais pas forcément *suffisante*) pour empêcher l'hibernation et que ce soit en fait une interaction Canon <-> équipement réseau tiers qui provoque l'effet observé.

Dingue ça, je ne savais même pas que Windows 7 faisait client NFS! Mais, quel est lintérêt, d'utiliser NFS sous Windows au lieu de CIFS qui est quand même le protocole "natif" chez Microsoft.

C'est pas suffisant, va te falloir aussi installer sur le NAS tcpdump, et donc optware (ipkg) Tu est en train de commencer à dérouler un sacré plat de spaghetti la ...

J'ai oublié de dire que si tu utilise wireshark sur ton PC, bien entendu, tu ne pourras pas visualiser les trames entre le NAS et la Canon en dehors des brodcasts. Pour cela, pas d'autre solution de passer par tcpdump en ligne de commande sur le NAS: tcpdump -s 0 -w capture.cap "(src host 192.168.0.2 and dst host 192.168.0.95) or (src host 192.168.0.95 and dst host 192.168.0.2)" (sous réserve que 192.168.0.2 et 192.168.0.95 soient bien les IPs respectives du NAS et de l'imprimante) Ensuite tu charges le fichier "capture.cap" dans wireshark pour l'analyser ***EDIT*** plus simple pour le filtre de capture (pas bien réveillé ce matin): tcpdump -s 0 -w capture.cap host 192.168.0.95 Au temps pour moi, je les ai aussi.

D'après ce que je constate, ton filtre (quel est-il?) sélectionne uniquement les trames émises par le NAS et les broadcasts, on ne voit pas tout ce que le NAS reçoit. Pour avancer, serait intéressant de voir l'intégralité du dialogue entre l'imprimante et le NAS. La trame ARP indique que l'imprimante s’apprête à communiquer avec le NAS (192.168.0.2) et qu'elle a besoin de connaitre l'adresse MAC correspondante. Pourtant le dialogue qui s'ensuit napparaît pas. Personnellement je ne constate pas ces broadcasts "host announcement", ils doit s'agir d'une réponse à une requête de l'imprimante, cette dernière étant passée à travers les mailles de ton filtre de capture.

J'ai franchement des doutes sur le fait que la requête ARP de la canon empêche le NAS de faire hiberner ses disques, d'autant plus que chronologiquement, c'est lui qui commence par émettre un broadcast N'aurais-tu pas plutôt laissé activé sur le NAS la fonction "master browser", qui comme l'indique la doc empêche justement l'hibernation? Sinon, au sujet de l'hibernation des disques, les spécialistes la déconseillent en général si on ne veut pas diminuer la durée de vie. Tu trouvera des fils de discussion sur le sujet dans le forum.

Commencer par faire le test avec la config ftp "dans l"état", on verra ensuite

Cette fonctionnalité est évoquée dans mon :

Oui Non toutafé, et on est la pour t'aider en cas de problèmes (alors que xnames.org, pas sur d'avoir encore compris à le concept ) Pas besoin de supprimer le compte, suffit de ne pas l'utiliser.. Chez moi,avec cette méthode, ça le fait ...

A moins (et c'est possible) que je ne comprenne pas toutes les subtilités, synology.me accepte automatiquement les sous-domaines, pas besoin de bidouille complexe Des que "tondomaine.synology.me" est enregistré, "machin.tondomaine.synology.me", "truc.tondomaine.synology.me", "sous.truc.tondomaine.synology.me", etc ... sont acceptés sans broncher et résolus avec ton IP (ce qui est loin d'être me cas avec les autres fournisseurs de DDNS gratuits) Tu as ainsi virtuellement accès à une infinité de sous-domaines et plus besoin d'utiliser no-ip ni xnames.org (connaissait pas celui-la). L'inconvénient est que si tu change de crèmerie (de Synology à un autre fournisseur de NAS), tu n’auras plus accès à synology.me (peut-être que est-ce cela qui te gène?)

DSM permet de régler les droits individuellement sur les sous-dossiers et fichiers contenu dans un dossier partagé. Par défaut les droits sont gérés "à la unix" (lecture/écriture/exécution pour propriétaire/groupe/autres) Et pour un contrôle encore plus fin il est aussi possible d'activer le support des ACL (administrables depuis un client Windows dans l'explorateur ou via FileStation)

Tiens tu me fait penser que, j'avais activé son option dl'historique. Comme j'en ai pas besoin, on va voir si les messages disparaissent après l'avoir désactivé.

Et ça filtrait les pings ???

Commencer alors par simplement désactiver le firewall du NAS (bien que le filtrage ICMP ne fasse pas partie des options accessible par l'interface DSM) N'aurais-tu pas un firewall mal configuré sur ton Linux? Sinon, on peut aussi investiguer coté câblage , quoique , vu les problemes qui tu décris je ne comprend pas que tu arrives à "administrer le nas depuis l'interface web", ou alors tu utilise un autre poste que ton linux pour ça (mais tu nous l'aurais dit évidemment). Faudra nous expliquer ce que tu veux dire par la (le NAS qui *reconnait* la freebox ???)

Est-qu'il sait lire des videos situés sur un partage samba ou NFS ?

Pourquoi pas envoyer balader no-ip et leur contraintes à la c** (qu'est-ce que ça peut bien leur faire que ton IP ne change pas pendant plus d'un mois?) et utiliser le service DDNS synology à la place ?

http://tizzbird.fr/images/stories/logos_articles/tizzbird/FICHES_TECHNIQUES/tizzbird_f20.pdf Processeur : TCC8801 - Cortex A8 - 1 Ghz - Mémoire : principale 512MB (RAM) / 2 GB (NAND) OS : Androïd 2.3 (gingerbread) EVOLUTIF - Interface : OPEN GL 3D - Taille et format du disque dur : 2,5’’ SATA jusqu’à 2 To - Langues : 38 langues disponibles dont : Français, Anglais, Allemand, Espagnol - Taille : 155x155x30 mm - Poids : 480 g

Je viens aussi de m'apercevoir que c'est par vagues... Ça vient de s’arrêter aussi la d'ailleurs

Super, je crois que cet argumentaire approfondi m'a convaincu Sérieusement, saurais-tu nous proposer des liens sur des tests ou comparatifs, des témoignages utilisateurs? **EDIT** Un truc me chiffonne déja: Android 2.3, bof.

Bonjour, Je viens de m'apercevoir que toutes les 30 secondes, j'avais les deux messages suivants dans /var/log/messages: Apr 11 14:06:14 synosnmpcd: snmp_oid_class.cpp:131 Invaild Argument (__null == _pOIDGet)=[0] Apr 11 14:06:14 synosnmpcd: snmp_object_class.cpp:381 Error: Cannot parse OID Je souhaiterai savoir si d'autres que moi peuvent observer ce comportement, histoire de déterminer si c'est ma config qui est en cause ou un bug de la 4.2. NB: je redémarre synosnmpcd quotidiennement, par le gestionnaire de tache, avec la commande suivante pour contourner le problème "Resource Monitor - Connection failed" discuté ici, peut-être est-ce lié /usr/syno/etc.defaults/rc.d/S96synosnmpcd.sh restart

Je vais essayer d'apporter un peu de précision au ce sujet qui, dans un passé récent, m'a semblé pouvoir provoquer certaines polémiques. Il est important de bien distinguer "contenu" et "contenant". Pour faire une analogie dans la vie réelle, pour cacher à la vue de certaines personnes qu'un objet existe, ce n'est pas en agissant sur l'objet lui-même qu'on va y parvenir (le spray d'invisibilité n'a pas encore été inventé), la méthode qui convient est de dissimuler l'objet en le plaçant *a l'intérieur* d'un *autre* objet dont le contenu (disons l'entrée) n'est accessible qu'aux personnes autorisées (comme on coffre dont on a ou pas la combinaison). Dans le cas de dossiers ou de fichiers c'est équivalent: pour cacher (rendre invisible) la présence d'un fichier ou d'un dossier, il n'y en général pas de méthode efficace passant par la modification des attributs du fichier ou dossier lui-même. Comme dans la vie réelle, il faut déplacer le fichier/dossier dans un dossier (père) dont on va contrôler laccès (avec les droits user/groupe/autres ou les acl si on veut faire plus fin) Donc, même si DSM offre des options pour masquer la présence de dossier/fichiers aux utilisateur non autorisés, il ne faut pas trop s'appuyer sur cette possibilité car elle dépend exclusivement d'une fonctionnalité de Samba et ne s'applique donc pas aux autres méthodes de partage.

Les dossiers "partagés" et les sous dossiers sont traités différement. Les premiers ne sont visibles que par les utilisateurs qui y ont effectivement acces *sauf* dans le cas d'un acces en mode partage réseau CIFS (voisinage réseau d'un poste windows par exemple) ou ils sont tous visible (mas bien entendu si on n'a pas l'acces il est impossible d'en voir le contenu). Toujours en mode SMB/CIFF il est aussi possible de rendre chaque partage indivuellement invisible (sera toujours possible d'y accéder en connaissant son chemin) Les sous-dossiers sont en général visible par tout le monde (sous réserve bien entendu d’avoir accès en lecture au dossier père). Il existe cependant une option permettant de les rendre invisibles, mais à l'inverse du cas précédent, cette option ne s'applique qu'aux acces CIFS. En général le concept de "dossier caché" est rarement implémenté par les systèmes d’explorations courant. Si on veut effectivement rendre invisible des objets (fichiers ou dossiers) le mieux est d'utiliser un dossier intermédiaire, contenant le (ou les) dossier(s) à masquer, et dont on ajuste les droits pour en autoriser la lecture uniquement aux personnes autorisés. Panneau de configuration -> Notification (mais attention, ni Free ni Sosh n'ont, à ma connaissance d'API d'envoi de SMS via le réseau). Le mieux est d'installer le client DS Finder sur le smartphone, de le lier avec le syno et le téléphone recevra les notifications en mode push (si il est connecté à internet). Bien entendu, suffit de configurer les ouvertures de ports dans la box/le routeur et le NAS sera accessible, sur les ports sélectionnés, à partir d'internet y compris un mobile. oui: panneau de conf -> matériel -> Planif Alim On trouve pas mal de didacticiels en ligne sur le site synology déja. Sinon le bon point de départ est simplement la doc PDF (dispo en ligne aussi) en complément du guide d'installation rapide: http://www.synology.com/support/download.php?lang=fre&b=2%20bays&m=DS213 Pour ma part je l'utilise comme cible de backup du disque1, pour stoquer des données dont la perte m'importe peu (logs), et cible time machine aussi.