Synology-Forum.nl
Hardware ondersteuning => Netwerk algemeen => Topic gestart door: benneves op 30 juli 2018, 13:19:49
-
Hallo,
Sinds de update naar 6.2-23739 update 2 werkt de commando "synonet --wake [mac adress] eth0" niet meer.
Via de taakplanner heb ik een taak ingesteld die elke week een server opstart op een bepaalde tijd.
Daarna wordt een backup uitgevoerd en zal de server zichzelf uitschakelen.
Bovenstaande commando heeft altijd gewerkt tot de laatste update.
De commando wordt uitgevoerd door 'root'. Als ik kijk bij taakplanner -> 'resultaat bekijken', zie ik geen foutmeldingen.
Ik heb geprobeerd de commando in een bestand te plaatsen met de naam 'opstart.sh' en via de commando 'bash /volume1/script/opstart.sh' deze uit te voeren met geen succes. Als ik via een windows programma 'Wake on lan' de server probeert op te starten lukt dit wel!
Ik heb een DS213J met de laatste updates.
Graag hulp.
Dank je .
Ben
-
Bij mij werkt het gewoon in CLI "synonet --wake 00:11:32:08:xx:xx eth0"
DSM 6.2-23739 Update 2
-
@Birdy,
Als jij met de CLI werkt, dan is de nas toch niet in slaapstand en kun je niet testen of de cronjob in slaapstand wel actief wordt?
Oeps. Ik zie nu dat het om twee apparaten gaat. Daar waar de taakplanner draait is hij niet in slaapmode.
-
Natuurlijk heb ik gestest op 1 NAS die een andere NAS opstart ::)
En het gaat niet over uit slaapstand komen maar WOL.
Dus, het commando werkt.
-
Als de taakplanner niet meer zou werken als de Nas in slaapstand gaat dan zou het volgens mij problemen regenen.
Denk eerder dat het met permissies te maken heeft.
Misschien moet hij die taak eens als admin uit laten voeren.
Heb wel vaker gemerkt dat uitvoeren als root niet altijd lekker werkt in de taakplanner.
-
1 - synonet moet door root worden uitgevoerd.
2 - in CLI werk het: DS716+II start DS411+II op.
3 - in de Taakplanner (DS716+II ), taak opgestart als root en de DS411+II wordt opgestart, dus dat werkt ook.
-
Dank voor het meedenken @Birdy @Briolet @Ben(V)
Het volgende heb ik nog geprobeerd maar zonder succes:
1. commando als admin uitvoeren
2. ingelogd via putty en remote de commando "synonet" uitvoeren
-
Wat krijg je te zien in PuTTY (als root) te zien als je alleen synonet ingeeft ?
-
als ik via putty inlog als standaard gebruiker en "sudo synonet --wake [mac adress] eth0" intypt krijg ik geen melding terug.
-
Natuurlijk krijg je geen melding terug, dat wisten we al.
Lees nog eens goed wat mijn simpele vraag was.
-
oke. ben misschien effe de weg kwijt. :oops:
als ik je vraag letterlijk neemt, dus gewoon synonet intypen krijg je dit:
-sh: /usr/syno/sbin/synonet: Permission denied
btw, ingelogd als normale gebruiker.
-
En toen ging er een lichtje branden ;D
uitgezocht hoe als root in te loggen via putty en de commando uitgevoerd, echter nog steeds niets :S
-
Nog 1x dan: als je root bent geef je alleen in: synonet
Wat zie je dan ?
-
Dan krijg je uitleg over hoe synonet uit te voeren.
Zie screenshot.
-
Precies, ik wilde de versie weten, ik heb dezelfde versie echter, bij mij werkt het op alle mogelijke manieren.
Je zou Synology kunnen inschakelen, misschien is het een DSM (voor jouw NAS) probleem.
-
Plaats eens een screenshot van het synonet --wake commando inclusief macadres dat je ingeeft en laat ook even een screenshot zien van het macadres van je target.
Het kan namelijk nauwelijk iets anders zijn dan dat je ofwel het verkeerde macadres hebt ofwel het commando verkeerd invoert.
Of misschien een firewall op je target?
-
in het screenshot zie je links het mac-adres en rechts het commando dat via de taakplanner wordt uitgevoerd.
de nas zit achter een router die als bridge is ingesteld.
op de router draait DD-WRT.
Kan het probleem ook daar liggen. Ofwel kan de router WOL pakketten tegenhouden?
-
op de router draait DD-WRT.
Kan het probleem ook daar liggen. Ofwel kan de router WOL pakketten tegenhouden?
Lijkt mij niet, want de stelling is:
Sinds de update naar 6.2-23739 update 2 werkt de commando "synonet --wake [mac adress] eth0" niet meer.
-
Wake on lan is een broadcast dus blijft gewoon op je lan en komt helemaal niet bij je router uit.
Zit het ipadres van je Nas in hetzelfde subnet als die server?
Niet toevallig de netmask van je Nas op iets anders gezet?
-
Ik denk dat mijn aanname verkeerd was :oops: :oops: :oops:
Het lijkt alsof de router, als bridge ingesteld en werkend op DD-WRT, toch WOL tegenhoud.
Nadat ik de DS213J direct op de router, als access point, aansloot werkte de commando wel.
Het probleem heeft dus niets te maken met de update naar DSM 6.2-23739 update 2, maar met een wijziging op het netwerk waarvan ik de consequenties niet meteen doorhad.
Op de afbeelding zie je een korte weergave van mijn netwerk.
Kleine uitleg:
Ik wil de DS213J en de backup-server niet in één ruimte hebben.
Omdat ik nog een oude router heb, en hier heel goed DD-WRT op kan draaien dacht ik de kosten van een 2e powerline te besparen.
Via een PC met putty kon ik de backup-server opstarten dus leek toen alles in orde.
Omdat de DS213J 1 keer in de week de backup-server opstart, en ik deze niet zelf had getest, kwam ik pas later achter het probleem.
Toevallig had ik hiervoor ook mijn DS213J geupdated naar de laatste versie waardoor het leek alsof het hier aan lag.
Ik ga het probleem bij een ander forum plaatsen. Dit heeft te maken met DD-WRT lijkt me.
Dank allemaal voor het meedenken :thumbup: :thumbup:
-
Dit kan alleen werken als je een echte wireless bridge kunt opzetten die ook de connectie in stand houd.
Als de router gewoon als AP opgezet is dan gebeurd er niets als er een wol package door de Nas wordt uitgezonden.
Een wol package is niet geadresseerd en wordt dus als broadcast op het lan gegooid.
Een AP pikt dat niet op want die moet eerst een connectie opzetten voor er mee gecommuniceerd wordt.
Als je een echte wireless bridge hebt tussen die twee devices dan is die wifi verbinding transparant, net als een powerline setje.
Ik betwijfel echter of je die router gelijktijdig zowel een wireless bridge als een AP kunt laten zijn, maar daar ken ik DD-WRT niet goed genoeg voor.