98_WOL: Probleme mit Ping und UDP

[vbs]

Ich habe bei mir zwei Probleme mit 98_WOL festgestellt:

• Das Aufwecken per UDP funktioniert bei mir meistens nicht. Ich habe mit tcpdump und etwas Rumprobiererei gemerkt, dass das UDP-Paket von der fhem-Maschine manchmal überhaupt nicht versendet wird und daher das Aufwecken dann eben auch nicht funktioniert. Und zwar wird ja das Paket an die IP des zu weckenden Geräts geschickt. Das Paket wird jedoch nicht rausgeschickt, wenn das zu weckende Gerät noch nie erreichbar war. Sprich bisher immer abgeschaltet war.
  Ich vermute, dass der fhem-Rechner einfach die MAC-Adresse der Ziel-IP gar nicht ermitteln kann per ARP, da er den Rechner noch nie gesehen hat.
  Abhilfe schafft es, das MagicPaket an die Broadcast-Adresse 255.255.255.255 zu senden. Das hat jedoch wiederum den Nachteil, dass das nur im eigenen Subnetz funktioniert.
  Eine Idee wäre, das Verhalten per Attribut konfigurierbar zu machen. Also man kann einstellen, ob das MagicPaket an die Broadcast-Adresse oder direkt an die Ziel-Adresse geschickt werden soll.


• Beim Status-Update wird ja regelmäßig ein Ping gemacht (und vor dem Senden des MagicPacket). Der Ping wird ja synchron in der GetUpdate-Funktion aufgerufen, so dass FHEM in der Zeit hängt. Das führt bei mir jedes Mal zu Hängern zwischen 1 und 2,5 Sekunden.  Ich persönlich bräuchte nichtmal die Anzeige, ob das Geräte gerade pingbar ist. Evtl. könnte man das regelmäßige Pingen per Attribut deaktivierbar machen?

Erstmal Vorschläge meinerseits. Bin für Meinungen offen. Bei Bedarf stelle ich auch gerne einen Patch bereit, der diese Sachen implementiert. Würde das jetzt nur noch nicht vorauseilend machen wollen, da es evtl. ja gar nicht gewünscht ist oder jemand noch bessere Ideen hat.

[Dietmar63]

Bei mir(Fritzbox - > NAS )  kann immer ohne Probleme mit UDP mein NAS wecken und wach halten. Warum es manchmal nicht funktioniert konnte ich nie herausfinden, weil ich weder die konkrete Hardware noch die Möglichkeit hatte den Netzwerkverkehr zu untersuchen.

Der Ping war im Modul enthalten als ich es geerbt habe. Mir war vor allen Dingen wichtig mein NAS damit wach halten zu können.

Für Verbesserungen bin ich immer offen - habe aber wie gesagt nicht die Detailkenntnisse was Netzwerke angeht.

Wenn man das Magic-Paket an die Broadcast Adresse verschickt, werden dann nicht alle Geräte geweckt?

[vbs]

Hi Dietmar,

also wenn man ein IP-Paket (egal ob TCP oder UDP) an eine IP verschickt, dann muss der Netzwerk-Stack des OS erstmal die zugehörige MAC-Adresse des Ziels ermitteln, weil es ja letztlich ein Ethernet-Frame verschicken muss. Das geht über das ARP-Protokoll. Wenn nun aber die Ziel-IP gar nicht erreichbar ist, dann kann daher auch die MAC nicht ermittelt werden und das Paket nicht verschickt werden. Sobald der Sende-PC das Ziel jedoch einmal gesehen hat, dann speichert er die MAC in seinem ARP-Cache. Also ab dann weiß er die MAC. Das geht dann solange, bis der ARP-Cache geleert wird (evtl. nur durch Reboot, weiß nicht genau).

Zu dem Broadcast:
In dem UDP-Paket steht zwar die Broadcast-Adresse (255.255.255.255) als Empfänger jedoch steht ja im Payload des Pakets die MAC, die eigentlich geweckt werden soll. Also es wird dann trotzdem nur das eine Gerät reagieren. Das sollte passen.

Also wenn du nichts dagegen hast, dann würde ich mal ein paar kleine Änderungen vornehmen an dem Modul. Wenn es nicht gefallen sollen, kannst du es dann ja immer noch ablehnen.

[Dietmar63]

Ok,
Du kannst es mir dann als Patch zukommen lassen, dann checke ich es nach einigen Tests bei mir ein.

[Dietmar63]

Hängern zwischen 1 und 2,5 Sekunden.  Ich persönlich bräuchte nichtmal die Anzeige, ob das Geräte gerade pingbar ist. Evtl. könnte man das regelmäßige Pingen per Attribut deaktivierbar machen?

so etwas ist schon vorhanden. Man kann die Pingzeit auf einen beliebigen Wert setzen. Wenn er groß genug ist, findet der dann einmal im Jahr statt. Es gibt aber einige hier, die überprüfen "damit" ob ihr Gerät auch wirklich eingschaltet ist. Deshalb sollte das Standardverhalten so bleiben wie es ist.

Man könnte vielleicht noch 0 als Wert für die Pingzeit zulassen, und festlegen, dass dann nie gepingt wird. 

[Dietmar63]

Abhilfe schafft es, das MagicPaket an die Broadcast-Adresse 255.255.255.255 zu senden. Das hat jedoch wiederum den Nachteil, dass das nur im eigenen Subnetz funktioniert.

Als das modul bei mich nicht richtig lief hatte ich Erfolg mit der Adresse 192.168.1.255 - auch so etwas wie eine Broadcastadresse.
Ich denke die meisten hier wecken mit WOL nur Geräte im eingenen Netz. Das sollte also passen.
Anhand der Adresse des Gerätes und der Adresse(IP) des FHEM sollte man do bestimmt in der Lage sein festzustellen, ob das Gerät außerhalb des eingenen Netzes befindet oder nicht - oder liege ich falsch?

Vielleicht kann man das ja ausnutzen und bei der Erweiterung verwenden.

[vbs]

Es wird aber in jedem Fall bei jedem set-Aufruf gepingt, unabhängig vom Intervall. Was hältst du davon, dieses implizite Update bei jedem set rauszunehmen? Finde das eher ungewöhnlich und ich verstehe den Sinn nicht so ganz. Weißt du, wofür das gut ist?
Das periodische Update könnte man wirklich gut mit interval=0 ausschalten, klingt nach einer sauberen Lösung.

Das mit Broadcast ist prinzipiell ne gute Idee. Ich weiß aber leider nicht, wie man das wasserdicht implementieren könnte. Im Prinzip müsste man die gesamte Routing-Tabelle des Rechners durchgehen und gucken, ob die IP direkt erreichbar ist bzw. über welche Route sie erreichbar wäre. Dann könnte man entsprechend der jeweilige Netzmaske eine passende Ziel-Broadcast-IP wählen. Ist evtl. recht aufwändig. Oder gibts da schon was fertiges in Perl? Würde das im ersten Schuss erstmal mit einem Attribut useBroadcast ja/nein machen, denk ich.

[Dietmar63]

Es wird aber in jedem Fall bei jedem set-Aufruf gepingt, unabhängig vom Intervall. Was hältst du davon, dieses implizite Update bei jedem set rauszunehmen? Finde das eher ungewöhnlich und ich verstehe den Sinn nicht so ganz. Weißt du, wofür das gut ist?

Das kann ich dir sagen. Ich meine es ist deshalb darin, dass man sofort nach dem Start sehen kann, dass das Gerät angeschaltet ist(bin mir wg. der Zeitverzögerung nicht mehr ganz sicher). DAs war aber der einzige Grund. Ich halte den ping auch für überbewertet. Es soll  aber hier fhemler geben, die nutzen WOL irgendwie wie Presence.

Das mit Broadcast ist prinzipiell ne gute Idee. Ich weiß aber leider nicht, wie man das wasserdicht implementieren könnte. Im Prinzip müsste man die gesamte Routing-Tabelle des Rechners durchgehen und gucken, ob die IP direkt erreichbar ist bzw. über welche Route sie erreichbar wäre.

reicht da nicht die einfache Variante. Ich hätte einfach gedacht, wenn 192.168.2.34 das Ziel ist, dass ist ein Rechner im gleichen Netz einer mit 192.168.2.xxx. Alles andere ist fremdes Netz - genau genommen muss man noch die Subnetzmaske einrechnen. Routingtabelle ist so kompliziert, dass es nicht lohnt.

Würde das im ersten Schuss erstmal mit einem Attribut useBroadcast ja/nein machen, denk ich

So sollten wir es erst einmal machen. Aufwand gering - dann bitte aber wie überall in fhem  useBroadcast 1/0.

[vbs]

Das kann ich dir sagen. Ich meine es ist deshalb darin, dass man sofort nach dem Start sehen kann, dass das Gerät angeschaltet ist(bin mir wg. der Zeitverzögerung nicht mehr ganz sicher). DAs war aber der einzige Grund. Ich halte den ping auch für überbewertet. Es soll  aber hier fhemler geben, die nutzen WOL irgendwie wie Presence.

Versteh ich nicht so ganz... Wäre das nicht eher die define-Funktion? Da ist es ja auch drin und das verstehe ich ja auch (für direkt nach dem Start). Evtl. steh ich jetzt auf dem Schlauch, aber warum das bei jedem set passiert, ist mir noch nicht klar.

reicht da nicht die einfache Variante. Ich hätte einfach gedacht, wenn 192.168.2.34 das Ziel ist, dass ist ein Rechner im gleichen Netz einer mit 192.168.2.xxx. Alles andere ist fremdes Netz - genau genommen muss man noch die Subnetzmaske einrechnen. Routingtabelle ist so kompliziert, dass es nicht lohnt.
So sollten wir es erst einmal machen. Aufwand gering - dann bitte aber wie überall in fhem  useBroadcast 1/0.

Klar, 0/1. Hm, aber selbst ohne Routing-Tabelle ists nicht so einfach, oder? Der Rechner kann ja mehrere Netzwerkinterfaces mit jeweils mehreren IPs dauf haben. Welche nimmt man her als Kriterium?

[Dietmar63]

kann ja mehrere Netzwerkinterfaces

bei mir recht selten - hätte ich übersehen. Mach es mit useBroadcast 1/0.

[vbs]

So, anbei mal ein konkreter Vorschlag. Folgende Sachen habe ich geändert:

• neues Attribute useUdpBroadcast
• wenn Interval 0 ist, dass wird nicht mehr gepingt
• beim Aufruf von set wird nicht mehr gepingt (außer natürlich bei "set refresh")
• bin mir unsicher, ob das gut ist: Habe das Internal INTERVAL rausgenommen, weil es mir einfach wie eine Doppelung des Interval-Attributs aussah. Ich wollte auch gerne den Default von 900 nur einemal im Code stehen haben

[Dr. Boris Neubert]

Hallo,

wake_by_udp() und etherwake nehmen auch die MAC-Adresse. Wäre es nicht das einfachste, darauf aufzubauen und die MAC-Adresse in der FHEM-Konfiguration hart zu verdrahten?

Dass Ping blockiert ist schädlich und stört mich auch. Ich habe mir eine Überwachung für 10 Rechner im LAN gebaut, die auf dieser Basis FHEM total lahmlegen würde. Es gibt aber die Möglichkeit, die Antwort asynchron auszuwerten. Ich spende hier mal den relevanten Code aus meinem netmon.pl in der Hoffnung, dass er in 98_WOL Eingang findet.

Viele Grüße
Boris

Code Auswählen Erweitern

sub checkHosts() {
  my $p= Net::Ping->new("syn",1);
  $p->hires();

  my @result;

  # SYN
  foreach my $tag (keys %config) {
my ($name, $hostname, %item)= getItem($tag);
next unless defined($item{port});
  my $port= $item{port};
my $timeout= ( defined($item{timeout}) ? $item{timeout} : 1 );
$p->port_number($port);
$p->ping($hostname, $timeout);
  }

  # ACK
  foreach my $tag (keys %config) {
my ($name, $hostname, %item)= getItem($tag);
next unless defined($item{port});
eval {
if(my ($h,$rtt,$ip)= $p->ack($hostname)) {
    push @result, sprintf("reachable %s yes\n", $name);
    #push @result, sprintf("rtt %s %.3f ms\n", $name, $rtt*1000.0);
    push @result, sprintf("msg %s ok\n", $name);
        } else {
    push @result, sprintf("reachable %s no\n", $name);
    push @result, sprintf("msg %s %s\n", $name, $p->nack($hostname));
}       
};
if($@) {
push @result, sprintf("msg %s %s\n", $name, "error"); # $@
}
  }

  $p->close();

  return @result;
}



[Dietmar63]

@Boris:
ich versuche das mal zu verstehen und zu integrieren.

[Dietmar63]

ich habe es verstanden - baue es ein.

[Dietmar63]

@Boris:
ich habe bei mir mal die Zeiten für den ping in WOL gemessen:

Code Auswählen Erweitern


2015.01.11 11:52:31 3: tim for ping----------->-0.0210690498352051
2015.01.11 11:49:19 3: tim for ping----------->-0.0131900310516357
2015.01.11 11:47:31 3: tim for ping----------->-0.0203368663787842
2015.01.11 11:44:19 3: tim for ping----------->-0.013463020324707
2015.01.11 11:42:30 3: tim for ping----------->-0.0193901062011719
2015.01.11 11:39:19 3: tim for ping----------->-0.0162630081176758
2015.01.11 11:37:30 3: tim for ping----------->-0.0234019756317139
2015.01.11 11:34:19 3: tim for ping----------->-0.0129461288452148
2015.01.11 11:32:30 3: tim for ping----------->-0.0204808712005615
2015.01.11 11:29:19 3: tim for ping----------->-0.0170819759368896
2015.01.11 11:27:30 3: tim for ping----------->-0.0175931453704834


das ist eingentlich nicht der Rede Wert. Warum dauert es anderswo scheinbar solange?