Rbatimus

oui test avec les nouvelles ram et si cela ne fonctionne pas, tu ne pourras pas aller beaucoup plus loin sans avoir accès au boot log via l'UART. Une société professionelle feront face au même difficultés que toi (sans le schéma pas de dépannage complexe possible) et malheureusement Synology ne fournissent pas ce genre d'informations... Pas con les mecs... Ou alors tu parle d'une société pour le reflow? oublie cela va te couter une blinde par raport à un NAS neuf... pour le reflow sur du BGA à la souflette je suis sceptique du résultat. Tu dois blinder de flux thermique pour y arriver?

Bon après au vus du prix d'un ds218play neuf j'espère que tu fais ce dépannage par passion et curiosité intelectuelle ^^.

ça m'aurais étonné aussi, les quartz sont des composants relativement peu solicités... c'est pourquoi je te poussais à trouver les pin UART pour visulaiser le Log (mais mission quasi impossible sans le schéma correct). le CPU chauffe-il un peu tout de même ou reste il complétement froid? tu change les deux ram j'imagine? je vois que c'est des BGA... tu à le matos pour les déposer sans abimer le pcb? J'espère pour toi que le système d'alimentation dédié aux mémoires n'est pas endomagé également une fois les rams dessoudée je t'inviterais à les controller avant de monter et bruler tes nouvelle ram ;). avec ton outillage limité ça risque d'être un dépannage plutot difficile à réaliser, je te souhaite bien du courage.

Ok je me demandais comment tu avais fais pour te procurer ce schéma justement...

@Cristaux66 ok si une fois que tu as changé les quartz cela ne fonctionne toujours pas je serais toi je tenterais de visualiser le log de boot du cpu... avant de le changer histoire de m'assurer que ce n'est pas un soucis au niveau des mémoires flash ou ram qui empèche le boot. Pour cela je vois qu'il y a des résistance sur le signal UART1 que tu peu utiliser pour te brancher... Bref tiens nous au courant 😉

Concernant la bande passante de ton oscilloscope on dit en générale qu'il doit être de 5x le signal d'intérêt donc pour toi entre 150 et et 200 MHz pour voir un signal propre... mais si tu es à 50MHz tu devrais tout de même vois un pseudo signal pas très beau... si c'est le calme plats ton quartz est probablement mort..

Salut @Cristaux66, je suis également électronicien à la base et maintenant, je conçois ce genre de carte électronique. ce genre de panne m'est déja arrivée quelque fois. les quartz sont connecté et stimulé directement par le CPU donc dans ton cas il serait bien de pouvoir établire si tu as déja une tension continue sur ta pin de X1. un oscilloscope avec une bande passante suffisante devrait être capable de voir l'oscilation quelle est la bande passante du tiens? si pas d'oscilation alors qu'une tension continue est présente, je te recommande de changer le quartz en premier... en gros soit le quartz est mort soit le CPU... c'est pas sorcier ^^. Une petite astuce pour voir si le CPU boot tu devrais pouvoir le voir à la différence de consomation entre une carte fonctionelle et non fonctionelle... ça peut également aider à cerner le problème (mais je me doute bien que tu ne dois pas avoir cela sous la main même en "prêt"). Sinon version plus technique tu peux te connecter au pin UR1-RX, UR1-Tx sur la carte avec un serial converter RS232-USB et ouvrir un terminal. lors du boot tu devrais voir apparaitre le log de boot... Bon courage pour ton dépannage.

@klicer c'est normal l'image xteve n'est plus maintenue par linuxserver. Ce tuto doit donc être remis à jour. Tu trouveras une image xteve chez dnsforge par exemple avec la documentation relative

Bienvenue, Salutations depuis la Suisse également 😉

@lordkivan je viens de vérifier mais hélas coté switch c'est pas la joie niveaux parmètre pour le LAG... en gros on peut juste créer un groupe entre plusieurs port phyique sur ce model de switche ça m'apprendra à prendre les entrée de gamme ^^. @church tu m'a mis sur la bonne piste merci c'est effectivement le mode Balance Xor qui fonctionne pour ma config... En addition à ce poste et afin de conclure, comme ces AP sont basé sur une architecture SDN comme mentionné plus haut je me suis amusé à créer un Omada Controller sur mon NAS via Docker et ça fonctionne plutôt pas mal... gestion du réseau centralisée, mise à jour automatique des différents firmware etc... ça serait à refaire je choisirais les mêmes AP mais un switch moins cheap compatible Omada controller ainsi qu'un router ça simplifierais beaucoup la gestion de mon réseau... Donc pas forcément nécessaire pour une petit réseau comme le mien mais indispensable pour les PME 😉

La suppression du LAG a résolu le problème... mais cela ne fais pas mes affaires étant donné que je souhaitais le conserver... c'était un Link Aggregation Dynamique IEEE 802.3ad avec config de l'IP manuelle. coté Switch j'ai simplement créer le lien dans Switching->LAG et selectionnée les deux port physique et créer LAG1... Bref j'ai du louper qqch coté switch probablement pour que cela fonctionne partout...

j'ai également ouvert un topic sur le Forum TP-Link concernant les access point Omada.. on verra qui de NAS forum ou T-Plink fournira la solution en premier ^^.

@lordkivan, je n'ai pas accès à mon AP pour l'instant mais je vérifierais ce soir. Je t'avoue que pour le moment je n'ai pas beaucoup dévié de la configuration par défaut des acces point mis a part le changement des addresse IP en statique et des login/WP... donc rien de fous de ce coté je crains, mais je vais passer cette config au crible et publierais ma config si je ne trouve rien... Par contre en effet je vais vérifier cette histoire de device insulatation. Je vais également tester de suprimer le LAG pour voir si le problème peut venir de la... @churchdu coup comme tu t'en doute pas de VLAN actif et mon switch est manageable (TL-SG1016PE), coté NAS j'ai fais un lag dynamique avec configuration de l'adresse IP manuelle selon le schéma et coté switch j'ai simplement créer un LAG sur les deux port physique utilisé. je peux y acceder via l'interface web et je peux le ping sur le reseau du router mais pas sur celui des AP. ce n'est pas lié à un seul PC mais à l'ensemble de mes appareils connectés (Test avec tablette, smartphone, laptop et fixe, le résultats est le même partout c'est donc lié à ma config réseau...) Je ne fais pas de partage SAMBA avec... Quoique il en soit merci pour vos retour et feedback qui m'aide à trouver du grain a moudre en attendant de trouver la solution ^^.

voici les Config IP de mon réseau Local: comme tu peux le voir tout est sur le même sub-net... sur mon NAS j'ai uniquement un serveur VPN actif pour les connexion venant de l'extérieur... donc pas de client j'ai tenté de desactiver le parfeu du NAS de supprimer les protection des comptes etc... rien ni fait j'ai accès a tout mon réseau depuis les AP sauf au NAS.... j'avoue que je sèche un peu...

j'ai tenté de désactiver le par feu du NAS mais toujours sans résultat

Salut à tous, Je viens de modifier mon réseau privé avec l'ajout de deux Access Point TPlink Omada. Voir ci-dessous la configuration de mon réseau: Tout semble fonctionner excepté l'accès à mon NAS... en effet une fois connecté à mon AP j'ai pu ping les différents appareils de mon réseau local sauf le NAS... par contre si je me connecte au Wifi du routeur directement, la j'ai accès sans soucis à mon NAS... Mon NAS est en IP Fixe avec un LAG (LAN1 & 2) Actif & fonctionnel sur le switch Avez-vous une peut-être une idée de piste à explorer? Merci d'avance pour votre aide.

Bravo les gars content que vous ayez une solution qui fonctionne 😉

Oui ton script semble correct... Voici le mien: #!/bin/bash umount /dev/usb1p1 sleep 10 echo "2-1.3" > /sys/bus/usb/drivers/usb/unbind je vois que tu as fais un copier-coller depuis le forum. Tu peux encore essayer d'effacer ton script et de le taper manuellement (Sans les commentaires) pour écarter l'ajout d'un caractère spécial dans le script...

@telenaze chez moi cela fonctionne parfaitement en tout cas. Es-tu certain d'avoir démonter la bonne partition? qu'es-ce que la commande df -h te retourne? Sinon tu peux essayer peut-être d'augmenter le temps entre le démontage de la partition et l'éjection du disque...

Petit addendum qui pourra s'avérer utile: la commande echo "1-2" > /sys/bus/usb/drivers/usb/unbind équivaut à retirer le câble USB du disque dure du NAS... ce qui nous vaut un joli message du system "le dique xxx n'a pas été éjecté correctement". Si on veut faire les choses proprement il faut alors démonter la partition système du disque avant de l'éjecter. Pour se faire il faut identifier le nom de la partition avec la commande: df -h par exemple: /dev/usb1p1 ce qui nous donne le scripte suivant pour éjecter proprement le disque: umount /dev/usb1p1 #démontage de la partition du disque sleep 10 #une pause de 10 secondes laisse le temps au système de finir le démontage de la partition echo "1-2" > /sys/bus/usb/drivers/usb/unbind #éjection du disque Après execution de ce script le message "le dique xxx n'a pas été éjecté correctement", n'apparaitra plus ce qui soulagera notre file de notification.

@telenaze, Je ne dirais pas que ta sauvegarde est maintenant protégée contre les ransomware. Ce serait faux de le dire car un attaquant qui se procurerais tes accès root du NAS serait capabale de remonter et d'infecter ta sauvgarde local. mais ce genre d'attaques à large échelle sont automatisés et ce qui sort d'un configuration généraliste sera plus difficilement attaquable... donc tant que ton disque n'est pas monté il sera théoriquement mieux protégé...

Salut @telenaze, Navré pour le délais de réponse, cela faisait un moment que je n'était pas repassé par le forum avec les fêtes. Je vois que dans l'intervalle tu as bien pu progresser sur ton script, bravo & merci pour tes retours qui seront utiles à d'autres! En effet, c'est bien vu de l'avoir signalé à l'équipe de dev Synology.

Ok problème résolu: pour monter les disques depuis ssh ils doivent être démonter en ssh aussi avant, cela même si ils on été éjecté proprement depuis DSM. sinon le montage ne fonctionne pas toujours... Ce qui implique d'avoir deux Scripts: l'un qui monte les diques: #!/bin/bash echo "2-1" > /sys/bus/usb/drivers/usb/bind et un autre qui les démontes: #!/bin/bash echo "2-1" > /sys/bus/usb/drivers/usb/unbind Je programme l' execution du script de démontage de mes disques 5 minutes avant l'execution du script de montage automatique. Le montage s'éxecute également 5 minutes avant leur utilisation par Hyper backup. Hyper backup se charge de les éjecter à la fin de la tâche de backup... ce qui fait que les disques sont monté uniquement durant leur temps d'utilisation +5 minutes... c'est pas très propre mais ça fait le job. Si quelqu'un à une meilleur idée je suis prenneur ;).

Bonjour à tous je cherche à créer un script afin d'automatiser le montage de mon disque USB de backup local. Ceci afin qu'il ne soit pas monté en permanence sur le NAS mais uniquement au moment de la sauvegarde et de m'éviter de fastidieuses connexion et reconnexion manuelle. Première question cela fait-il du sens de le faire (je laisse les experts en débattre)? De prime à bord, je tiens à préciser que ce disque de backup local n'est pas mon unique point de backup de mon NAS. Je vois donc déjà les "experts" me dire alors à quoi bon, surtout si les accès du NAS on été sécurisé, par exemple en suivant l'excellent tuto de fenrir sur le sujet... De mon point de vue, je vois cela comme une précaution supplémentaire ou une bonne pratique à mettre en place. En effet de cette manière je pourrais possiblement me rendre compte de l'attaque avant que mon disque usb de backup soit monté automatiquement et donc le déconnecter physiquement afin qu'il ne soit pas affecté par l'attaque. Je dis également moins sensibles car il y aura toujours moyen qu'on puisse y accéder. Mais cela complique la tâche de l'attaquant. Passons à la mise en pratique : Pour cela je compte utiliser la fonction d'éjection après la sauvegarde de hyper backup. Il ne me reste donc plus qu'à créer un script qui monte automatiquement mon disque dans le planificateur des tâches pour qu'il le monte 5 minutes avant la tâche de sauvegarde par exemple. Je me suis donc connecté en SSH via Putty à mon NAS (DSM7.1) avec 2 disques USB connectés dont l'un éjecté mais encore connecté. Ceci afin de localiser les répertoires des montages. Les répertoires d'intérêts localisés : /volume1 (c'est le volume de donnée du NAS ou sont sauver les dossiers partager par exemple) /volumeUSB1 (c'est le répertoire principal du disque USB connecté mais éjecté) /volumeUSB1/@eaDir /volumeUSB2 (c'est le répertoire principal du disque USB connecté et monter) /volumeUSB2/@eaDir /volumeUSB2/usbshare (répertoire de montage du disque USB) j'ai ensuite utilisé la commande lsusb pour détecter le matériel connecter en USB sur mon NAS 1d6b:0002:0404 09 2.00 480MBit/s 0mA 1IF (Linux 4.4.180+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub |__1-1 xxxx:xxxx:xxxx xx 2.10 480MBit/s 100mA 1IF (Seagate Backup+ Hub xxxxxxxxx) hub |__1-2 xxxx:xxxx:xxxx xxx 1.10 12MBit/s 20mA 1IF (EATON Eaton 5SC xxxxxxxxx) |__1-4 xxxx:xxxx:xxxx xx 2.00 480MBit/s 200mA 1IF (Synology Diskstation xxxxxxxxxx) |__usb2 xxxx:xxxx:xxxx xx 3.00 5000MBit/s 0mA 1IF (Linux 4.4.180+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub |__2-1 xxxx:xxxx:xxxx xx 3.00 5000MBit/s 0mA 1IF (Seagate Backup+ Hub xxxxxxxxxxx) hub |__2-1.1 xxxx:xxxx:xxxx xx 3.10 5000MBit/s 0mA 1IF (Seagate Backup+ Hub xxxxxxxxxxxx) |__2-1.2 xxxx:xxxx:xxxx xx 3.00 5000MBit/s 896mA 1IF (Intenso External USB 3.0 xxxxxxxxxxx) On voit ici que mes deux disques usb sont visibles sur les deux dernière lignes 2-1.1 (Disque monté), 2-1.2 (disque éjecté) On les retrouve également sous /sys/bus/usb/devices: 1-0:1.0 1-1 1-1:1.0 1-2 1-2:1.0 1-4 1-4:1.0 2-0:1.0 2-1 2-1.1 2-1:1.0 2-1.1:1.0 2-1.2 2-1.2:1.0 usb1 usb2 La commande sudo fdisk -l donnera plus de détails concernant les périphériques USB. Je ne vais pas afficher ici l'entier du retour mais uniquement les devices qui m’intéresse : USB 2-1.1: Disk /dev/usb1: 7.3 TiB, 8001563221504 bytes, 15628053167 sectors Disk model: Backup+ Hub BK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx Device Start End Sectors Size Type /dev/usb1p1 256 15628048064 15628047809 7.3T Linux filesystem USB 2-1.2: Disk /dev/usb3: 3.7 TiB, 4000787030016 bytes, 976754646 sectors Disk model: External USB 3.0 Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: xxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx Device Start End Sectors Size Type /dev/usb3p1 32 976751999 976751968 3.7T Linux filesystem Ces identifiant sont également visibles sous /dev Avec ces différentes commandes on a donc bien pu vérifier que mon disque éjecté mais connecté physiquement au NAS est bien visible dans le system d'exploitation bien que son contenu ne soit pas accessible. Pour le rendre accessible, il va falloir le monter dans /volumeUSB1 de la même manière que son homologue /volumeUSB2 Je vais donc créer un dossier usbshare dans volumeUSB1 avec la commande mkdir. sudo mkdir usbshare On peut aussi le supprimer avec la commande rmdir. sudo rmdir usbshare Puis le monter avec mount. sudo mount /dev/usb3p1 /volumeUSB1/usbshare Ou le démonter avec la commande umount. sudo umount usbshare Après cette commande le contenu de mon disque précédemment éjecté et disponible sous /volumeUSB1/usbshare le disque est donc monté... En revanche le disque n'est pas détecté comme monté dans DSM... J’ai essayé également de créer un dossier partager depuis DSM et de l'utiliser comme destination de montage pour mon disque USB et cela fonctionne (je peux voir le contenu du disque depuis le web GUI de DSM)... mais impossible de le sélectionner comme destination dans hyperbackup malheureusement. J’imagine donc qu'il faudra modifier un fichier quelque part afin de déclarer ce disque comme monter pour DSM. Mais je n'ai pas encore trouvé la solution. Du reste si quelque à cette information je la prends volontiers avec tous mes remerciements. P.S: j'ai également esssayer la commande: echo "2-1.2" > /sys/bus/usb/drivers/usb/bind -ash: echo: write error: No such device bien que 2-1.2 soit bien visible sous /sys/bus/usb/drivers/usb ...

@shad oui j'imaginais exactement partir sur une solution Jeedom mais basé peut-être sur une VM plutot que Docker pour des questions d'accès périphériques plus simple mais je vais tout de même suivre ça avec intérêt 😉