98_WOL: Neue Version zum Testen

[KernSani]

Ja, genau. Dann brauchst nicht für alles ein eigenes Attribut.

Hab ich ja nicht. shutdownCmd gibt es bereits, daran will ich grundsätzlich nichts ändern (Kompatibilität), wolCmd ist neu und realisiert neue Funktionalität. Dazu kommen noch die zwei sshHosts, die man theoretisch natürlich in ein einzelnes Attribut packen könnte. Grundsätzlich halte ich es persönlich aber für übersichtlicher unterschiedliche Attribute für unterschiedliche Funktionalität zu haben als n Dinge in ein Attribut zu packen (wie war das jetzt gleich? Pipe getrennt, Komma getrennt oder doch Doppelpunkt oder vielleicht Leerzeichen? Und kam jetzt wakeup oder shutdown zuerst? ... )

Grüße,

Oli

[KernSani]

Dazu hätte ich noch die Idee, dass man die eventuell fehlenden Broadcast Adresse aus der IP Adresse ableiten kann. Bei all meinen bisherigen Umgebungen und Versuchen schlug eine fehlende Broadcast Adresse für Magic Paket bisher immer fehl - sicher weil dann ein Broadcast an ALLE gemacht wird, den mittlerweile jede Netzwerktechnik verwirft. Also wenn überhaupt, dann geht sowieso nur ein gezielter Broadcast an die richtige Netzwerkadresse.
Wenn die fehlt (weil vom User nicht angegeben) halte ich es für legitim die aus der IP abzuleiten und zu setzen. Immer noch besser als die Aussage "funktioniert nicht"

Die Subnetzmask eines remote Hosts herauszufinden ist aber nicht einfach... Variante 1 wäre generell von /24 auszugehen (einfach), alternativ die netmask vom lokalen (also FHEM) Server zu finden und damit die broadcast-Adresse zu berechnen...

[KernSani]

Angehängte Version fügt nicht mehr automatisch den "sudo hinzu, hat dafür eine Commandref

[Otto123]

Ich wäre für Variante 1  einfach und viel besser als nix

[kadettilac89]

Hallo Oli,

mit ist was aufgefallen. Im SSH-Fall wird das Command nicht an den auszuführenden String gehängt. Zusätzlich, Parameter -T unterdrückt die Warnung "Pseudo-terminal will not be allocated because stdin is not a terminal."

Zeile 324

Code Auswählen Erweitern


        #Enclose SSH command in double quotes
        $sshCmd .= " -T ".$cmd;        <--------------- neu
$sshCmd .= "\"";
        $cmd = $sshCmd;


[KernSani]

ups... da habe ich eine Zeile zuviel auskommentiert

Angepasst, (wie vorgeschlagen mit -T)

und Otto's Vorschlag zur default broadcast-Adresse ist auch umgesetzt.

[kadettilac89]

ups... da habe ich eine Zeile zuviel auskommentiert

Angepasst, (wie vorgeschlagen mit -T)

und Otto's Vorschlag zur default broadcast-Adresse ist auch umgesetzt.

sieht jetzt gut aus.

Danke!

Könntest du bitte noch die Meldung s. u. ausblenden?

Code Auswählen Erweitern


2020.01.11 19:14:39.436 1: Timeout for WOL_Ping reached, terminated process 20791


Nachdem mein Host down ist benötigt der Ping 11 Sekunden. Der Ping hat zwar -w 2 (Dauer 2 Sekunden) aber die Ausführung dauert 11 Sekunden. WArum auch immer. Timeout in Zeile 155 auf Wert 20 müsste das lösen. Oder kann man im Blocking-Aufruf die Meldung abfangen und erst bei verbose 3 ausgeben? Ich habe aktuell jede Minute den Eintrag im Log.

Code Auswählen Erweitern


root@2deff4cbb70f:/opt/fhem# date;ping -c 1 -w 2 192.168.0.26;date
Sa 11. Jan 19:31:56 CET 2020
PING 192.168.0.26 (192.168.0.26): 56 data bytes
--- 192.168.0.26 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
Sa 11. Jan 19:32:07 CET 2020
root@2deff4cbb70f:/opt/fhem#


[KernSani]

Interessant...

Code Auswählen Erweitern


pi@fhem:~ $ date;ping -c 1 -w 2 172.16.4.10;date
Sa 11. Jan 20:07:54 CET 2020
PING 172.16.4.10 (172.16.4.10) 56(84) bytes of data.

--- 172.16.4.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 41ms

Sa 11. Jan 20:07:56 CET 2020



Die Timeout-Meldung kommt jetzt auf level 4.

EDIT: Kleine Anekdote am Rande... Habe gerade festgestellt, dass mein Log voll mit WOL Timeout-Meldungen ist... Schock, was habe ich jetzt wieder verpfuscht? Bis mir die Erkenntnis kam: Ich hatte den timeout auf 1 Sekunde gestellt, um zu testen, ob die Meldung richtig geloggt wird und vergessen, ein reload zu machen, nachdem ich den timeout wieder zurückgestellt hatte

[KernSani]

Wenn keine Einwände kommen, würde ich die Version dann bei Gelegenheit mal im SVN einchecken...

[kadettilac89]

Wenn keine Einwände kommen, würde ich die Version dann bei Gelegenheit mal im SVN einchecken...

ich habe für Wol die SSH-Variante im Einsatz und nichts negatives festgestellt. Habe somit nichts dagegen

[kadettilac89]

Wenn keine Einwände kommen, würde ich die Version dann bei Gelegenheit mal im SVN einchecken...

Darf ich nachfragen, hast du es vergessen, oder gab es die passende Gelegenheit noch nicht?

[KernSani]

Ups... ich fürchte ich habe das vergessen... Shame on me.. kommt heute Abend


Kurz, weil mobil....

[hajo23]

Hallo, ich habe das Modul für meinen HTPC getestet. Offenbar werden die Attribute "sshHost" und "sshHostShutdown" beim Zuweisen der Werte geprüft (s.u.). Das führt allerdings zu dem Problem, dass die Werte bei einem "FHEM-Restart" nicht wieder zugewiesen werden, wenn der HTPC gerade offline ist.

Code Auswählen Erweitern

if ( ( $attrName eq "sshHost" or $attrName eq "sshHostShutdown" ) and $cmd eq "set" ) {
...


VG
Hajo

[kadettilac89]

es ist richtig, es wird geprüft. Wenn du einen Jump-Server verwendet soll der aber auch dauerhaft erreichbar sein, sonst macht die ssh-Config keinen Sinn.

Beim Restart von Fhem wird da aber mMn nicht geprüft, nur beim erstmaligen Anlegen des WOL-Devices.

[hajo23]

...
Beim Restart von Fhem wird da aber mMn nicht geprüft, nur beim erstmaligen Anlegen des WOL-Devices.

Ich bin darauf gekommen, weil das Attribut "sshHostShutdown" bei mir immer wieder nach dem Restart fehlte, obwohl es in der cfg stand. Ich habe es aus der Zeile herausgenommen und nun überlebt es auch den Restart. "sshHost" verwende ich derzeit nicht, aber dafür dürfte das Selbe gelten.

VG
Hajo