Automatisches Wakeup des WHS für externe Services

[piet]

Hallo JoachimL,

auch ich möchte meinen WHS automatisiert über WOL von meiner RitzBox einschalten, allerdings habe ich ein etwas anderen Ansatz.

Bei mir läuft eine FritzBox 7170 mit freetz 1.1.2.

Meine Idee ist, dass der WHS immer an sein soll, wenn ein Client im Netz aktiv ist - unabhängig davon, ob tatsächlich ein Zugriff auf den WHS erfolgt oder nicht.

Der WHS soll gestartet werden, sobald ein Client eingeschaltet wird.

Meine Frage ist nun, ob das ganze über den DHCP Server der FritzBox zu realisieren wäre. Sobald ein Client eine DHCP Adresse anfordert, soll der WHS per ether-wake gestartet werden. Ich denke, das ist die früheste Möglichkeit, oder gäbe es da noch etwas anderes?

Leider kenne ich mich im Linux nicht gut genug aus, um das ganze selbst zu realisieren

Hättest Du eine Idee dazu?


Danke und Gruß


Piet

[JoachimL]

Leider kenne ich mich im Linux nicht gut genug aus, um das ganze selbst zu realisieren

Du solltest Dich zumindest trauen Anleitungen nachzubauen und ggfs. vorher mal eine Suche anwerfen, aber ansonsten muß man nicht bei allem Experte sein. Probiert man nicht´s neues, lernt man auch nichts dazu...

Bei mir läuft eine FritzBox 7170 mit freetz 1.1.2.

Super Voraussetzungen. Welche Packages? Mit tcpdump & libpcap?

Meine Idee ist, dass der WHS immer an sein soll, wenn ein Client im Netz aktiv ist - unabhängig davon, ob tatsächlich ein Zugriff auf den WHS erfolgt oder nicht.
Der WHS soll gestartet werden, sobald ein Client eingeschaltet wird.

Kostet halt mehr Strom als nötig, aber reduziert Wartezeiten der Clients. Hast Du Dir LightsOut schonmal angesehen? Funktioniert bisher nur für Windows PCs - was für Clients verwendest Du? woraus könnte man noch ableiten dass der WHS gebraucht wird?

Meine Frage ist nun, ob das ganze über den DHCP Server der FritzBox zu realisieren wäre. Sobald ein Client eine DHCP Adresse anfordert, soll der WHS per ether-wake gestartet werden. Ich denke, das ist die früheste Möglichkeit, oder gäbe es da noch etwas anderes?

sehe erstmal keinen Grund warum das nicht gehen sollte, allerdings nur für Clients die DHCP verwenden.
Gruß Joachim

[piet]

Hallo Joachim,

vielen Dank für Deine schnelle Antwort

Du solltest Dich zumindest trauen Anleitungen nachzubauen und ggfs. vorher mal eine Suche anwerfen, aber ansonsten muß man nicht bei allem Experte sein. Probiert man nicht´s neues, lernt man auch nichts dazu...

Ja, ich trau' mich ja schon. Ich habe ja immerhin in einer virtuellen Linux Umgebung ein freetz-image compiliert und auf meine FritzBox übertragen, ohne dass sie explodiert ist

Super Voraussetzungen. Welche Packages? Mit tcpdump & libpcap?

Zurzeit nur das Basissystem mit Net-SNMP, CGI für AVM Firewall und Ehter-Wake - würde aber alles installieren was für das Aufwecken des Servers bei DHCP Adressvergabe notwendig ist.

Kostet halt mehr Strom als nötig, aber reduziert Wartezeiten der Clients. Hast Du Dir LightsOut schonmal angesehen? Funktioniert bisher nur für Windows PCs - was für Clients verwendest Du? woraus könnte man noch ableiten dass der WHS gebraucht wird?

Ja, mit dem Stromverbrauch hast Du sicher Recht, nehme ich aber in Kauf. Alle Clients sind Windows Clients, die ihre Adresse per DHCP abholen. Alle Nicht-DHCP (& always-On) Komponenten im Netz (Switch, Netzwerk-Mutlifunktionsdrucker (wird u.A. als Fax genutzt), COM2LAN Adapter) benötigen den Server nicht.
Es geht eigentlich auch nicht um einen WHS Server sondern um einen SBS Server. Daher kann ich LightsOut nicht nutzen.

Ich habe auch schon im IP-Phone-Forum gesucht, bin dort aber auch nicht fündig geworden. Dann habe ich Dein Script gefunden. Dein Ansatz scheint mit geringem Aufwand anpassbar zu sein

Meine Linux Kenntnisse reichen bei Weitem nicht aus, um mein Vorhaben selbst umzusetzen. Daher meine Frage, ob Du mir etwas unter die Arme greifen könntest und mir die notwendigen Schritte, für das Reagieren auf eine DHCP Anfrage auf der FritzBox und dem anschließenden Wecken des Servers (hier kann ich sicher Teile Deines Scriptes nutzen), mitteilen könntest.

Danke und Gruß


Piet

[JoachimL]

Hallo Piet,
Du solltest als erstes Freetz mit dem Package tcpdump (sollte libpcap automatisch einschließen) übersetzen und auf Deiner Fritzbox installieren. Wenn Du Dich danach mit telnet auf der Fritzbox anmeldest, probier mal ein "tcpdump -f udp dst 67" und schalte dann einen der Clients ein. Abbruch mit Ctrl-C. Wenn Du soweit bist, sehen wir weiter, wenn es Probleme gibt, meld Dich einfach.
Doku zu tcpdump findest Du übrigens unter http://www.tcpdump.org/tcpdump_man.html und zu DHCP unter http://en.wikipedia.org/wiki/Dynamic_Ho ... n_Protocol.
Gruß Joachim

[piet]

Hallo Joachim,

vielen Dank für die Infos

Werde Deinen Vorschlag ausprobieren und die Ergebnisse hier posten - kann allerdings ein paar Tage dauern, da ich im Moment mit dem Ausbau unseres Dachgeschosses ziemlich Busy bin


Danke und Gruß

Piet

[piet]

Hallo Joachim,

habe das tcpdump Paket in meine freetz Image compiliert (hört sich toll an - oder ) und die DHCP Anfrage eines Clients mitgeschnitten.

Die von Dir vorgeschlagene Syntax erzeugt allterdings einen Fehler:

Code: Alles auswählen

/var/mod/root # tcpdump -f udp dst 67
tcpdump: 'udp' modifier applied to host

Habe dann ein wenig gegoogelt und folgende Syntax ausprobiert:

Code: Alles auswählen

/var/mod/root # tcpdump -n port 67

Das Ergebnis beim Einschalten eines Clients ergibt folgendes:

Code: Alles auswählen

/var/mod/root # tcpdump -n port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lan, link-type EN10MB (Ethernet), capture size 68 bytes
12:15:17.011056 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
12:15:17.015248 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548
12:15:24.401634 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
12:15:24.406187 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548

4 packets captured
4 packets received by filter
0 packets dropped by kernel

Das heißt doch, dass tcpdump das Senden eines DHCP Requestes mitbekommt. Warum gibt es eigentlich zwei Anfragen und zwei Antworten (ich habe definitiv nur einen Client eingeschaltet )
EDIT: Es gab tatsächlich 2 DHCP Anfragen - ich habe den Test nämlich mit meinem Laptop gemacht, der per Kabel am LAN angeschlossen war, der aber auch WLAN eingeschaltet hatte. Es hat also tatsächlich 2 DHCP Anfragen und 2 IP Adressvergaben gegeben - eine für's LAN und eine für's WLAN.

Doch was fange ich nun damit an?

Gruß

Piet

[JoachimL]

Hallo Piet,
Du kommst prima voran. Jetzt mußt Du ein Skript laufen lassen, dass tcpdump im Hintergrund macht und Deinen Server weckt, ähnlich wie mein wakeonconnect.sh oben. Du kannst das entweder direkt in /var/flash/debug.cfg integrieren oder von dort ein Skript z.B. auf einer an die 7170 angeschlossenen USB-Platte oder -Stick rufen. Bei mir muß ich alles vom WHS laden weil die 7050 keinen USB-Host hat. Vorteil wenn Du es via USB lädst: Du kannst es evtl. bequemer editieren, brauchst aber einen Editor der nur mit LFs statt wie bei Windows CRLF als Zeilenende umgehen kann. Was gefällt Dir besser?
Ansonsten post mal den Inhalt von /var/flash/debug.cfg (sollte da was vertrauliches drin sein aus-x-en).
Gruß Joachim

[piet]

Hallo Joachim,

mir würde der Weg über ein USB-Stick besser gefallen.
Klappt das auch, wenn ich Teile von freetz als 'extern' markiere und somit ebenfalls auf den USB Stick auslagern möchte (ich habe testweise mal das Paket 'dnsmasq' ausgewählt und bekomme dann aber beim compilieren den Fehler 'Filesystem image too big', was ich, wie ich nachgelesen habe, durch das Auslagern von Paketen auf eien USB Stick beheben kann.

Die Datei /var/flash/debug.cfg kann ich bei mir nicht öffnen. Woran kann das liegen?

Code: Alles auswählen

/var/mod/root # cat /var/flash/debug.cfg
cat: can't open '/var/flash/debug.cfg': No such file or directory
/var/mod/root #

Und das, obwohl die Datei mit dem ls Befehl zu sehen ist

Code: Alles auswählen

/var/mod/root # ls -al /var/flash/debug.cfg
crw-r--r--    1 root     root     240,  98 Jan  1  2000 /var/flash/debug.cfg

Gruß

Piet

[JoachimL]

Klappt das auch, wenn ich Teile von freetz als 'extern' markiere und somit ebenfalls auf den USB Stick auslagern möchte (ich habe testweise mal das Paket 'dnsmasq' ausgewählt und bekomme dann aber beim compilieren den Fehler 'Filesystem image too big', was ich, wie ich nachgelesen habe, durch das Auslagern von Paketen auf eien USB Stick beheben kann.

müßte gehen - da ich keinen USB Port habe, hab ich es nicht ausprobieren können.

Die Datei /var/flash/debug.cfg kann ich bei mir nicht öffnen. Woran kann das liegen?

Code: Alles auswählen

/var/mod/root # cat /var/flash/debug.cfg
cat: can't open '/var/flash/debug.cfg': No such file or directory
/var/mod/root #

Und das, obwohl die Datei mit dem ls Befehl zu sehen ist

Code: Alles auswählen

/var/mod/root # ls -al /var/flash/debug.cfg
crw-r--r--    1 root     root     240,  98 Jan  1  2000 /var/flash/debug.cfg

Gruß

Piet

Keine Ahnnung! Irgend ein Linux-Experte der das schon hatte? Ein Bug in der Busybox? Am besten mal im Freetz-Forum suchen..
Mir fällt nur ein auch more, cp nach /var/tmp etc. auszuprobieren.
Gruß Joachim

[piet]

Hallo Joachim,

habe die Frage im IP-Phone Forum gestellt (http://www.ip-phone-forum.de/showthread ... ost1465866) und gelernt, dass die debug.cfg am Anfang leer ist und dass man sie deshalb nicht anzeigen kann, solange man nichts manuell hineingeschrieben hat.

Was sollte ich denn in die Datei reinschreiben?


Gruß

Piet

[JoachimL]

Hallo Piet,
eine Fehlermeldung hätte ich erwartet bei einer nicht existierenden Datei, nicht bei einer leeren.
Versuch mal den folgenden Inhalt - natürlich mußt Du am Anfang IP, Interface und Mac Deines Servers eintragen.

Code: Alles auswählen

server="192.168.178.22"
interface="eth1"
mac="00:26:2D:00:88:A0"

{
    while true; do
        tcpdump -n port 67 >wolconnect.dhcp
        ether-wake -b -i $interface $mac
        ping -c 1 $server || cat wolconnect.dhcp >>wolconnect.`date -I`.log
    done
} &

Testen kann ich das nicht sinnvoll, sollte aber halbwegs passen. Du kannst das ganze direkt ins debug.cfg schreiben oder - wenn man mehrere Erweiterungen hat wird es leicht unübersichtlich - in eine Datei auf Deinem Stick und dann diese Datei aufrufen. Zum Ändern von debug.cfg eignet sich am besten ein Texteditor in dem man den gewünschten Inhalt so einpackt und dann in die Telnetsitzung einfügt (paste):

Code: Alles auswählen

cat >/var/flash/debug.cfg <<EOF
..gewünschter Inhalt...
EOF

Viel Erfolg.
Gruß Joachim

[piet]

Hallo Joachim,

schonmal ganz herzlichen Dank für die Infos

Ich werde allerdings am Wochenende nicht dazu kommen, das auszuprobieren.

Melde mich in der nächsten Woche, sobald ich getestet habe.

Viele Grüße

Piet

[Tommyknocker]

Hi,
ich hab zwar keine Fritzbox sondern verwende OpenWRT aber ich bin grad mit dem gleichen Problem beschäftigt. So weit ich dein letztes Script verstanden hab, verwendest du nur noch Dhcp Requests als Indikator für den Start des Servers. In diesem Fall brauchst du eigentlich kein tcpdump. Den dazu könntest du auch die arp table nutzen

Code: Alles auswählen

arp 

oder auch

Code: Alles auswählen

cat /proc/net/arp/

Denn sobald ein Client ein Paket versendet, wird es in der arp Table erfasst, weil der Router diese für die Zuordnung der ip zur mac braucht. Also sobald da eine client ip im dhcp ip Bereich auftaucht ist ein neuer Client aktiv. Also zB.

Code: Alles auswählen

arp | grep 192.168.0.10? | wc -l 

Gibt die Anzahl der arp Einträge aus. die eine ip 192.168.0.10* enthalten. Die man dann einfach auf > 0 testet.
Das einzige Problem mit dem ich mich noch herumschlage sind fixe ips da die im inaktiven Zustand keinen arp Eintrag mehr haben. Da die table alle par Minuten neu aufgebaut wird und wenn es keinen traffic von dem Client gab fliegt er aus der List. Aber daran arbeite ich noch.

[JoachimL]

Hallo Tommyknocker,
zunächst mal - dhcp war ein Vorschlag für Piet, bei mir hört die Fritzbox immer noch auf Zugriffe auf https, aber egal. Interessante Alternative - weil für diesen speziellen Fall deutlich weniger Resourcen verbraucht werden. "arp" alleine findet die Fritzbox nicht, das andere schon. Du machst damit die Annahme dass der Router auch DHCP-Server ist - ist aber wohl die Regel. Allerdings bleiben bei mir WLAN Geräte relativ lange drin, ggfs. "übersieht" man einen Einschaltzyklus.
Gruß Joachim

[Tommyknocker]

Sorry hab die Beiräge nur interessant gefunden und habs nicht wirklich vollständig gelesen. Ja der Router muss wohl dhcp server sein damit das gut funktioniert, aber eigentlich genügt es wenn der Router alle Pakete sieht da er dann den arp Traffic analysiert und in den arp cache einträgt. Das einzige was ich noch nicht ausprobiert habe ist die Verwendung eines Switches zur Erweiterung da dann evtl. der normale Traffic nicht über den Router geht. Allerdings bleiben die dhcp anfragen ja erhalten und das sollte fürs Einschalten genügen.
Ich denke nicht, dass ein Einschaltzyklus verpasst werden kann. Denn wenn ein Gerät startet und sich verbindet muss es früher oder später im arp cache auftauchen. Entweder sobald eine dhcp Anfrage erfolgt oder sobald das Gerät irgend ein Paket ins Netz schickt, da ja jedes über den Router geht werden alle Geräte immer erfasst. Was bei Geräten mit fixen ips unter linux allerdings nicht automatisch durch irgendwelche Abfragen passiert, sondern erst so bald tatsächlich eine Netzwerkresource/Internet benutzt wird. Das ist für mich aber kein Problem da ich die 'fixen' ips fürs port forwarding auch per dhcp vergeben kann.

Was aber passieren kann ist, dass ein Rechner nichts mehr tut für einige Minuten und der Server in den Standby geht. Wenn der Rechner dann wieder aktiv wird und auf eine Resource zugreifen will, dann dauert es halt einige Zeit bis das Pollingscript wieder einen Test macht ob Clients aktiv sind und erst dann den Server startet da der Rechner vorher aus der arp Liste gefallen ist. Aber ob und welchen Effekt das hat muss ich noch testen, wenn das ganze produktiv eingesetzt werden kann.

Sollten die WLAN Geräte bei dir aber über lange Zeit in der Liste bleiben, könnte es sein, dass der Server nach einem Standby sofort wieder aufgeweckt wird. Aber das könnte man durch einen ping ja vorher checken ob wirklich clients dran hängen.