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.
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?
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.
Ok,
Du kannst es mir dann als Patch zukommen lassen, dann checke ich es nach einigen Tests bei mir ein.
ZitatHä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.
ZitatAbhilfe 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.
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.
ZitatEs 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.
ZitatDas 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.
ZitatWü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.
Zitat von: Dietmar63 am 10 Januar 2015, 19:06:10
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.
Zitat von: Dietmar63 am 10 Januar 2015, 19:06:10
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?
Zitatkann ja mehrere Netzwerkinterfaces
bei mir recht selten - hätte ich übersehen. Mach es mit useBroadcast 1/0.
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
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
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;
}
@Boris:
ich versuche das mal zu verstehen und zu integrieren.
ich habe es verstanden - baue es ein.
@Boris:
ich habe bei mir mal die Zeiten für den ping in WOL gemessen:
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?
Hallo,
wenn die Maschine NICHT erreichbar ist, dauert es bis zum Timeout.
Viele Grüße
Boris
Aha,
danke - bei mir ist das NAS immer erreichbar. Deshalb ärgere ich mich nicht darüber und habe auch nicht die Notwendigkeit gesehen es zu verbessern.
Sollte man die ganzen komplizierten Umsetzungen mit BlockingCall nicht auch auf diese viel einfachere Variante umbauen. Mit BlockingCall habe ich mich auch mal abgequält.
Könntest du den Code mal bitte zeigen, wie das jetzt aussieht? Du musst ja der Gegenstelle weiterhin eine gewisse Antwortzeit einräumen (üblicherweise 1 Sekunde). Also ohne fork kann ich mir gar nicht vorstellen, wie man das mit einem einzigen Funktionsaufruf non-blocking implementieren könnte. Um einen "richtigen" Ping handelt es sich dabei ohnehin nicht mehr, so wie ich das verstehe.
Meine bescheidene Meinung: Mit dem PRESENCE-Modul existiert Code, der einen echten ICMP-Ping non-blocking ausführt und genau dafür gemacht wurde. Ein Teil des Codes in WOL reimplementiert damit ja Teile des PRESENCE-Moduls. Ich persönlich würde die ganzen Ping-Sachen aus WOL rausnehmen, ehrlich gesagt. Wer Ping- bzw. Presence-Funktionalität benötigt, der möge das PRESENCE-Modul nehmen und wer Wake-On-LAN braucht, der soll das WOL-Modul nehmen. Ist aber vermutlich eine eher kontroverse Position meinerseits :)
Ich bin noch in der Experimentierphase(padre).
a) man pingt den host mit $p->ping($hostname, $timeout); an.
b) setzt eines Timers mit einer neuen Auswertfunktion nach (timeout+1) Sekunden.
c) in der Auswertfunktion werden die ACKs und nACKs ausgewertet und die Readings versorgt:
# ACK
while (($host,$rtt,$ip) = $p->ack() ) {
print "HOST: $host [$ip] ACKed in $rtt seconds.\n";
}
foreach $hostname (@hosts) {
my $nack = $p->nack($hostname);
if ($nack) {
print "msg $hostname $nack\n";
}
}
@Boris
wäre das so richtig?
Zitat von: Dietmar63 am 11 Januar 2015, 13:51:16
wäre das so richtig?
So würde man das in FHEM typischerweise(R) tun.
Ich habe gerade nachgesehen, ob Net::Ping Callbacks unterstützt, tut es aber nicht. Schade.
Kürzlich wurde AnyEvent im Developer-Board vorgestellt. Schien mir sehr vielversprechend. Man schreibt damit sehr sauberen Code. Vielleicht eine Option?
Grüße
Boris
Callbacks braucht man nicht.
man kann es so machen:
################################################################################
sub WOL_UpdateReadings($) {
my ($hash) = @_;
my $timeout = 2;
my $ping = Net::Ping->new("syn",1);
$ping->hires();
$ping->ping($hash->{IP}, $timeout);
$hash->{ping} = $ping;
InternalTimer(gettimeofday()+$timeout, "WOL_UpdateReadingsCallback", $hash, 0);
}
################################################################################
sub WOL_UpdateReadingsCallback() {
my ($hash) = @_;
my $name = $hash->{NAME};
my $ping = $hash->{ping};
readingsBeginUpdate ($hash);
if (my ($host,$rtt,$ip) = $ping->ack($hash->{IP})) {
Log3 $hash, 3, "HOST: $host [$ip] xACKed in $rtt seconds";
Log3 $hash, 5, "[$name] ping succesful - state = on";
readingsBulkUpdate ($hash, "isRunning", "true");
readingsBulkUpdate ($hash, "state", "on");
} else {
Log3 $hash, 5, "[$name] ping not succesful - state = on";
readingsBulkUpdate ($hash, "isRunning", "false");
readingsBulkUpdate ($hash, "state", "off");
}
$ping->close(); delete $hash->{ping};
readingsEndUpdate($hash, defined($hash->{LOCAL} ? 0 : 1));
WOL_SetNextTimer($hash);
}
Leider funktioniert genau das auf der FB nicht:
in Zeile:
my $p= Net::Ping->new("syn",1);
kommt die Fehlermeldung:
Can't get tcp echo port by name at ./FHEM/98_WOL.pm line 130
my $p= Net::Ping->new("syn");
my $p= Net::Ping->new();
funktionieren auch nicht.
Zitat von: Dietmar63 am 11 Januar 2015, 15:16:24
Leider funktioniert genau das auf der FB nicht:
in Zeile:
my $p= Net::Ping->new("syn",1);
kommt die Fehlermeldung:
Can't get tcp echo port by name at ./FHEM/98_WOL.pm line 130
my $p= Net::Ping->new("syn");
my $p= Net::Ping->new();
funktionieren auch nicht.
Fritten sind in Bezug auf FHEM sterbende Systeme. Willst Du das wirklich unterstützen?
Das Problem sitzt in der Fritte, vermutlich ist der Port in /etc/services nicht definiert und dann schlägt getservbyname() fehl.
Mit etwas Arbeit kannst Du vielleicht eine Klasse von Net::Ping ableiten, die getservbyname() durch etwas hartkodiertes ersetzt.
Viele Grüße
Boris
ZitatFritten sind in Bezug auf FHEM sterbende Systeme. Willst Du das wirklich unterstützen?
...
Mit etwas Arbeit kannst Du vielleicht eine Klasse von Net::Ping ableiten, die getservbyname() durch etwas hartkodiertes er
Das scheint mir sehr viel Neuland zu werden. Dazu habe ich keine Zeit und außerdem sollte es dann einfacher sein
BlockingCall() aufzurufen, zumal es dazu viel Doku gibt.
Ich habe mich entschieden mal schnell BlockingCall() in WOL einzubauen.
Kann das mal jemand reviewen. Es scheint bei mir zu funktionieren.
################################################################################
sub WOL_Undef($$) {
my ($hash, $arg) = @_;
RemoveInternalTimer($hash);
BlockingKill($hash->{helper}{RUNNING_PID}) if(defined($hash->{helper}{RUNNING_PID}));
return undef;
}
################################################################################
################################################################################
################################################################################
sub WOL_UpdateReadingsX($) {
my ($hash) = @_;
my $blockingFn = "WOL_Ping";
my $arg = $hash->{NAME}."|".$hash->{IP};
my $finishFn = "WOL_PingDone";
my $timeout = 3;
my $abortFn = "WOL_PingAbort";
$hash->{helper}{RUNNING_PID} =
BlockingCall($blockingFn, $arg, $finishFn, $timeout, $abortFn, $hash)
unless(exists($hash->{helper}{RUNNING_PID}));;
}
################################################################################
sub WOL_Ping($){
my ($string) = @_;
my ($name, $ip) = split("\\|", $string);
my $hash = $defs{$name};
my $ping = "ping -c 1 -w 2 $ip";
my $res = qx ($ping);
$res = "" if (!defined($res));
Log3 $hash, 5, "[$name] executing: $ping";
my $erreichbar = !($res =~ m/100%/);
my $return = "$name|$erreichbar";
return $return;
}
################################################################################
sub WOL_PingDone($){
my ($string) = @_;
my ($name, $erreichbar) = split("\\|", $string);
my $hash = $defs{$name};
readingsBeginUpdate ($hash);
if ($erreichbar) {
Log3 $hash, 5, "[$name] ping succesful - state = on";
readingsBulkUpdate ($hash, "isRunning", "true");
readingsBulkUpdate ($hash, "state", "on");
} else {
Log3 $hash, 5, "[$name] ping not succesful - state = on";
readingsBulkUpdate ($hash, "isRunning", "false");
readingsBulkUpdate ($hash, "state", "off");
}
readingsEndUpdate($hash, defined($hash->{LOCAL} ? 0 : 1));
delete($hash->{helper}{RUNNING_PID});
WOL_SetNextTimer($hash);
}
################################################################################
sub WOL_PingAbort($){
my ($hash) = @_;
delete($hash->{helper}{RUNNING_PID});
Log3 $hash->{NAME}, 3, "BlockingCall for ".$hash->{NAME}." was aborted";
WOL_SetNextTimer($hash);
}
@vbs:
BlockingCall() scheint bei mir für den Ping zu funktionieren.
Es gibt aber ein Problem mit der neuen Funktion useUdpBroadcast. Ich kann nicht sagen, dass es falsch läuft, aber bei mir funktioniert der WOL nicht mit der Broardcast-Adresse 255.255.255.255.
Ich konnte mich noch daran erinnern, dass ich es einmal vor langer Zeit mit 192.168.2.255 geschafft habe - so etwas wie die kleine Broardcast-Adresse.
Ich schlage vor, dass wir das Attribut dahingehend verändern sollten, dass man die Broardcast-Adresse an sich vorgeben kann. Dann haben wir größtmögliche Flexibilität:
attr NAS useUdpBroadcast 255.255.255.255
attr NAS useUdpBroadcast 192.168.2.255
Was hältst du davon? Kannst du dir das Verhalten bei mir erklären?
Also gut erklären kann ich es nicht. Aber nach nochmaliger Googelei folgendes herausgefunden:
255.255.255.255 ist ein Broadcast der implizit das eigene Netz meint. Also im Endeffekt auch 192.168.2.255. Hab aber wieder keine Ahnung, welches das "eigene Netz" sein soll, wenn man mehrere IPs hat. Entweder spielt da auch das OS rein, bei der Entscheidung wie es rausgeschickt wird, oder es liegt sogar am Endgerät, ob dann letztendlich auf das WOL-Paket reagiert wird, oder nicht.
Wie auch immer:
Genau erklären kann ich es nicht, aber ich finde die Idee sehr gut, die ganze Adresse per Attribut konfigurierbar zu machen.
Jedoch halte ich mehr und mehr das Schicken an die tatsächliche Ziel-Adresse (zB 192.168.0.27) für nicht gut. Ich denke, da sind Probleme vorprogrammiert (wegen dem genannten ARP-Problem). Alle Stellen, die ich jetzt nochmal gelesen habe bzgl. WOL reden auch immer nur von Broadcast-Adressen (also 192.168.0.255 oder auch 255.255.255.255). Ist die Frage, was man stattdessen macht. Eventuell 255.255.255.255 als default und ansonsten muss es der User konfigurieren?
(Auch interessant: http://search.cpan.org/~tequeter/Net-Route-v0.02/lib/Net/Route/Table.pm)
ZitatJedoch halte ich mehr und mehr das Schicken an die tatsächliche Ziel-Adresse (zB 192.168.0.27) für nicht gut. Ich denke, da sind Probleme vorprogrammiert (wegen dem genannten ARP-Problem). Alle Stellen, die ich jetzt nochmal gelesen habe bzgl. WOL reden auch immer nur von Broadcast-Adressen (also 192.168.0.255 oder auch 255.255.255.255). Ist die Frage, was man stattdessen macht. Eventuell 255.255.255.255 als default und ansonsten muss es der User konfigurieren?
dann würde ich 192.168.0.255 als Standard vorschlagen, weil ich irgendwo gelesen hatte, dass dies die Broadcast-Adressen des eigenen lokalen Netzes(class C) ist.
Genau müsste es so sein(vermute ich):
IP bitweisesOR ( bitweisesNOT subnetzmask) sein.
192.168.0.27 bitweisesOR ( bitweisesNOT 255.255.255.0) --->>> 192.168.0.255.
Probier mal, ob bei dir folgende IP funktioniert: also 192.168.0.255
Je nach Größe des Netzes ist die Subnetzmask unterschiedlich 255.255.255.0 255.255.0.0 oder 255.0.0.0
255.255.255.255 ist mir zu gefährlich, a) weil es bei mir schon nicht funktioniert und b) ich dann viele Tickets erwarte.
Also bei 192.168.0.255 setzt das ja voraus, dass die Leute als Netz 192.168.0.x nutzen. Das passt auf mich schonmal nicht und ich kenne auch einige andere Leute die 192.168.1.2 oder auch 192.168.2.x nutzen. Das wäre dann schon eine recht spezieller Default...
Ich hab keine Ahnung bei wievielen Leuten 255.255.255.255 funtkionieren würde, aber es wäre immerhin generisch. Plan B wäre sonst echt nur das Auslesen der Routing-Tabelle fürchte ich :( Hab gerade keine gute Idee...
so müßste man es machen:
Das ist eine Formel(Varialblen in Rot):
IP bitweisesOR ( bitweisesNOT subnetzmask)
192.168.0.27 bitweisesOR ( bitweisesNOT 255.255.255.0) --->>> 192.168.0.255.
192.168.1.27 bitweisesOR ( bitweisesNOT 255.255.255.0) --->>> 192.168.1.255.
192.168.2.27 bitweisesOR ( bitweisesNOT 255.255.255.0) --->>> 192.168.2.255.
ZitatDie meisten Router erzeugen einen Ethernet-Broadcast, wenn sie ein Paket an die IP-Broadcast-Adresse weiterleiten sollen. Dies ist immer die höchste Adresse im lokalen Subnetz und hängt daher von der Netzmaske ab. In einem typischen Netz mit der Netzmaske 255.255.255.0 wäre dies zum Beispiel die 192.168.1.255. Der IP-Stack des Routers setzt diesen IP-Broadcast dann in einen Ethernet-Broadcast um, und das Paket erreicht alle PCs im LAN. Eine Umleitung eines UDP-Ports des Routers auf die interne Broadcast-Adresse macht das ankommende UDP-Paket zu einem Ethernet-Frame, den alle Rechner im LAN erhalten.
http://www.heise.de/netze/artikel/Port-Forwarding-224180.html (http://www.heise.de/netze/artikel/Port-Forwarding-224180.html)
Hm Ok, aber das wussten wir ja schon, oder? Meinst du etwas bestimmtes?
eingecheckt.
nun mit BlockingCall()
und
attr <name> interval <seconds>
defines the time between two checks by a ping if state of <name> is on. By using 0 as parameter for interval you can switch off checking the device.
attr <name> useUdpBroadcast <>
When using UDP then the magic packet can be send to one of the broardcastAdresses (x.x.x.255, x.x.255.255, x.255.255.255) instead of the target host address. Try using this, when you are trying to wake up a machine in your own subnet and the wakekup with the target adress is instable or doesn't work.
Seit meinem letzten Update habe ich Logeinträge von WOL:
2015.01.21 14:24:25 1: Timeout for WOL_Ping reached, terminated process 15915
2015.01.21 14:24:25 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.21 14:40:48 1: Timeout for WOL_Ping reached, terminated process 16735
2015.01.21 14:40:48 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.21 14:51:53 1: Timeout for WOL_Ping reached, terminated process 17324
2015.01.21 14:51:53 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.21 15:18:48 1: Timeout for WOL_Ping reached, terminated process 18729
2015.01.21 15:18:48 3: BlockingCall for t5.wol.pc1 was aborted
Was muss ich an meiner (Standard) Konfig ändern um im Log Ruhe zu haben ?
define computer1 WOL 72:11:AC:4D:37:13 192.168.0.24 EW
Setze mal verbose auf 5 und Poste den Output.
Als Hardware verwendest du einen Cubietruck?
Nutzt du das Weathermodul? Es hat auch BlockingCall () im Bauch. Wenn du es nicht verwendest kannst du es Testweise einbauen?
Mit attr interval 0 kannst du die pings abschalten.
prüf bitte mal, ob auf dem Cubi folgender Befehl funktioniert:
ping -c 1 -w 2 192.1.168.xxx
mal mit einer Adresse, dei es in deinem Netzwerk gibt und einmal mit einer Adresse, die es nicht gibt.
Cubietruck, Ja
Weathermodul, Ja
Ping:
root@haus ~ > ping -c 1 -w 2 192.168.0.50
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.
--- 192.168.0.50 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms
verbose 5:
2015.01.21 22:03:17 5: [t5.wol.pc2] executing: ping -c 1 -w 2 192.168.0.105
2015.01.21 22:03:17 5: [t5.wol.pc2] ping not succesful - state = off
2015.01.21 22:03:17 5: [t5.wol.pc2] WOL_SetNextTimer to 30
2015.01.21 22:03:17 5: [t5.wol.pc2] removing Timer: t5.wol.pc2_ping
2015.01.21 22:03:17 5: [t5.wol.pc2] setting Timer: t5.wol.pc2_ping 21.01.2015 22:03:47
2015.01.21 22:03:49 5: [t5.wol.pc2] executing: ping -c 1 -w 2 192.168.0.105
2015.01.21 22:03:49 5: [t5.wol.pc2] ping not succesful - state = off
2015.01.21 22:03:49 5: [t5.wol.pc2] WOL_SetNextTimer to 30
2015.01.21 22:03:49 5: [t5.wol.pc2] removing Timer: t5.wol.pc2_ping
2015.01.21 22:03:49 5: [t5.wol.pc2] setting Timer: t5.wol.pc2_ping 21.01.2015 22:04:19
2015.01.21 22:04:21 5: [t5.wol.pc2] executing: ping -c 1 -w 2 192.168.0.105
2015.01.21 22:04:21 5: [t5.wol.pc2] ping not succesful - state = off
2015.01.21 22:04:21 5: [t5.wol.pc2] WOL_SetNextTimer to 30
2015.01.21 22:04:21 5: [t5.wol.pc2] removing Timer: t5.wol.pc2_ping
2015.01.21 22:04:21 5: [t5.wol.pc2] setting Timer: t5.wol.pc2_ping 21.01.2015 22:04:51
sind diese Meldungen nun verschwunden, oder kommen sie sporadisch?
2015.01.21 14:24:25 1: Timeout for WOL_Ping reached, terminated process 15915
2015.01.21 14:24:25 3: BlockingCall for t5.wol.pc1 was aborted
Sporadisch. 1,2 mal in der Stunde.
Dann lass mal laufen, und liefere den Output wenn der Fehler kommt.
Wieder im Log:
2015.01.22 15:08:50 1: Timeout for WOL_Ping reached, terminated process 15252
2015.01.22 15:08:50 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.22 15:22:38 3: CUL_HM set t5.bz.di1_Sw 30 300 0
2015.01.22 15:33:17 1: Timeout for WOL_Ping reached, terminated process 16394
2015.01.22 15:33:17 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.22 15:35:59 1: Timeout for WOL_Ping reached, terminated process 16502
2015.01.22 15:35:59 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.22 15:42:42 1: Timeout for WOL_Ping reached, terminated process 16754
2015.01.22 15:42:42 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.22 15:46:44 1: Timeout for WOL_Ping reached, terminated process 17016
2015.01.22 15:46:44 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.22 16:10:53 3: CUL_HM set t5.bz.di1_Sw 30 300 0
2015.01.22 16:14:08 1: Timeout for WOL_Ping reached, terminated process 18164
2015.01.22 16:14:08 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.22 16:27:45 1: Notify: LED On Wohnzimmer
2015.01.22 16:27:45 3: CUL_HM set t5.wz.sd2_Sw on-for-timer 1800
2015.01.22 16:27:46 1: Kamera-Alarm: Aus (Anwesend)
2015.01.22 16:27:46 3: CUL_HM set t5.ku.sd2_Sw on
2015.01.22 16:27:46 3: CUL_HM set t5.wz.sd2_Sw on
2015.01.22 16:27:46 1: DOIF: LED Ein
2015.01.22 16:27:46 3: CUL_HM set t5.fl.di1_Sw 25 25 0
2015.01.22 16:28:22 3: CUL_HM set t5.fl.di1_Sw 25 25 0
2015.01.22 16:42:26 1: Timeout for WOL_Ping reached, terminated process 19460
2015.01.22 16:42:26 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.22 16:42:34 1: Timeout for WOL_Ping reached, terminated process 19468
2015.01.22 16:42:34 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.22 16:55:28 1: Timeout for WOL_Ping reached, terminated process 20062
2015.01.22 16:55:28 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.22 16:55:54 1: Timeout for WOL_Ping reached, terminated process 20072
2015.01.22 16:55:54 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.22 17:01:18 1: Timeout for WOL_Ping reached, terminated process 20399
2015.01.22 17:01:18 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.22 17:01:23 1: Timeout for WOL_Ping reached, terminated process 20402
2015.01.22 17:01:23 3: BlockingCall for t5.wol.pc2 was aborted
2015.01.22 17:06:11 3: CUL_HM set t5.fl.di1_Sw 25 25 0
2015.01.22 17:08:20 1: Kamera-Alarm: Aus (Terrasse wurde geöffnet)
2015.01.22 17:15:18 1: Timeout for WOL_Ping reached, terminated process 21041
2015.01.22 17:15:18 3: BlockingCall for t5.wol.pc1 was aborted
2015.01.22 17:20:12 1: Timeout for WOL_Ping reached, terminated process 21227
2015.01.22 17:20:12 3: BlockingCall for t5.wol.pc2 was aborted
Ich habe ein kleine Veränderung vorgenommen, und eingecheckt.
Prüf bitte mal, ob eine Besserung erkennbar ist.
Vielen Dank, werde berichten.
Und, wie sieht es aus?
Sehr Gut, keine PING-Einträge mehr im Log. :-)
Ok, Ich habe dem Blocking Modul eine Sekunde mehr Zeit eingeräumt.
Wenn du den Status des Gerätes nicht benötigst kannst du den Ping mit interval 0 komplett abschalten.