Hibernation Dd Empechee Par Trame Arp

[CeMi]

Bonsoir

J'ai un DS212J avec DSM 4.2.

Le DD ne passait plus en hibernation.

J'ai donc analysé la trafic de mon NAS et j'ai trouvé la trame qui empêche l'hibernation :

Il s'agit de la séquence suivante (entourée en rouge dans le log ci-dessous) :

-> Le NAS (192.168.0.2) émet une trame NBNS a tout le monde (192.168.0.255)

-> L'imprimante Canon répond par une séquence ARP, et déclenche probablement une action dans le NAS qui empèche l'hibernation ..

En tout cas, si je mets l'imprimante OFF, l'hibernation fonctionne (dans ce cas, dans le log on voit bien la trame NBNS mais plus la trame ARP).

J'en déduis que c'est la réponse de l'imprimante (Trame ARP) qui empêche l'hibernation

J'ai donc 3 solutions pour que le NAS passe en hibernation :

-> Je mets l'imprimante OFF entre 2 utilisations

(c'est pas génial, car elle met une plombe à se rallumer)

-> J'évite que l'imprimante émette la trame ARP en réaction à la trame NBNS du NAS

mais ça, je ne sais pas faire...

-> J'évite que le NAS émette la trame NBNS qui provoque la trame ARP de l'imprimante..

Je crois avoir compris que cette trame est liée à Samba.

Pour l'éviter j'ai donc désactivé la fonction "Windows File Service" dans Win/Mac/NFS.

ça marche aussi, l'hibernation fonctionne.

Le problème est que dans ce cas, je ne peux plus accéder au NAS à partir des PC du réseau directement de Windows (j'ai monté des lecteurs virtuels)

Avez vous une idée, svp ?

Merci d'avance

[CoolRaoul]

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.

[CeMi]

Merci de ta réponse CoolRaoul

Oui, j'ai lu ces fils de discussion sur la pertinence de faire hiberner les DD ou pas. Les points de vue sont assez mitigés et je n'arrive pas à me faire une idée bien claire.

Je vais creuser, ça dépend probablement des DD utilisés. Moi j'utilise des WD Red.

Pour ce qui est de la raison de la non hibernation dans mon cas :

A la suite de ta réponse, je viens de vérifier la case "Local Master Browser" . Elle est bien décochée.

Quand j'éteins l'imprimante l'hibernation marche bien.

Dans ce cas, dans le log on voit les mêmes trames (Browser, SSDP, y compris la trame NBNS broadcastée par le NAS) à l'exception bien sur le la trame ARP générée par l'imprimante (puisqu'elle est OFF).

Et dans ce cas, le NAS hiberne.

La seule différence dans le log étant la trame ARP, broadcastée par l'imprimante, j'en déduis que c'est la cause de la non hibernation.

Nota : j'ai fait le LOG avec Wireshark en filtrant les trames émises et reçues par le NAS (192.168.0.2)

Comment pourrais-je faire pour éviter que la trame NBNS soit émise par le NAS, tout en gardant le service d'accès au fichiers depuis les PC sous windows au moyen de lecteurs montés.

(j'ai mis mes albums photos sur Z:/ , mes videos sur X:/, ma musique sur Y:/, etc...)

Merci encore

[CoolRaoul]

Nota : j'ai fait le LOG avec Wireshark en filtrant les trames émises et reçues par le NAS (192.168.0.2)

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.

Modifié le 13 avril 2013 par CoolRaoul

[CoolRaoul]

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

Personnellement je ne constate pas ces broadcasts "host announcement",

Au temps pour moi, je les ai aussi. Modifié le 13 avril 2013 par CoolRaoul

[CeMi]

C'est vrai que je ne suis pas du tout un spécialiste de wireshark ni de réseaux.

Je l'ai téléchargé et utilisé pour la 1ère fois pour comprendre pourquoi de l'hibernation marchait de façon aléatoire, selon des posts sur une autre forum.

(je pensais au départ que ça venait du routeur de la Box que j'ai récemment changée)

Mon filtre est : host 192.168.0.2, mais si en effet on ne voit que les trames broadcast.. c'est pas top.

Pourtant dans le log plus haut on voit aussi l'adresse 239.255.255.250. et la 224.0.0.251..

Je vais essayer de ce pas la manip avec tcpdump.

La non plus, je ne suis pas un spécialiste, (Linux, je ne connais pas) mais j'ai cru voir quelque part que pour ce genre de manip il faut se logger dans le NAS avec hyperterminal en root

.. bon j'essaie..

Merci !

[CoolRaoul]

Je vais essayer de ce pas la manip avec tcpdump.

La non plus, je ne suis pas un spécialiste, (Linux, je ne connais pas) mais j'ai cru voir quelque part que pour ce genre de manip il faut se logger dans le NAS avec hyperterminal en root

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 ...

Modifié le 13 avril 2013 par CoolRaoul

[CeMi]

Ce fut un peu le parcours du combattant..

Mais j'y suis arrivé.

J'ai fait la commande suivante : tcpdump -s 0 -c 800 -w capturez.cap "src host 192.168.0.2 or dst host 192.168.0.2"

Comme ça, j'ai eu tout ce qui entre et sort du NAS

j'ai trouvé la trame de l'imprimante et je l'ai isolée dans la capture.

la voici :

Ce qui est étonnant c'est que d'autres trames ARP sont émises suite à la requete NBNS en ligne 220.

-> Notamment en ligne 225 on voit le SamsungE (je pense que c'est la BBox) emettre la même sequence ARP.

Toutefois, les deux trames ARP sont differentes :

- La trame ARP de l'imprimante est en broadcast alors que celle du SamsungE est destinée au NAS

- la trame ARP de l'imprimante contient la mention "ETHERNET FRAME CHECK SEQUENCE INCORRECT", alors que celle du SamsungE, non.

Je n'ai pas trouvé des infos utiles sur le Flag "ETHERNET FRAME CHECK SEQUENCE INCORRECT"

Merci

Modifié le 13 avril 2013 par CeMi

[CoolRaoul]

J'ai fait la commande suivante : tcpdump -s 0 -c 800 -w capturez.cap "src host 192.168.0.2 or dst host 192.168.0.2"

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.

Comme ça, j'ai eu tout ce qui entre et sort du NAS

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?)

j'ai trouvé la trame de l'imprimante et je l'ai isolée dans la capture.

la voici :

(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.

Ce qui est étonnant c'est que d'autres trames ARP sont émises suite à la requete NBNS en ligne 220.

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

-> Notamment en ligne 225 on voit le SamsungE (je pense que c'est la BBox) emettre la même sequence ARP.

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.

Toutefois, les deux trames ARP sont differentes :

- La trame ARP de l'imprimante est en broadcast alors que celle du SamsungE est destinée au NAS

- la trame ARP de l'imprimante contient la mention "ETHERNET FRAME CHECK SEQUENCE INCORRECT", alors que celle du SamsungE, non.

Je n'ai pas trouvé des infos utiles sur le Flag "ETHERNET FRAME CHECK SEQUENCE INCORRECT"

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é.

Modifié le 13 avril 2013 par CoolRaoul

[CeMi]

Merci,

Ci dessous le log avec toutes les trames entre le NAS et l'imprimante.

[CoolRaoul]

Etrange ces réponse NBNS: ce sont des réponse a des requetes netbios "name query" venant du NAS, mais comme il s'agit de broadcasts les demandes napparaissent pas avec ton filtre et on ne voit que la réponse.

Je ne comprend pas pourquoi le NAS passe son temps à faire des requêtes de résolution du nom de l'imprimante

Je dois reconnaître aussi que les détails de Netbios me sont quasi totalement étrangers (suis allé faire des recherches pour comprendre avant de répondre)

En tout cas, ça m'étonnerait qu'on arriver à grand chose avec ces analyses de capture réseau.

[Brunchto]

tu n'as pas un partage de l'imprimante sur le nas?

[CeMi]

Etrange ces réponse NBNS: ce sont des réponse a des requetes netbios "name query" venant du NAS, mais comme il s'agit de broadcasts les demandes napparaissent pas avec ton filtre et on ne voit que la réponse.

Je ne comprend pas pourquoi le NAS passe son temps à faire des requêtes de résolution du nom de l'imprimante

Je dois reconnaître aussi que les détails de Netbios me sont quasi totalement étrangers (suis allé faire des recherches pour comprendre avant de répondre)

En tout cas, ça m'étonnerait qu'on arriver à grand chose avec ces analyses de capture réseau.

Tu as raison avec le filtre que j'ai utilisé pour ce log on ne voit pas les broadcasts.

Donc on ne voit pas la requete NBNS émise par le NAS qui initie l'échange.

Par contre on peut la voir dans le Log précédent (Ligne 220 surlignée en bleu)

Elle déclenche la réponse en ligne 3 du dernier log ainsi que des requetes ARP, comme celle q'on voit en ligne 1, entre autres.

Cette requete NBNS initiale, je peux l'éviter en désactivant le service de fichier windows dans Win/Mac/NFS.

Si je desactive cette option :

-> le NAS n'emet pas la requete NBNS en question

-> L'imprimante n'y repond pas et ne genere pas de trame ARP

-> le NAS hiberne ses DD

Mais je voudrais trouver une autre solution car dans ce cas, je n'ai plus accès au NAS depuis les PC sous windows.

tu n'as pas un partage de l'imprimante sur le nas?

Euh non..

L'imprimante est connectée en Wi-Fi directement sur le réseau.

[CoolRaoul]

Si je desactive cette option :

-> le NAS n'emet pas la requete NBNS en question

-> L'imprimante n'y repond pas et ne genere pas de trame ARP

-> le NAS hiberne ses DD

[CeMi]

Je vais essayer ça..

En effet, le NAS et l'imprimante n'ont pas à communiquer.

Je vais devoir mettre une adresse fixe à l'imprimante.

Merci encore de ton aide !

[CeMi]

Et bien, c'est cool !!

J'ai mis la regle dans le Firewall et ça marche..

Maintenant je peux laisser l'imprimante ON et le NAS hiberne ses DD

Grand merci..