CoolRaoul

Bien sur. Aucun changement C'est possible mais comment tester ? Le plus probable à mon avis. Va falloir ouvrir un ticket dans le bugtracker. J'aurais aimé avoir des retour d'expérience avant (positifs ou négatifs)

Celle-ci : https://play.google.com/store/apps/details?id=co.uk.mrwebb.wakeonlan C'est bien configuré pour utiliser le port 9 et je rappelle que ça fonctionnait avant sans avoir modifié la conf Oui , en pratique je parle de l'IP broadcast (192.168.1.255 selon la topologie de mon LAN). Mais effectivement la diffusion se fait avec la MAC broadcast forcément. Oui comme ça on se retrouve dans la même conf qu'en local bien entendu Mais je cherche à aller au plus simple : j'appui sur une icone et ça réveille l'appareil que j'ai ciblé. Si je doit activer le VPN autant en rester à la fonction WOL intégrée à l'appli Free.

Note : question posée également dans un forum Free mais sans réponse jusqu'ici donc je soumet ça ici. Préambule : Comme je n'utilise pas souvent cette fonction je ne suis pas capable d'identifier depuis quand ça ne fonctionne plus, il n'est pas impossible que ça soit depuis ma migration fibre mais ça m'étonnerait vu que j'ai conservé mes IPs et ma conf "FullStack". Je sais qu'on peut également réveiller un appareil à distance avec l'ancienne appli Freebox (bien plus complète que FreeBox connect qui ne le permet pas) mais j'ai besoin de valider la fonction via proxy + paquet magique. Je n'ai pas changé l'application (sous Android) utilisée pour faire mes tests pas plus que sa configuration Pour chacun des appareils à réveiller j'ai une config "lan" (qui diffuse directement en local sur l'adresse de broadcast) et une config "ext" (externe) qui cible l'IP fixe externe de ma box. Les config "lan" continuent à fonctionner correctement. Je lance une capture (par tcpdump) en local sur un de mes appareils qui filtre les paquets UDP port 9 Et donc, quand le smartphone utilisé pour activer le wake on LAN est connecté au réseau *local* en wifi, en utilisant la config "LAN" de l'appli les paquets sont bien capturés. En connexion réseau mobile par contre rien ne passe. Je peux confirmer que ça fonctionnait avec la même configuration précédemment (mais je ne saurais pas dire quand était la dernière fois)

Bon à savoir ça que SFR permette le Full Stack sur demande. Personnellement je l'ignorais.

Ah oui en effet, ça aurait été une bonne idée de prévenir, j'ai dû utiliser "mot de passe oublié" pour retrouver l'acces au forum!

Vérifier si restart auto est activé dans le panneau de configuration DSM

Il y aurait plutot un risque que certaines de celles affichées ci-dessus ne soient pas implémentées si on se base sur cette discussion : https://www.nas-forum.com/forum/topic/75618-comment-émettre-un-wake-on-lan/?do=findComment&comment=1319479975 Mais la doc officielle de "synouser" est ici dans le CLI Administrator Guide for Synology NAS

Il existe une commande en ligne, "synouser", avec une option "--add" : $ sudo synouser Copyright (c) 2003-2022 Synology Inc. All rights reserved. Usage: synouser --help --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})} --enum {local|domain|ldap|all|domain_used} --enumpre {local|domain|all|domain_used} prefix Caseless{0|1} --enumsub {local|domain|all|domain_used} substr Caseless{0|1} --enum_admin {local|domain|ldap|all} --get username --getuid UID --add [username pwd "full name" expired{0|1} mail privilege] --modify username "full name" expired{0|1} mail --rename old_username new_username --setpw username newpasswd --del username1 username2 ... --login username pwd --dbopen2 username --filesetpw --create_homes {domain|ldap} Mais l'invoquer à partir d'un formulaire web, comme c'est root (donc sudo) obligatoire, c'est quand même un peu touchy

Je suis vraiment désolé que ça soit tombé sur toi, mais je ne compte plus le nombre de fois où je tombe sur une réponse "chez moi ça marche" dans un fil ou un utilisateur vient demander de l'aide. Et parfois je réponds avec ce genre de remarque qui, je le reconnais, peut s'avérer désagréable. mieux alors: sudo tcpdump -Anq -i any 'udp port (0 or 7 or 9)' (au cas ou le nom des interface LAN est différent selon le modèle de NAS)

<HS> le fait qu'une *même* commande se comporte différemment selon qu'on utilise un chemin absolu ou la résolution via le PATH (étant donné que l'identité du chemin de la cible est confirmé par un "which <commande>" ) remet en cause toute mon expérience du fonctionnement des shells Unix. Un pointeur vers un cas avéré m'intéresse au plus haut point </HS>

Je ne suis plus chez moi la et donc plus d'accès à mon PC et à son Wireshark Mais je ne vois pas quelle différence ça pourrait faire

Voulant en avoir le cœur net j'ai testé avec Wireshark. Avec le module Python je capture bien le "magic packet": Avec "synonet --wake" : rien J'ai meme essayé un tcpdump en ligne de commande sur une autre fenêtre shell directement sur le NAS ("sudo tcpdump -i eth0 '(udp and port 7) or (udp and port 9)'") ; pas mieux

Je ne pense pas que [mention=76055]PierU[/mention] trouve utile de savoir que la méthode qu'il essaie sans succès d'utiliser marche chez d'autres. De mon côté j'ai également retesté "synonet" en ligne de commande, autant avec sudo à partir d'un compte non root que sans dans un shell "full root" ("sudo -i") et ça n'a marché dans aucun des cas.

Confronté au même besoin, je ne suis également pas parvenu à avoir de succès avec la commande "synonet" (que pourtant il me semblait me souvenir avoir utilisé dans le passé) Je n'ai pas trouvé plus simple que d'installer ce module Python : https://github.com/remcohaszing/pywakeonlan (dans un virtualenv pour faire plus propre) Et je confirme que ça fonctionne (je réveille mon PC une fois par semaine pour que sa sauvegarde planifiée s'exécute)

Ah, j'avais bien compris alors ! Dans ce cas, je renouvelle ma suggestion d'aller également essayer de poser la question sur un forum TV. Plus de chances en plus d'y trouver des compétences sur la configuration des modèles Panasonic.

Ah j'avais pas percuté que c'était du DLNA, la référence au nom d'utilisateur et au mon mot de passe m'a induit en erreur

Je pense que ça serait une question à poser plutôt sur un forum TV/home cinema Celui-ci par exemple : https://www.homecinema-fr.com/forum/

Si le port 5000 est ouvert (et pas le 5001) la seule différence que ça fera en ce qui concerne les tentatives d'accès illégitimes sera que le traffic entre le pirate et le NAS ne sera pas chiffré (et donc en clair). Ça ne rendra pas le service plus vulnérable à ce genre d'attaques par contre. Bien entendu ceci n'empêche pas que pour les accès légitimes il faut absolument s'astreindre à utiliser le port SSL (5001), et donc ne laisser que celui-ci ouvert dans la box. Même avec un certificat invalide (autosigné): le traffic restera quand même chiffré. Même si c'est un poil moins sécurisé, on n'est pas à l'abri d'attaque de type "man in the middle" (passe plat) mais il y a peu de risques que quelqu'un se donne autant de mal pour détourner le traffic d'un serveur personnel à domicile. L'option VPN suggérée est meilleure mais ça n'empêchera pas des possibles tentatives de connexion du même type (brute force), sauf que a sera sur l'accès VPN cette fois, (plus rare cependant). Par contre ça sera sans doute pas évident de se connecter par cette méthode, à l'improviste en cas d'urgence, voire à partir de son réseau d'entreprise. Au delà de ça et en parallèle il est possible d'utiliser le firewall intégré pour limiter les accès exclusivement au pays de son domicile. C'est pas parfait (je peux en témoigner) mais ça réduit considérablement les alertes de tentative d'intrusion. Ne pas oublier aussi alors d'ouvrir le ou les ports requis par le VPN si on l'utilise, sur la box et dans le firewall (à moins de disposition d'un VPN intégré à la box).

Ah ok, et en effet en postant ce message j'ai eu le sentiment d'avoir déjà signalée cette anomalie mais ne suis pas pas parvenu à retrouver mon post précédent. C'est un peu ennuyeux. Peut-on savoir si un des admins du forum est sur le dossier ?

Bonjour, Une réponse a été postée dans ce fil que j'ai ouvert ce matin : "warning SMB1 récurrent dans les logs" Alors que l'option de suivi est bien activée dans le fil ("Un courriel lorsqu’un nouveau contenu est posté") , je n'ai pas reçu de notification (et pas en spam non plus) Bien entendu mon email est valide dans mes paramètres de compte

Ci joint un script ("my_sendmail") perl (qui nécessite bien entendu l'installation du paquet correspondant) que j'utilise pour envoyer des mails en ligne de commande. Son mode utilisation est en tête du code. my_sendmail Et si tu préfère quelque chose de plus propre, il y a ça (pas testé) : https://github.com/zehm/sendEmail

La syntaxe "${1:-<valeur_défaut>} permettait de mettre un défaut sauf si spécifié explicitement en $1 En en effet, ça dépend si le fichier est directement copié/généré dans le dossier ou juste déplacé Après le "do" ajouter: [[ $1 == *.epub ]] || continue Quelqu'un va bien te trouver ça,

Tout à fait

A mon avis, le plus light (en termes de ressources en particulier) est de le faire via un script shell. Le pre-requis est d'installer ce package "inotify-tools": Ensuite lancer en tache de fond un script basé sur ce modèle : #!/bin/bash PATH=/bin:/usr/bin:/usr/local/bin WATCHED_DIR=${1:-/var/tmp/watched_dir} # répertoire que j'ai utilisé pour tester # inotifywait --recursive \ --quiet \ --event close_write \ --format "%w%f" \ --monitor $WATCHED_DIR | while read newfile do echo >&2 "received: $newfile" # ici ajouter la commande pour envoyer le fichier "$newfile" par email done Pour la commande email je pense qu'un autre membre du forum saura proposer une façon de faire. En ce qui concerne le lancement automatique du script, je préconise, après l'avoir testé à la main, de le faire au boot, via le gestionnaire de taches (task manager) de cette façon :

Ca doit poser problème pour le renouvellement auto de(s) certifcat(s) let's encrypt non?