Ik zit hier met een redelijk vreemd probleem i.v.m. Wake-On-Lan in combinatie met Linux distro (Fedora 7). Het gaat hier om een oud pc’tje dat als automatische backup server zou moeten dienen en dus liefst niet 24/24 zal aanstaan maar enkel wanneer er een andere PC in het netwerk actief is. (Dit zou ik bereiken door de PC’s een klein batch script te laten uitvoeren wanneer ze opstarten waarin een magic packet verstuurd wordt.)
Het probleem ligt al vast niet bij de voeding, of de netwerkkaart want er is een optie waarvan ik weet dat ze werkt, namelijk ‘wake-on-broadcast’. Zoals ik zei ik gebruik Fedora en het ethtool commando om de wol opties te beheren. Ethtool zegt duidelijk dat mijn kaart de pumbg opties ondersteund (waarbij g het magic packet is en b de broadcast optie) en wanneer ik manueel de opties instel zodat de pc zou wakker worden wanneer er iets op het broadcastadres komt doet ie dat ook. (Terwijl de lichtjes op de NIC uit staan!)
Dit bewijst voor mij duidelijk dat de NIC en de voeding wel degelijk nog iets ontvangen ook al staat de PC in slaapstand (het BIOS optie zei: Wakeup from S4). En toch krijg ik de magic packet optie niet aan de praat. Wanneer ik de g optie manueel instel en dan de PC in slaapstand zet wordt ie niet terug wakker. Wanneer ik hem dan zelf terug aanzet staat de wol optie op ‘disabled’ volgens ethtool ook al heb ik het ethtool -s eth0 wol g commando aan een hook script toegevoegd.
Naar wat ik begrepen heb zijn er verschillende manieren om een wol pakket te versturen? Via TCP/IP (geen optie vanwege mijn router en DI-524UP, aangezien deze IP adressen en MAC adressen vergeet), UDP (zelfde probleem denk ik?) en dan nog rechtstreeks via de MAC adressen (datalinklaag). Kan hier soms ergens het probleem zitten? Dat al de tooltjes die ik geprobeerd heb (waaronder die van depicious, amd, wol.exe freeware) allemaal een verkeerde verzendmethode gebruiken?
De pakketten zwerven wel degelijk over het netwerk wanneer ik met een packet sniffer onderzoek. Maar wel via UDP.
Ik heb een gelijkaardige vraag als deze, over hetzelfde probleem al eens gesteld in het Linux forum twee weken geleden ofzo maar daar heb ik geen antwoord op gekregen. Hopelijk kunnen de mensen van dit forum me beter helpen.
Het probleem ligt al vast niet bij de voeding, of de netwerkkaart want er is een optie waarvan ik weet dat ze werkt, namelijk ‘wake-on-broadcast’. Zoals ik zei ik gebruik Fedora en het ethtool commando om de wol opties te beheren. Ethtool zegt duidelijk dat mijn kaart de pumbg opties ondersteund (waarbij g het magic packet is en b de broadcast optie) en wanneer ik manueel de opties instel zodat de pc zou wakker worden wanneer er iets op het broadcastadres komt doet ie dat ook. (Terwijl de lichtjes op de NIC uit staan!)
Dit bewijst voor mij duidelijk dat de NIC en de voeding wel degelijk nog iets ontvangen ook al staat de PC in slaapstand (het BIOS optie zei: Wakeup from S4). En toch krijg ik de magic packet optie niet aan de praat. Wanneer ik de g optie manueel instel en dan de PC in slaapstand zet wordt ie niet terug wakker. Wanneer ik hem dan zelf terug aanzet staat de wol optie op ‘disabled’ volgens ethtool ook al heb ik het ethtool -s eth0 wol g commando aan een hook script toegevoegd.
Naar wat ik begrepen heb zijn er verschillende manieren om een wol pakket te versturen? Via TCP/IP (geen optie vanwege mijn router en DI-524UP, aangezien deze IP adressen en MAC adressen vergeet), UDP (zelfde probleem denk ik?) en dan nog rechtstreeks via de MAC adressen (datalinklaag). Kan hier soms ergens het probleem zitten? Dat al de tooltjes die ik geprobeerd heb (waaronder die van depicious, amd, wol.exe freeware) allemaal een verkeerde verzendmethode gebruiken?
De pakketten zwerven wel degelijk over het netwerk wanneer ik met een packet sniffer onderzoek. Maar wel via UDP.
Ik heb een gelijkaardige vraag als deze, over hetzelfde probleem al eens gesteld in het Linux forum twee weken geleden ofzo maar daar heb ik geen antwoord op gekregen. Hopelijk kunnen de mensen van dit forum me beter helpen.
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.
/u/11917/cheshirecat.png?f=community)