CoolRaoul

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)

C'est réparé. Selon les commentaires du ticket Github la cause était un disque plein. Je ne m'explique encore moins que les abonnés Free étaient impactés et pas ceux de certains autres fournisseurs d'accès.

Je ne parviens pas à trouver une explication logique à une erreur *interne* qui dépend de la provenance du flux (externe donc)

Je ne comprend pas, j'ai encore testé sur différent navigateurs et sur mon smartphone avec le même résultat Et la mise à jour des packages synocommunity échoue sur mon NAS aussi Oui, et en effet, si je bascule mon smartphone en data plus d'erreur

Toujours "Internal Server Error" ici (attention : l'erreur est sur https://synocommunity.com/packages , la page d'accueil (https://synocommunity.com/) fonctionne bien elle.

Salut à tous https://synocommunity.com/packages : "Internal Server Error" L'update des paquets échoue ("Unable to download "synocli-file". Please try again later.") **EDIT** Ah, je m'aperçois à l'instant que le problème est déjà signalé sur github : Backend Issue - Internal Server Error #107

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

Non mes options me semblent correctes (NB: peut-être que je ne comprends pas bien) une fois la restauration effectuée tout redevient normal. C'est *avant* de restaurer que le problème se manifeste (forcément!)

Pourquoi ? la restauration fonctionne (heureusement) Dans les versions récentes d'Android les restrictions accès aux fichiers sont de plus en plus strictes Pour faire court, une appli n'a accès qu'a ses propres fichiers. Par défaut (saufs droits spécifiques), pour qu'une autre appli accède à un fichier appartement à appli tierce elle doit obligatoirement passer par les fonction du "Storage Access Framework". Pas de open(), read(), write() etc ... Seuls les fichiers de certains dossiers (Download par exemple) sont accessibles sans restrictions. =========================== NB: je ne reçois toujours pas les notifications de réponse alors que je suis abonné au fil. C'est ennuyeux. C'est toujours pas résolu ce problème ? Moi non plus (après restauration de ceux à problème). Sur un très grand nombre de fichiers pdf je n'ai été confronté à ce dysfonctionnement que sur 2 ou 3 en plusieurs mois dont juste 2 récemment.

Vérifié et restaurés oui Seuls 2 fichiers ont été touchés jusqu'ici (et j'en ai des tas de .pdf) le seul client que j'utilise pour accéder à ces fichiers là c'est Synology Drive pour Android. Et le cloisonnement des acces fichiers d'Android ne permet pas à une autre app de les modifier directement. Je soupçonne un bug tordu dans Drive (coté client ou serveur)

L'un des deux est un reçu fiscal fourni par une asso. La seule métadonnée qu'il contienne est "outil de conversionOPDF : PyPDF2" L'autre est le résultat d'un scan effectué par une appli Microsoft (je ne sais pas si on peut parler ici de "fichier Office")

Et encore nouveau .pdf vidé ce matin. Restauré avec HyperBackup aussi

Salut à tous Il vient de m'arriver pour la 2eme fois une mésaventure inquiétante : des fichiers .pdf se retrouvent subitement avec une taille vide (0 bytes) A noter que juste la taille change, pas la date : La première fois c'était lors d'un accès smartphone via Synology Drive. Erreur soudaine à l'ouverture d'un fichier auquel j'accède régulièrement. Après analyse : fichier vide. Cette fois je m'en suis aperçu en ouverture par le réseau local en SMB. Dans les deux cas HyperBackup m'a sauvé mais ce n'est pas rassurant. A noter qu'aucune erreur ne s'est manifestée dans les logs ou dans les rapports hebdos programmés que m'envoie mon NAS. Je n'ai aucune piste. Peut-être que quelqu'un a une idée ? J'ai vérifié en ligne de commande si d'autres fichiers pouvaient avoir été touchés : find . -name '*.pdf' -size 0 -ls") Apparemment tout va bien (ouf)

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 oui en effet, c'est mort on dirait bien : https://github.com/liftoff/GateOne/issues/752