Hilfe beim Skripten für FB7360SL mit Freetz

Disector · 30 Nov 2015

Hallo zusammen,

ich hoffe dass ich mit meiner Frage hier an der richtigen Stelle bin.

Zu meinem Vorhaben:
Ich habe einen Server im Netzwerk der auch von außerhalb erreichbar sein soll, dennoch soll dieser nicht 24/7 laufen. Daher soll der Server starten sobald eingehende Zugriffe registriert werden, daher sollte die FB dafür sorgen. Mit Freetz schien mir dies möglich, also habe ich auf meiner FB 7360SL (FW 06.30) Freetz(devel-13451) installiert was auch Problem funktioniert hat. Via Putty kann ich mittels

Code:

tcpdump -i any port X dst 192.168.X.X

eingehende Verbindung sehen. Nun mein Gedanke ist ein Script zu erstellen welches an meinen Server einen Ping schickt als Schleifenbedingung, sollte keine Antwort kommen, dann soll mittels einer if Abfrage der oben aufgeführte Befehl ausgewertet werden. Falls eine Anfrage gefunden wird, schickt die FB mit hilfe von ether-wake ein MagicPaket zum wecken vom Server.

Leider scheitere ich bereits an der Syntax, entweder wird das "done" oder "then" nicht akzeptiert wenn ich das Skript in Putty ausführe. Führe ich den Quellcode im Freetz Interface unter rc.custom aus, können die Busybox Befehle nicht ausgeführt werden, bzw auch dort habe ich öfters Schwierigkeiten mit der Syntax.
Ich vermute, mir fehlt ein Compiler oder sonst was der das Skript richtig ausführen kann, da ich bereits viele verschiedene einfachste Beispiele erfolgslos ausprobiert habe. Daher kann ich nicht raus finden ob ich überhaupt in der If-Bedingung den tcpdump gegen 0 vergleichen kann.

Code:

echo "Listening to ports  for IP 192.168.178.2" >> /var/media/ftp/uStor01/CheckPortAction.log
while ![ping -c 1 -q "192.168.X.X" > /dev/null]; do 
    if [tcpdump -i any port X dst 192.168.X.X != 0]; then
        echo `date`" Registered action on port X." >> /var/media/ftp/uStor01/CheckPortAction.log
    fi
    sleep 10
done

Ich wäre wirklich froh über jeglichen Ratschlag was ich falsch machen oder was mir fehlt damit das Skript ausgeführt wird.
Danke

koyaanisqatsi · 30 Nov 2015

Moins

Ich schiess mal ins Grüne...

Das Kommando tcpdump wird einfach nicht gefunden.
Um so etwas zu vermeiden sollte deshalb der volle Pfad verwendet werden.
Also nicht einfach...
tcpdump
...sondern (beispielsweise)...
/var/media/ftp/SanDisk-Cruzer-01/external/usr/sbin/tcpdump

Disector · 30 Nov 2015

hallo koyaanisqatsi,

danke für die schnelle Idee, also ich habe es endlich mit der Rudi(mentär)-Shell geschafft die Befehle auszuführen. Jetzt suche ich ob man den tcpdump dump in der If-Bedingung vergleichen kann, damit ich weiß ob eine Anfrage statt findet.

EDIT:

Wie schon gesagt, funktioniert mein erstellter Quellcode tadellos unter der Rudi(mentär)-Shell. Es erkennt wenn mein Server mit Ping erreichbar ist oder ein Zugriff auf den Port stattfindet. Darauf hin startet der Server, so wie es sein soll.

Code:

echo "Listening to port X for Host-IP X" >> /var/media/ftp/uStor01/CheckPortAction.log
while !(ping -c 1 -q "X" > /dev/null); do
    if (tcpdump -i any port X -c 2 > /dev/null); then
        echo `date`" Registered action on port X." >> /var/media/ftp/uStor01/CheckPortAction.log
        ether-wake -b X
    fi
    sleep 60
done
[CODE]

Wie kann ich jetzt den Quellcode als Skript speichern ohne Syntax Errors.  In Putty bekomme ich das folgende als Rückmeldung wenn ich das als CheckPortAction.sh speichere und dann ausführe (vorher führe ich chmod +x CheckPortAction.sh aus):

/var/media/ftp/uStor01/CheckPortAction.sh: line 1: can't create /var/media/ftp/u: Invalid argumenttion.log
/var/media/ftp/uStor01/CheckPortAction.sh: line 8: syntax error: unexpected "done" (expecting "then")

PeterPawn · 30 Nov 2015

Nach der Beschreibung frage ich mich allerdings, warum Du nicht ganz plump die "stock firmware" von AVM benutzt und dort in Kombination mit der ja ohnehin erforderlichen Portfreigabe den Server bei eingehenden Paketen direkt von der FRITZ!Box starten läßt. Ich blicke zwar gerade bei Deiner Beschreibung mit ping, tcpdump und Polling nicht so richtig durch (habe auch keinen Ehrgeiz in der Richtung), aber das, was da in #1 als Ziel formuliert ist, kann die originale Firmware bereits.

Für das "Einschlafen" ist dann ohnehin wieder der Server selbst verantwortlich ... da könnte man ggf. noch etwas wie ein "Monitoring" auf der FRITZ!Box implementieren, was nach entsprechender Zeit ohne externe Zugriffe so einen Server per "remote command" (abhängig von dessen Betriebssystem) wieder schlafen schickt, aber nur, wenn der das tatsächlich nicht selbst auf die Reihe kriegt.

Was m.W. auch nicht funktioniert, ist die Verwendung eines anderen Ports als "Trigger", also so eine Art "port knocking" für den Aufruf von ether-wake - die anderen üblichen Probleme bei solch einer Konstruktion hat aber die AVM-Firmware logischerweise auch.

Der erste Zugriffsversuch wird z.B. in aller Regel fehlschlagen, weil der Server noch "etwas verschlafen" ist - ich weiß nicht, ob und wie lange das FRITZ!OS so ein Paket zurückhält, nachdem der Server geweckt wurde und an eine permanente "Überwachung" des Serverzustands glaube ich eher nicht ... das erinnert mich aber auch daran, daß ich das schon länger mal wieder testen wollte.

Wenn ich raten sollte, würde ich vermuten, daß AVM nach einer gewissen Zeit ohne aktive Verbindungen so eines Servers im internen "connection tracking" dem Server bei eingehendem Datenverkehr dann prophylaktisch ein "magic packet" schickt und wohl gar nicht wartet ... irgendwelche Paketwiederholungen würden schließlich (zumindest bei TCP) von der Sicherungsschicht aus ohnehin erfolgen, da ist das Zurückhalten (und zeitversetzte Aussenden) von Paketen eigentlich unnötig - bei IPSec wird es allerdings tatsächlich praktiziert (da wird das Paket aufgehalten, bis die Verbindung etabliert ist und dann gesendet).

koyaanisqatsi · 30 Nov 2015

Nun, die nach links geneigten Hochkommata sind eigentlich deprecated...

Code:

echo `date`" Registered action on port X." >> /var/media/ftp/uStor01/CheckPortAction.log

...die werden leicht übersehen, mach es lieber so...

Code:

echo $(date)" Registered action on port X." >> /var/media/ftp/uStor01/CheckPortAction.log

Und wenn du für tcpdump und/oder ether-wake keine vollen Pfadangaben nehmen willst, dann mach wenigstens eine PATH Variable im Skript.
Am Einfachsten geht das, indem du dir PATH mal ausgeben lässt, wo es funktioniert...

Code:

echo $PATH

Dann öffnest du dein Skript und in die zweite Zeile, kommt dann...

Code:

PATH=Hier rein was echo $PATH ausgegeben hat

Disector · 1 Dez 2015

@PeterPawn,

danke für deine Antwort. Die Stock FW bietet zwar diese Funktion, aber leider wird der Server nicht gestartet bei einem Zugriff aus dem Internet. Das mit dem Portforwarding klappt hingegen schon. Ein Freund hat genau das selbe Problem gehabt, das sein Server nicht gestartet wird. Deshalb habe ich die Entscheidung getroffen es mit Freetz zu probieren

Bezüglich dem Einschlafen des Servers hast du Recht. Mein Server geht in den Ruhezustand durch eine batch die ich geschrieben habe nach circa 30min. Zwar ist das noch nicht optimal, aber das habe ich nur mal schnell umgesetzt zum Testen. Dort liegt die Priorität für mich gerade noch nicht so hoch.

@koyaanisqatsi
vielen dank für den Hinweis mit `date`, bin leider kein Experte im Unix Bereich

Ich glaube ich weiß jetzt was du meinst mit dem Path und werde es mal heute Nachmittag/Abend ausprobieren. Melde mich wenn es funktioniert bzw wenn nicht

PeterPawn · 1 Dez 2015

@Disector:
Hast Du denn mal versucht, das Problem der AVM-Firmware einzugrenzen? Die entscheidende Frage hier wäre es ja, ob die Firmware kein "magic packet" erzeugt (Packet-Dump anfertigen) oder ob der Server es nicht versteht, wenn es von der AVM-Firmware auf der FRITZ!Box erzeugt wird (ob da tatsächlich das vorhandene "ether-wake" verwendet wird, bezweifle ich eher, es wird nirgendwo in den AVM-Komponenten aufgerufen) - die AVM-Firmware erzeugt am Ende auch nur ein solches Paket: Absender ist ihre eigene MAC-Adresse, Ziel ist (Ethernet-)Broadcast, Type ist 0x0842 und dann folgt nach 8x 0xFF 16x die MAC-Adresse des zu weckenden Rechners. Warum sollte das bei Freetz so sehr viel anders aussehen?

Ob das Wecken generell funktioniert, kannst Du mit dem "Computer starten"-Button prüfen ... gibt es bei Dir da tatsächlich einen Unterschied zu einem manuellen Aufruf von "ether-wake" auf der FRITZ!Box (nicht auf irgendeinem anderen Host im Netzwerk)?

Wenn es mit dem Button klappen sollte, wäre halt die Frage, warum die Box dann das Paket nicht automatisch erzeugt.

Da kann ich mir nur zwei Erklärungen vorstellen ... der Zugriff erfolgt nicht wirklich aus dem Internet beim Test (lokale Zugriffe starten den Server eigentlich nicht und auch ein Zugriff aus den LAN auf die externe Adresse wird höchstwahrscheinlich hier dank "NAT hairpinning" gar nicht erst als von extern ankommender Verkehr erkannt werden) oder die FRITZ!Box hat noch eine "offene Verbindung" für den Server (dann wird er in der Übersicht mit der Weltkugel anstelle der grünen LED dargestellt) und hält es daher noch nicht für notwendig, ihn (erneut) zu wecken.

Da es bei UDP-Verbindungen ja keinen Ende-Indikator gibt, muß man für solche Tests dann schon das Timeout für das Connection-Tracking einer UDP-Verbindung abwarten, jedenfall wenn die Box so arbeiten sollte, wie ich es vermute. Ich kann es bei mir nicht richtig selbst testen, weil jeder Zugriff auf die FRITZ!Box über den Server (als einzigen Client im LAN der Box) erfolgt und daher schon die Anzeige des GUI der Box oder das Speichern eines Packet-Dumps immer aktive Verbindungen sind. Am einfachsten sieht man das wohl wieder im GUI anhand der angesprochenen "Anzeigen" vor dem Namen.

PeterPawn · 1 Dez 2015

@Disector:
Ich habe in einem anderen Zusammenhang gerade feststellen müssen, daß das AVM-GUI bei der 06.30 (bei mir 7490) wohl tatsächlich ein Problem hat ... und zwar wird unabhängig von der Einstellung im GUI der Wert von "auto_etherwake" in der "landevices"-Sektion der ar7.cfg nicht richtig auf "yes" gesetzt, wenn er es eigentlich sein sollte. Macht man das von Hand (ar7.cfg-Änderungen brauchen einiges an Umsicht und ggf. einen Neustart der Box), wird auch das "magic packet" bei eingehenden (TCP-)Verbindungen erzeugt ... wie es bei mir im Moment aussieht (ist - wie gesagt - schwerer zu ermitteln), für jedes TCP-SYN-Paket aufs neue. Wie es bei UDP-Freigaben aussieht, muß ich bei Gelegenheit mal testen.

Ich lasse das mal in zwei eigenen Beiträgen nacheinander eine Zeitlang stehen ... entgegen den Forenregeln. Sollte es sehr stören, bitte einfach zusammenlegen.

tb2668 · 2 Dez 2015

Hallo PeterPawn,

danke für den Vorschlag. Ich arbeite zusammen mit Disector seit ein paar Tagen an diesem Problem und habe mal in die Datei

Code:

/var/flash/ar7.cfg

geschaut. Bei mir ist der entsprechende Eintrag jedenfalls auf "yes" gestellt:

Code:

auto_etherwake = yes;

Das Problem besteht leider trotzdem.

Gruß
tb2668

PeterPawn · 2 Dez 2015

Und es gibt nicht etwa zwei Einträge im "landevices"-Abschnitt für dieselbe IP-Adresse? Eine "alte Krankheit" nach mehreren Updates und Änderungen von Einstellungen, wenn man nicht von Beginn an "immer dieselbe Adresse zuweisen" gesetzt hatte.

Was ergibt denn ein Start über das GUI per Button? Funktioniert der nun oder nicht?

tb2668 · 2 Dez 2015

Start per GUI Button funktioniert wunderbar.

Unter landevices in der arg.cfg steht folgendes:

Code:

landevices {        
        landevices_version = 2;
        landevices {
                ip = 192.168.0.3;
                name = "SERVER-TB2668";
                mac = xx:xx:xx:xx:xx:xx;
                medium = medium_ethernet;
                auto_etherwake = yes;
                ifaceid = ::;
                type = neightype_pc_windows_vista;
                staticlease = no;
                ipv4forwardrules = 
                                   "tcp 0.0.0.0:21 192.168.0.3:21 0 # FTP-Server", 
                                   "tcp 0.0.0.0:10011 192.168.0.3:10011 0 # TS1", 
                                   "tcp 0.0.0.0:30033 192.168.0.3:30033 0 # TS2", 
                                   "udp 0.0.0.0:9987 192.168.0.3:9987 0 # TS3", 
                                   "udp 0.0.0.0:43434 192.168.0.3:9 0 # WoL", 
                                   "tcp 0.0.0.0:32400 192.168.0.3:32400 0 # Plex", 
                                   "tcp 0.0.0.0:3389 192.168.0.3:3389 0 # MS Remotedesktop";
        } {

Außerdem wurde ein statischer ARP-Eintrag für den PC auf der Fritzbox erstellt.

PeterPawn · 3 Dez 2015

Mehrere mögliche Tests ... den statischen ARP-Eintrag (wie macht man den überhaupt bei "stock firmware" ohne Telnet) kann man auch weglassen, ja - ich würde ihn sogar aus Prinzip auslassen, falls die Box von diesem - nicht von ihr erzeugten - ARP-Eintrag vom Senden des WoL-Pakets abgehalten wird, weil sie z.B. immer noch denkt, der wäre an und hätte sich innerhalb der TTL des ARP-Caches bei ihr gemeldet, weil sie den Unterschied zwischen statischem und dynamischem Eintrag nicht berücksichtigt.

Ansonsten "landevices_version" mal auf "3" setzen und "neighbour_name" mit identischem Wert wie bei "name" hinzufügen ... außer der Server meldet sich z.B. per mDNS mit einem anderen Namen, dann den nehmen - für mich zwar weniger wahrscheinlich, aber vielleicht wirkt sich die Version ja auf die berücksichtigten Eigenschaften eines "landevice" bei der Suche nach irgendeinem Eintrag aus. Wie lange gibt es diese "landevices"-Sektion denn schon in der Box? Auch ein Import einer Export-Datei ohne diesen Abschnitt würde zum kompletten Löschen (und notwendigen Neuaufbau) dieser Sektion führen ... ich bin etwas verblüfft von der Version 2, weiß aber auch nicht sicher, ob die 3 bei mir nicht von der ständigen Wechselei zwischen 06.36 und 06.30 stammt.

Weitere Idee ... auch wenn die Box die Adresse nicht wirklich vergibt/vergeben hat, trotzdem mal "staticlease" einschalten - auch dadurch könnte der "lookup"-Prozess bei der Suche nach einer Zuordnung zwischen IP- und MAC-Adresse verändert/beeinflußt werden oder sogar die generelle Entscheidung, ob für eine einkommende Verbindung ein WoL-Paket zu erzeugen ist.

Auch würde ich bei den Freigaben erst einmal klein anfangen und mich zunächst einmal auf einen automatischen Service beschränken. Die Weiterleitung von UDP/43434 würde ich sogar komplett auslassen, jeder andere Zugriff auf einen freigegebenen Dienst sollte das erledigen. Nimm doch erst mal nur den RDP-Service und schau, ob der bei einem Zugriff von extern (wie gesagt, wirklich von extern und nicht etwa per "NAT hairpinning" aus dem internen Netz, denn es kommt ja nicht darauf an, welche Adresse der Server sieht, sondern daß das Paket auf der FRITZ!Box an der richtigen Stelle vorbeikommt) auch ein "magic packet" in einem Packetdump erscheinen läßt (am besten den FRITZ!Box-eigenen verwenden und auch für "lan" ... also die Bridge anstelle des ethX-Interfaces).

Ich selbst habe im Moment auch nur einen TCP-Service getestet (wo m.E. dann eben ein SYN-Paket zum WoL führt) ... ob und wie es mit UDP-Freigaben funktioniert, weiß ich nicht - daher würde ich nicht gerade den TS auf 9987 oder den WoL-Port auf UDP-Basis für einen solchen ersten Test verwenden.

tb2668 · 4 Dez 2015

Danke für die Ansätze und Gedankenanstöße.

ARP Einträge wurden mit Freetz über die rc.custom erstellt.
Und bevor der statische ARP Eintrag erstellt wurde, hat die WoL Funktion auch schon nicht funktioniert wie sie es sollte.

Was ist denn der Unterschied zwischen landevice_version 2 und 3?

Unsere jetzige Lösung sieht so aus, dass das folgende Skript in rc.custom hinterlegt ist:

Code:

#!/bin/sh
#in rc.custom kopieren
#Ports:
#21 = FTP
#9987 = TeamSpeak
#32400 = Plex
#3389 = MS Remotedesktop
#2302 = DayZ Server
while (true); do
if !(ping -c 1 -q 192.168.xxx.xxx > /dev/null); then
if (tcpdump -i any -c 2 -q '(tcp port 21) or (udp port 9987) or (tcp port 3389) or (udp port 2302)' and dst 192.168.xxx.xxx); then
ether-wake -b xx:xx:xx:xx:xx:
sleep 60
fi
else
sleep 120
fi
done

Warum kann rc.custom und Rudi-Shell das eigentlich ausführen, und wenn man es als andere Shell speichert funktioniert es nicht?
Könnte das Skript ja auch zB als wakeup.sh auf meinem USB Stick speichern, mit chmod +x ausführbar machen und manuell oder per rc.custom starten ... funktioniert nicht.

PeterPawn · 4 Dez 2015

tb2668 schrieb:
Was ist denn der Unterschied zwischen landevice_version 2 und 3?

Wenn ich es definitiv wüßte (ist halt ClosedSource), hätte ich es geschrieben.

Warum kann rc.custom und Rudi-Shell das eigentlich ausführen, und wenn man es als andere Shell speichert funktioniert es nicht?
Könnte das Skript ja auch zB als wakeup.sh auf meinem USB Stick speichern, mit chmod +x ausführbar machen und manuell oder per rc.custom starten ... funktioniert nicht.

Wie sattelfest seid Ihr denn in Shell-Programmierung? Ich behaupte mal, nicht so sehr ... schon in #1 sollte eigentlich die Konstruktion

Code:

![ping -c 1 -q "192.168.X.X" > /dev/null]

nicht wirklich funktionieren, weil nach der eckigen Klammer zumindest mal ein Leerzeichen stehen müßte, damit das als "test"-Operator erkannt wird. Der geübte Shell-Programmierer verwendet auch runde Klammern - wie in #13 - nur sehr sparsam, weil damit das Kommando in einer Subshell ausgeführt wird und das Ergebnis, das man mit einem "!(kommando)" abfragt, ist das der Subshell - selbst wenn das fast immer mit dem Ergebnis eines einzelnen Kommandos in den Klammern übereinstimmen wird.

Normalerweise würde man das so schreiben:

Code:

while true; do
  if ! ping -c 1 -q 192.168.xxx.xxx > /dev/null; then
    if tcpdump -i any -c 2 -q '(tcp port 21) or (udp port 9987) or (tcp port 3389) or (udp port 2302)' and dst 192.168.xxx.xxx; then
      ether-wake -b xx:xx:xx:xx:xx:
      sleep 60
    fi
  else
    sleep 120
  fi  
done

Weil das mit dem Negieren unübersichtlicher ist, läßt sich das leicht umformulieren:

Code:

while true; do
  if ping -c 1 -q 192.168.xxx.xxx > /dev/null; then
    sleep 120
  else
    if tcpdump -i any -c 2 -q '(tcp port 21) or (udp port 9987) or (tcp port 3389) or (udp port 2302)' and dst 192.168.xxx.xxx; then
      ether-wake -b xx:xx:xx:xx:xx:
      sleep 60
    fi
  fi  
done

Ansonsten ist das mit dem "tcpdump" für Interface "any" auch so eine Sache ... da werden alle Interfaces zusammengeworfen und die haben dann vollkommen unterschiedliche Paketformate, womit die Disectoren (die heißen nun mal so) nicht immer klar kommen, gerade auf dem externen Interface, wo bei den meisten DSL-Anschlüssen noch die PPPoE-Kapselung dabei ist.

"-i lan" wäre richtig und eigentlich auch ausreichend, weil das Paket von extern ja ohnehin auf diesem Interface an den "Server" gesendet wird ... dann sieht man auch nur ein einzelnes Paket, denn Euer "-c 2" sieht mir mehr nach "trial and error" aus, weil da mehr als ein Paket (bzw. dasselbe Paket auf mehr als einem Interface) gefunden wird. Wenn es tatsächlich so gewollt ist, daß auch Requests von internen Clients den Server wecken können (so die Pakete über die FRITZ!Box gehen, man weiß ja nicht, wie die Verkabelung ist), dann reicht die Filterangabe ... ansonsten muß man halt noch ein "and not src net 192.168.xxx.0/24" (oder ähnlich) hinzufügen, wenn der Server direkt an der FRITZ!Box angeschlossen ist und man das Wecken von intern nicht haben will.

Und damit wären wir dann auch beim Filterausdruck für tcpdump ... der berücksichtigt die angegebene Adresse nur in Kombination mit dem UDP-Port 2302 - ansonsten weckt jeder beliebige (ordentlich von den Disectoren zerlegte) Verkehr (wenn er auf der FRITZ!Box vorbeikommt) auf Port TCP/21 (FTP), TCP/3389 (RDP, also auch eine aus dem lokalen Netz auf einen Host irgendwo im Internet ausgeführte Sitzung) und jeder Zugriff mit dem TeamSpeak-Client auf einen TS3-Server mit dem Standardport (das ist ja UDP 9987) den Server ebenfalls auf. Die Hochkommata um die Portliste sind zwar nett anzusehen und haben im Kontext eines Shell-Skripts tatsächlich auch eine Bedeutung, aber sie gruppieren keinesfalls irgendwelche Filterausdrücke zu einem einzigen Operanden beim "and" des tcpdump. Auch die Klammern innerhalb der Portliste machen das Ganze zwar vielleicht wirklich lesbarer, aber sie sind im Ergebnis vollkommen überflüssig. Da, wo wirklich Klammern gebraucht würden (nämlich um die gesamte Portliste herum), genau da fehlen sie dann. Ich würde mich also eher wundern, wenn das tatsächlich wie gewünscht funktionieren würde ... außer die beschriebene Auswertung war tatsächlich so beabsichtigt. Dieses Verhalten könnte das FRITZ!OS dann auch tatsächlich nicht "out of the box" bieten ...

Zur Fehlersuche kann man das Skript auch mit "sh -x filename" aufrufen (auch im SheBang könnte man das "-x" noch angeben), dann sieht man bei der Ausführung sofort, warum es bei einem "normalen Aufruf" nicht funktioniert. Wenn die Ursache die falsche erste Zeile (wie offenbar in der ersten Version des Beitrags, jedenfalls enthielt meine Mail die Zeile "#!/bin/sh#in rc.custom kopieren" ohne Umbruch) war (das wäre ein falsches "SheBang"), dann hast Du das ja vielleicht sogar schon korrigiert.

Mehr kann man dazu ohne weitere Angaben einfach nicht sagen ... sowohl der Vorschlag mit dem Packetdump als auch die Nachfragen nach weiteren Einzelheiten, was beim FRITZ!OS-eigenen "auto-wake" nun eigentlich nicht klappen soll, stoßen ja offenbar nicht auf offene Ohren. Damit muß das bisher Geschriebene dann aber auch reichen ... Wiederholungen haben keinen zusätzlichen Wert.

tb2668 · 4 Dez 2015

Das FirtzOS-eigenen auto-wake funktioniert wie gesagt über die GUI, ansonsten nicht.
In diesem Zusammenhang wurde ebenfalls abgehört, was sich im Netzwerk alles abspielt, falls du das mit den Packetdump meinst.
Magic Pakete wurden nur denn verschickt, wenn die GUI genutzt wurde.

Was Shell-Programmierung angeht, ist dies mein erster Versuch. Und der von uns verfasste Code macht tatsächlich was er soll: Leitet die FritzBox ein Paket über eines der angegeben Ports weiter und der Server ist im Sleep Modus, dann wird ein Wol-Paket verschickt. Da ich es aber eleganter finde wie du den Code umgestellt hast, nutze ich nun diesen.
Ich teste das, indem ich mit meinem Handy aus dem mobilen Netz per FTP auf meinen Server zugreife.

Und das "-c 2" ist nicht wirklich trial and error. Hat sich irgendwie so ergeben, und da es vom Effekt egal ist, ob man "-c 1" oder "-c 5" nimmt, sind wir dabei geblieben.
Wie Klammern und Hochkommas beim tcpdump Filter eingesetzt werden, das habe ich dem Wiki von Ubuntuuser entnommen und entsprechend umgesetzt.

Zur Verkabelung: http://i.*******com/HlhbjeJ.jpg

Auf Fehlersuche was das Ausführen von Scripts ohne rc.custom angeht, werde ich mich bei Gelegenheit begeben.

Jedenfalls vielen Dank für deine Zeit, Peter Pawn. Die ganze Thematik ist für mich Neuland und im Moment freue ich mich einfach, dass mein Server startet, wenn er von außerhalb kontaktiert wird. Feinheiten werden nach und nach umgesetzt.

koyaanisqatsi · 4 Dez 2015

Moins

tb2668 schrieb:
Auf Fehlersuche was das Ausführen von Scripts ohne rc.custom angeht, werde ich mich bei Gelegenheit begeben.

Kannst ja mal die Checkpoints durchgehen...
1. Skripte unter Linux (Fritz!Box) haben in der ersten Zeile ein SHEBANG*: #!/bin/sh
2. ...nach chmod +x skript.sh kann es dann im aktuellen Verzeichnis so aufgerufen werden: ./skript.sh
3. Nur wenn das aktuelle Verzeichnis auch im PATH enthalten ist, entfällt das ./ und es reicht von überall: skript.sh
4. Um ein Skript auf Nummer sicher aufzurufen, ohne SHEBANG oder PATH Gedöns den Interpreter (sh) mit vollen Pfad zu skript.sh als Argument benutzen: /bin/sh /var/tmp/skript.sh
...dasselbe (4.) gilt für die im Skript benutzten Kommandos (tcpdump/ether-wake).
Wenn du das Kommando which kennst/hast/benutzt kannst du mal die vollen Pfade sehen (Rudishell), mit:
which tcpdump
which ether-wake

* Das SHEBANG ist unter Linux was die Dateiendung (z.B. .bat) unter MS Windows ist.
Deswegen benötigt ein Skript unter Linux keine Dateiendung, ist nur Zierde, oder zur Identifikation.

PeterPawn · 4 Dez 2015

Zu dem "-c 1" und "-c 5" ... da das die Anzahl der tatsächlich vom Filter selektierten Pakete ist, braucht es bei der zweiten Variante mindestens 5 passende Pakete, bis das "tcpdump" beendet wird. So viele sollten eigentlich bei einem einzigen Versuch des Verbindungsaufbaus nicht auftreten. Solange der anfragende Client nichts wiederholt, bleibt es sogar bei einem einzelnen Paket ... denn der "übliche" 3-Wege-Handshake beim TCP-Protokoll findet ja nur dann statt, wenn da eine Antwort kommt, was bei schlafendem Server nicht der Fall sein dürfte.

Wenn der Filterausdruck sich beim Starten tatsächlich auf die Pakete an die IP-Adresse des Servers beschränken sollte, habe ich die Syntax vollkommen falsch verstanden (ich würde bis 95% Sicherheit mitgehen), nach meinem Dafürhalten steht das für

Code:

(tcp port 21) or (udp port 9987) or (tcp port 3389) or [COLOR="#FF0000"]( [/COLOR](udp port 2302) and dst 192.168.xxx.xxx [COLOR="#FF0000"])[/COLOR]

, während nach der Beschreibung zu urteilen aber

Code:

[COLOR="#FF0000"]([/COLOR] (tcp port 21) or (udp port 9987) or (tcp port 3389) or (udp port 2302) [COLOR="#FF0000"]) [/COLOR]and dst 192.168.xxx.xxx

die richtige Reihenfolge der Auswertung wäre.

Zur Überprüfung müßte es schon reichen, wenn Du eine beliebige ausgehende FTP-Verbindung zu irgendeinem Server startest ... schon diese Pakete (mind. 3 schon mal für den Handshake) sollten eigentlich mitgezählt werden vom "tcpdump", da auch keine Angabe erfolgt, ob der Port sich auf die Ziel- oder die Quell-Adresse bezieht (oder eben auf beide, wenn die Angabe fehlt). Wenn das nicht den Server häufiger weckt als notwendig und erwartet, wäre ich in der Tat sehr verblüfft.

Hilfe beim Skripten für FB7360SL mit Freetz

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

Statistik des Forums