Formattierung der MAC Adresse für WakeOnLan

[Dostal]

Lösung nur mit Miniserver

[Pippo74]

Just One Virtual Output with wol:// command and multiple PCs ? There are no problem iaddressing same command to many different MACs ?

For which purpose POST is used as HTTP method ?

Thanks a lot!

[Dostal]

No idea why it works with POST, but it is
And yes, it works exactly as shown in the screenshot

best regards

[Jan W.]

This is really strange, that the HTTP method should make a difference, because WoL does not send any HTTP packet. Unfortunately the creator of the thread has not send any wireshark packet captures so far.

[t_heinrich]

Hallo,

also die Idee mit "POST" habe ich probiert, hat allerdings (wie einige vermutet haben) keine Auswirkungen gehabt.

Mit WireShark habe ich noch nie gearbeitet, erinnere mich, dass ich das mal vor Ewigkeiten getestet habe und dann verworfen habe, weil ich nicht mit zurecht kam.
Auch die vorgeschlagene hardwaretechnische Verkabelung wird schwer, da die Geräte in verschiedenen Räumen stehen.

Zumindest kann ich das nicht so einfach mal testen.

Ich frage mich mal wieder, wieso etwas (hier FritzBox und einer App am Mac) sofort funktionniert und bei Loxone nicht.

[svethi]

Ich kann nur wieder sagen, dass ich das auch schon oft genug hatte, dass bestimmte Tools bestimmte Geräte nicht schalten konnten

[Jan W.]

t_heinrich Wireshark ist sicherlich nichts für Laien, aber wer bereits x Stunden Zeit mit Testen aller denkbaren Varianten "verplempert" hat, findet mit Wireshark ein Tool mit dem man schnell die Ursache für Probleme ermitteln kann.

Es geht sogar einfacher, als ich zunächst dachte: WoL Pakete sind Broadcasts im lokalen Netzwerk, d.h. Du musst an Deiner Verkabelung gar nichts ändern. Jeder (Layer 2-)Switch leitet solche Broadcasts weiter. Du kannst Daher auch auf Deinem Mac die Pakete aufzeichnen - solange alle Geräte im gleiche VLAN bzw. IP-Subnetz sind.

Ein Beispiel habe ich angehängt. Ist zwar etwas komplizierter, als bei der Werbung mit dem "Goldfinger", aber sicherlich leichter, als mit Loxone Config umzugehen.

[svethi]

Du kannst mit der Fritzbox den Netzwerkverkehr mitschneiden und diese Datei dann im Wireshark einlesen. Wenn Du mit dem Wireshark nicht zurecht kommst, würde Dir sicher jemand bei der Analyse helfen.

[svethi]

Geht das denn jetzt mit jeder Karte? Ich weiß von früher noch, dass das nicht mit jeder Netzwerkkarte geht.

[Jan W.]

Als MacBook User kann ich das für Windows nicht genau sagen. Mit einem Mac (hat der TE wohl auch) funktioniert das Capture sowohl für WLAN als auch LAN Adapter ohne Probleme.

Mit Windows ging es - zumindest früher - nur mit Netzwerkkarten, die den Promiscous Mode konnten, das waren die meisten LAN Karten. Mit WLAN Karten ging es generell nicht, weil die Firma, die den WinPCAP Treiber entwickelt hatte, die eigene AirPCAP USB WLAN Karte verkaufen wollte.

[svethi]

Ja, irgendwie so war das damals ;-)

[Jan W.]

Hab mal einen Beitrag in der Loxwiki zum Thema Wireshark erstellt: Was macht mein Loxone Miniserver im Netzwerk?, da es dann einfach ist, auf den Beitrag zu verlinken.

Wireshark ist nicht nur bei WoL hilfreich, sondern bei vielen anderen Problemen mit der Kommunikation über TCP/IP. Ich habe mit dem Tool z.B. die Modbus/TCP Kommunikation zwischen einem Tool und meiner Helios Lüftungsanlage mitgeschnitten, um dann ein passendes Pico-C Skript für den Miniserver programmieren zu können.

Auch bei der Analyse der SIP Kommunikation zwischen Miniserver, App und meiner selbstgebauten Türsprechanlage war Wireshark sehr hilfreich für das Verständnis, wer mit wem wie kommuniziert.

[t_heinrich]

Jan W. wow erstmal klasse Idee mit dem Wiki-Artikel, dass ist wirklich sehr hilfreich und macht (teilweise) richtig Spaß mal etwas genauer zu schauen, was im eigenen Netzwerk so passiert.
Konkret für mein Thema WOL, bin ich allerdings nicht wirklich weitergekommen.

Wenn ich nach WOL filtere, sehe ich den Befehl von der FritzBox, aber nichts vom Miniserver (führe den Befehl per Webinterface am Miniserver aus):

[B]"wol"[/B]
No. Time Source Destination Protocol Length Info
112 8.368456 AVMAudio_67:f7:c5 Broadcast WOL 116 MagicPacket for SamsungE_28:09:8d (d0:d0:03:28:09:8d)

Wenn ich nur nach der Mac Adresse vom Miniserver filtere erhalte ich das; sehe also eigentlich gar nichts.

[B]"eth.src == 50:4F:94:10:9B:1F"[/B]
No. Time Source Destination Protocol Length Info
20 1.805921 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=1 Ack=16 Win=59120 Len=10
22 2.838713 LoxoneEl_10:9b:1f Broadcast ARP 60 Who has 192.168.1.116? Tell 192.168.1.82
24 2.941117 LoxoneEl_10:9b:1f Broadcast ARP 60 Who has 192.168.1.116? Tell 192.168.1.82
32 3.660776 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=11 Ack=16 Win=59120 Len=10
33 3.660783 192.168.1.82 192.168.1.105 TCP 226 80 → 57550 [PSH, ACK] Seq=21 Ack=16 Win=59120 Len=172
54 4.792242 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=193 Ack=31 Win=59120 Len=10
109 7.766732 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=203 Ack=46 Win=59120 Len=10
196 9.302156 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=213 Ack=46 Win=59120 Len=10
197 9.302159 192.168.1.82 192.168.1.105 TCP 80 80 → 57550 [PSH, ACK] Seq=223 Ack=46 Win=59120 Len=26
305 10.765250 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=249 Ack=61 Win=59120 Len=10
341 12.772588 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=259 Ack=76 Win=59120 Len=10
389 13.900209 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=269 Ack=76 Win=59120 Len=10
390 13.900214 192.168.1.82 192.168.1.105 TCP 96 80 → 57550 [PSH, ACK] Seq=279 Ack=76 Win=59120 Len=42
414 14.777966 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=321 Ack=91 Win=59120 Len=10
435 15.423352 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=331 Ack=147 Win=59120 Len=10
436 15.423355 192.168.1.82 192.168.1.105 TCP 160 80 → 57550 [PSH, ACK] Seq=341 Ack=147 Win=59120 Len=106
440 15.533718 192.168.1.82 192.168.1.105 TCP 64 80 → 57550 [PSH, ACK] Seq=447 Ack=147 Win=59120 Len=10
441 15.533725 192.168.1.82 192.168.1.105 TCP 80 80 → 57550 [PSH, ACK] Seq=457 Ack=147 Win=59120 Len=26

Hast du evtl. noch einen Tip?
Es sieht ja erstmal so aus, dass gar kein WOL Befehl ausfegührt wird; aber ich hätte vermutet, dass ich irgendwie erkenne, dass ich im Webinterface den Taster gedrückt habe.

Gruß Thomas

[Jan W.]

@t_heinrich Ja, Dein MS sendet kein WoL Paket aus. Broadcasts z.B. von ARP Requests des MS kommen aber sehr wohl an, d.h. die Ursache liegt wohl im MS und nicht am Fernseher, der den Request wg. falscher MAC-Adresse oder etwas anderer Form des Befehls nicht versteht. Immerhin hat Wireshark das Problem eingrenzen können.

Den Trigger solltest Du auf jeden Fall sehen können, allerdings filterst Du die Pakete heraus, die der MS sendet. Hier bitte den Filter auf eth.addr (Quell- oder Ziel MAC Adresse) ändern. Ich habe es gerade bei mir getestet: die Kommunikation erfolgt über das Protokoll websocket, daher als Filter z.B. http || websocket, evtl. (http || websocket) && ip.addr==192.168.1.82 (http oder websocket von und zur IP-Adresse des MS) einstellen. Am Besten das automatische Scrolling in Wireshark aktivieren, so dass man ungefähr weiss, ab welcher Paketnr. man suchen muss und dann beide Fenster nebeneinander setzen (Wireshark und Webbrowser).

ich sehe dann folgenden websocket Request vom MacBook zum MS:
jdev/sps/io/0c0f25b6-013e-7448-ffffeee000540133/on

Es handelt sich um einen IO Request mit dem Befehl "on" für das Objekt 0c0f25b6-013e-7448-ffffeee000540133, welches in der .loxone Config Datei so aussieht:

<C Type="PushButton2" V="124" U="0c0f25b6-013e-7448-ffffeee000540133" Title="Licht Abstellraum" Px="9792" Py="576" Px2="12480" Py2="1632" Cl="105,195,80" Nio="6" WF="16384">

Ich habe hierbei den einfachen Taster für das Licht eingeschaltet. Der MS antwortet dann mit:

{"LL": { "control": "dev/sps/io/0c0f25b6-013e-7448-ffffeee000540133/on", "value": "1", "Code": "200"}}

Was bedeutet, dass der Wert auf 1=an gesetzt wurde. Man kann den Filter noch verfeinern: websocket.opcode == 1 (zeige Websocket Pakete an, die "Text" enthalten).

Die Ursache ist damit aber nicht klar. Du könntest parallel zum WoL Befehl noch etwas anderes ausführen, um sicherzustellen, dass der Trigger greift. Ich werde WoL auch mal testen ...

Gruß Jan

[Jan W.]

Hier ein Update: ich habe in meinem MS ein WoL Objekt mit einer fiktiven MAC-Adresse erstellt. Ergebnis: ich habe kein WoL Paket mit Wireshark gesehen, also das gleiche Problem wie @t_heinrich. Der Loxone Monitor zeigte ein "PRG Virtualoutput to <MAC-Adresse>", siehe



Da der Loxone Monitor das Auslösen des virtuellen Outputs im Monitor angezeigt hat, ist die Konfiguration korrekt. Wenn es ein Broadcast gewesen wäre, dann hätte Wireshark es anzeigen müssen. Dann gibt es nur zwei Möglichkeiten:
a) entweder hat die Funktion keine Wirkung - sehr unwahrscheinlich, da andere Anwender sie erfolgreich verwendet haben
b) die Funktion sendet keinen Broadcast, so dass die einfache Aufzeichnung direkt am PC/MacBook ohne Portspiegelung oder Fritzbox (siehe Loxwiki weiter oben) die Pakete nicht angezeigt hat.

Um b) zu prüfen, ohne umständlich eine Portspiegelung auf meinem Switch einzurichten, habe ich einfach die MAC-Adresse meines MacBooks eingetragen. Ergebnis: ich habe ein WoL Paket mit Wireshark gesehen! Filter: websocket.opcode == 1 || wol
Hinweis: Bei dem Filter "websocket" sieht man nur dann etwas, wenn man die Session im Browser mit Reload neu startet bzw. ein neues Fenster oder Tab öffnet.

Der Unterschied war also die Zieladresse im Ethernet Header! Wenn man Google mit der richtigen Suche füttert, dann kommt die Erklärung auch sofort:

Das Datenpaket ist entweder direkt an die Netzwerkkarte adressiert oder wird als Broadcast verschickt.

aus Wikipedia

Möglicherweise reagieren bestimmte Geräte nur auf die Broadcast-Adresse im Ethernet Header. Das ist sicherlich die schlüssige Erklärung. Ob Loxone über ein Feature-Request den Code der WoL Funktion modifiziert bzw. eine Option für Broadcast/Unicast ergänzt? Ich bin da eher skeptisch, aber Du kannst ja versuchen, den Support zu fragen und ein Ticket erstellen. Ein Bug ist es nach meiner Ansicht nicht, wenn Loxone nur eine der beiden Varianten implementiert hat. Blöd ist nur, wenn bei dem Gerät genau die andere Variante implementiert wurde. :-((

Auf jeden Fall war das geschilderte Problem mit WoL bestens geeignet, um mit Hilfe von Wireshark aufgeklärt zu werden. Damit ist auch klar, dass weder die Klein- oder Großschreibung, noch die HTTP Methode oder irgendein Voodoo eine Rolle spielt.

[svethi]

Ich wäre für die POST Variante ;-)

[t_heinrich]

Jan W. Wow!! Erstmal vielen Dank für die ja schon fast wissenschaftliche Abhandlung. Liest sich total schlüssig (und dadurch schon fast trivial) dennoch Cheapau für das deutliche Eingrenzen des Problems.
Ich werde mich mal an Loxone wenden, vielleicht bekomme ich ja eine technische Antwort über die Art der Implementierung ... Ergebnis würde ich dann hier kundtun.

[t_heinrich]

Loxone hat das Thema bestätigt und es als Feature Request aufgenommen.