Foksadure

J'arrive peut-être après la bataille, mais perso j'essaierais déjà d'évaluer la qualité du réseau WiFi sans les MR2200ac. Et effectivement aussi de se passer du CPL si une liaison cuivre ou WiFi peut être établie avec le RT6600ax. Ensuite, on peut regarder dans l'interface du SRM (ou avec l'application mobile) à quelle vitesse sont connectés les périphériques client, sur quel point d'accès, ainsi que la vitesse de liaison du lien technique entre les points d'accès. Couplé avec un utilitaire de test réseau comme Analiti ou iperf3, en remettant ensuite progressivement les MR2200ac en service, il doit y avoir moyen d'évaluer la qualité de l'ensemble à différent points de mesure ou d'identifier les zones à problème. Je me demande également si la cohabitation entre l'ancienne gamme WiFi5 et la nouvelle WiFi6 ne serait pas devenue problématique. On se souvient qu'à la sortie du RT6600ax il avait fallu attendre quelques temps que les RT2600ac et MR2200ac soient rendus compatibles Mesh avec la gamme WiFi6, et on ne peut pas dire que l'expérience se soit avérée fluide avec le SRM 1.3 depuis sur ces modèles, qui fonctionnaient très bien de conserve en SRM 1.2 & WiFi5. En tout cas sur ma modeste installation, avec le SRM en màj automatique, j'ai récemment rencontré de grosses instabilités et lenteurs avec un RT2600ac de Mesh depuis 2 ans avec le RT6600ax principal (en mode rocade WiFi, pas de câblage possible). Remplacer le premier par un WRX560 vient de résoudre tout cela. La section WiFi de l'interface d'administration du SRM est devenue beaucoup plus réactive et le WRX asservi démarre infiniment plus vite que le RT2600 dans la même situation, avec une liaison 5GHz qui s'établit à ~2Gbps entre les deux (débits mesurés > 110Mo/s, soit ~30% de gain). La surface à couvrir est très modeste mais le second routeur en Mesh permet d'alimenter des PC en GbE cuivre à l'étage, qui bénéficient donc de l'accès fibre et aux NAS à des débits encore plus respectables qu'auparavant. Edit : penser à stopper Threat Prevention si on en a pas l'usage.

On trouve sur LBC des référence Crucial en ECC qui fonctionnent. J'ai pris une unique 16Go, laquelle est bien suffisante combinée aux 8Go d'origine du DS1522+ pour faire un peu de virtualisation.

La question est surtout de savoir quelle est la qualité du lien uplink entre les deux RT6600ax, s'ils sont connecté en Wi-Fi. Et combien de clients sont connectés sur le second RT6600ax lorsque l'anomalie de débit survient. Tout cela à voir dans Wi-Fi Connect -> Point d'accès Wi-Fi. Je trouve que le Wi-Fi fonctionne beaucoup moins bien sous SRM 1.3, en tout cas sur la génération précédente (RT2600ac et MR2200ac). L'uplink n'utilise plus le réseau 5 GHz-2 dédié, mais partage celui - le 5 GHz-1 - également utilisé par les clients compatibles. Et en plus on a perdu le fonction de test de performance qui était intégrée au SRM 1.2 justement pour identifier les soucis à ce niveau : https://kb.synology.com/fr-fr/SRM/help/SRM/WiFiConnect/wifi_mesh?version=1_2#t3 J'espère qu'ils vont corriger le tir.

Bonjour, Je ravive ce fil pour confirmer que les IronWolf "grattent" comme des disques d'il y a 10 ans, ce qui peut s'avérer gênant dans un environnement domestique. J'utilise un DS412+ avec un panachage de disques 4To Seagate et WD, lié aux augmentation successives de capacité. Les WD40EFRX et WD40EFZX sont inaudibles. Les ST4000VN008 vibrent nettement plus et leur activité d'I/O sont très nettement remarquables en comparaison, surtout parce qu'elle provoquent des résonances du boitier (découplage très partiel des disques à cause de la platine SATA arrière). Par curiosité, l'idée m'a pris de remplacer un des Seagate VN008 par le nouveau modèle ST4000VN006, qu'on trouve à moins de 100 euros (5400tr/mn, 256Mo de cache, 2 plateaux, hauteur 20,20mm). https://www.seagate.com/www-content/product-content/ironwolf/en-us/docs/100807039m.pdf Avec les 256Mo de cache et l'augmentation de la densité, on pouvait craindre que Seagate nous ait fait un produit "de crise" en SMR déguisé, mais il n'y a pas de problème lors de la reconstruction de la grappe RAID contrairement aux WD40EFAX. Il semble bien être CMR (tel qu'indiqué ici et dans la liste de compatibilité Synology). Cependant, le ST4000VN006 n'est hélas pas plus silencieux que le ST4000VN008 tout en chauffant plus : 31°C vs 24°C en idle. Il n'est pas non plus reconnu par le test de santé Seagate IronWolf intégré dans DSM depuis la v6.1. Donc en conclusion, AMHA, le petit gain en performance et en consommation ne vaut pas la chandelle tant qu'on trouve encore des ST4000VN008, qui sont vendus sensiblement au même prix.

Pour la petite histoire, le support WD m'a échangé les deux WD40EFAX que j'avais achetés avant l'annonce de Synology, par des WD40EFRX recertifiés. L'opération a nécessité 2 demandes de RMA anticipés successives, pour disposer d'un disque de rechange en tuilage. Ceci afin de de procéder à la reconstruction de la grappe SHR et d'effacer l'ancien disque avec l'outil de diagnostic DLGDIAG avant de le leur renvoyer. Le contact par chat en français fonctionne très bien pour préciser qu'il s'agit d'une demande de changement de référence, et ils sont manifestement au courant de la problématique DM-SMR vs CMR. 🤫

Personnellement, acquéreur de 2 x WD40EFAX début avril 2020 (oui, le timing était juste parfait !), et devant l'incompatibilité annoncée par Synology depuis, je suis en train de tenter de me les faire remplacer par le SAV WD. Je viens de lancer un premier RMA anticipé, plus un message au support. En effet, le délai de rétractation étant échu, le marchand ne me propose qu'un retour avec remboursement par avoir, sans vouloir me fournir deux disques 4To d'une autre référence en "tuilage" pour que je puisse préalablement transférer mes données. Ceci alors qu'ils ont du Seagate IronWolf exactement au même prix, mais soi-disant "moins performant". Bref. Cela dit, le NAS ne signale pas d'erreurs, et les données ne sont pas critiques. Mais outre la lenteur des opérations d'écriture remarquée lors de la double reconstruction du volume unique SHR, je trouve que les disques EFAX sont trop bruyants par rapport aux WD30EFRX et IronWolf ST3000VN007 avec lesquels ils cohabitent. On entend clairement l'activité disque, même si c'est moins pire que les vieux et increvables Samsung au son si caverneux qu'ils remplacent.

Question bête si le sujet est encore d'actualité : est-ce que DS412+ a été passé à 2Go de RAM ? Après avoir un peu galéré pour trouver une barrette compatible, le mien est devenu nettement plus réactif avec une Samsung M471B5773CHS-CH9 achetée €8 sur LBC. Bon moyen de faire encore durer une excellente machine.

Je ne sais pas si mi-2019 DownloadStation a été corrigé, mais pour info la limite de vitesse globale fonctionne très bien avec le package Transmission du site SynoCommunity. https://synocommunity.com/package/transmission

Aux dernières nouvelles, les arnaqueurs sont sur le point de disparaître dans la nature, non sans monnayer la base contenant les clés non encore réclamées : http://www.theregister.co.uk/2014/08/14/synolocker_trojan_closing_down_sale/ http://www.f-secure.com/weblog/archives/00002733.html Notons l'existence d'un service support (sic) et de la possibilité contre paiement de récupérer les fichiers même après mise à jour du DSM (custom decryption tool). On peut cependant raisonnablement supposer que Synology a porté plainte, et que des investigations sont en cours.

Bonjour à tous, La dernière communication de Synology au sujet de Synolocker précise bien qu'il est impossible de déchiffrer les fichiers sans la clé : http://www.wegotserved.com/2014/08/06/synology-confirms-decyrption-help-available-synolocker-victims/ (les versions concernées du DSM sont la 4.1, certaines 4.0, 4.2 et 4.3) Et via le site ci-dessus, on trouve un lien vers l'analyse du ransomware sur le site de F-Secure : http://www.f-secure.com/weblog/archives/00002730.html A compléter avec ce lien chez Symantec : http://www.symantec.com/security_response/earthlink_writeup.jsp?docid=2014-080708-1950-99 Seules certaines extensions sont ciblées, ce qui explique la rapidité du processus, ajouté au fait que le message de racket n'apparaît qu'après le chiffrement d'un certains nombre de fichiers en tâche de fond pendant quelques temps, et que le hack est fort opportunément lancé durant le mois d'août pour retarder d'autant plus sa détection avant qu'il ne soit trop tard. Définitivement très astucieux, malheureusement pour les victimes.

Ce qui me gêne avec eux, c'est qu'ils insistent un peu lourdement : Encore moins envie, du coup.

Bon bah fin de la partie. Avoir eu gratuitement Internet Guide - et accessoirement un nom de domaine dynamique - aussi longtemps, c'était quand même chouette, même si finalement je me passerai sans pb des deux. Merci à eux quand même.

Merci mais euh, comme d'autres, je suis absolument sûr que cela fonctionnait auparavant, et de façon globale. Je vois mal la finalité de pouvoir laisser le système télécharger en parallèle plusieurs fichiers, dont le nombre maxi est variable selon la puissance du NAS, tout en devant faire un calcul d'apothicaire pour déterminer la limite totale à ne pas dépasser en fonction de la bande passante maximale de la connection.

Bonjour, Nouveau déterrage de ce topic zombie Car chez moi, les limites d'UL et de DL ne fonctionnent plus depuis quelques temps : pour peu que les torrent en file d'attente aient beaucoup de sources et se téléchargent donc vite, Download Station sature la bande passante de la connexion ADSL, notamment l'upload, ce qui ralentit considérablement tout autre activité sur le net. Cela dure depuis un petit moment (peut-être depuis le DSM 3.2), avec donc plusieurs mises à jour du DSM et du package, et même une migration pour cause de changement de NAS (DS211 vers DS412+). Il suffit de constater la discordance entre les valeurs de débit affichées dans Download Station et ce qui apparaît dans le Moniteur de ressources, sans autre activité réseau si ce n'est celle nécessaire à affichage de l'interface du DSM dans le navigateur. J'ai tout essayé : désinstallation / réinstallation du package, y compris en supprimant physiquement le cache de l'application et ses paramètres sur le volume via WinSCP modification à la main du fichier settings.conf dans /var/packages/DownloadStation/etc application d'une QoS sur les ports BT dans le Panneau de configuration (ne gère pas les débit asymétriques) RAS sur mon routeur, configuration NAT ou mon réseau, c'est vraiment un problème dû à Download Station. J'ai l'impression qu'il y a des griefs similaires sur le forum Syno officiel, mais pas de réponses. Merci de votre aide.

Si je comprends bien, les dossiers partagés sont accédés depuis des machines Windows via internet ? Via un VPN ou bien ? Au cas présent, il faut à mon avis éviter toute ambiguïté dans les couples noms de comptes / mot de passe sur le NAS, qui ne doivent pas être identiques aux noms de session utilisateur sur les PC distants. Comme en général, les ports des partages Windows (ex : TCP 137) sont la première chose que bloque le pare-feu d'un routeur ou d'une box, le cas d'utilisation me dépasse un peu, surtout que Syno a mis en place des outils de partage du NAS qui en général passent par le Web (webdav, FileStation) ou via des applis dédiées pour les terminaux nomades. Pour la pagaille après la ligne de commande, c'est normal : toutes les sessions actives de connexion à un partage réseau ont été fermées. Rien de surprenant donc.