Jump to content

WOL Probleme


jasch

Recommended Posts

Hallo, ich wollte mich mal wieder ans aktivieren von WOL machen.

Lief früher bei mir einwandfrei, aber nach wechsel auf Win10 hatte ich da Probleme mit längerem Standby(Energie Sparen).(Hatte aber nichts mit DVBViewer zu tun).

Also habe ich das ganze mal wieder aktiviert, allerdings lässt sich der Server  nicht aufwecken.(Mediaserver +DVBViewer 4er Version(neuste))

Mit Wol2 Tool oder anderen Sachen funktionert das Ganze.

Ich habe jetzt mal Whireshark auf den Mediaserver gepackt und folgendes Ergebnis, Whireshark erkennt das ganze nicht als WOL sondern als QUIC.

Kann eventl. am port liegen, 80 wird vom DVBViewer verwendet, kann man diesen irgendwo ändern?(mache tools versuchen ICMP port 7 zu nehmen, das geht in der Regel aber auch schief).

 

Whireshark.thumb.PNG.226c3a60048c517bf50d269fd5410507.PNG

Wol von 192.168.6.254(Pfsense)

Wol von 192.168.6.2 Dvbviewerclient via Wol2 Tool

Quic von 192.168.6.2 ist manuelles drücken von Server aufwecken im Reiter recordingService

 

0wol.png.18d2da2da10bc364b77147d052b8af8e.png

 

funktionierender Wol ( Synchronization Stream (FF..) gefolgt von 16x MAC Adresse)

 

QUIC.PNG.b932ed1bae75222f0c823bc4e1721668.PNG

 

Der DVBViewer Block beinhaltet zwar auch die richtigen Daten, hat aber davor und danach noch sachen stehen.

Danach kann zwar durchaus ein passwort stehen aber das muss anders aussehen.

 

 

Soviel ich noch weiss kann man mit Quic UDP packete verschlüsseln, aber bei WOL?

 

Die Header Daten passen aber.

 

WOL Packet

0000   45 00 00 9a 1c bb 00 00 80 11 56 ee c0 a8 06 02
0010   ff ff ff ff

 

DVBViewer

0000   45 00 00 90 1c bc 00 00 80 11 56 f7 c0 a8 06 02
0010   ff ff ff ff

 

Da unterscheidet sich nur die Header checksum.

 

Bei der Lan Nic handelt es sich um eine Intel Nic, alle haken für Wakeup sind gesetzt.

 

 

 

Edited by jasch
Link to post

Hab jetzt nochmal nachgeforscht, die fehlerhafte erkennung als QUIC kann ich ausschalten im Wireshark, allerdings stimmt das Paket einfach nicht.

Mit unten stehendem Powershell script kann man einfach wol testen.

 

$Mac = Ziel Mac Adresse

$UdpClient.Connect hinten die Zahl ist der Port

port 80 funkt einwandfrei.

 

 

$Mac = "00:AA:BB:CC:DD:EE"
$MacByteArray = $Mac -split "[:-]" | ForEach-Object { [Byte] "0x$_"}
[Byte[]] $MagicPacket = (,0xFF * 6) + ($MacByteArray  * 16)
$UdpClient = New-Object System.Net.Sockets.UdpClient
$UdpClient.Connect(([System.Net.IPAddress]::Broadcast),9)
$UdpClient.Send($MagicPacket,$MagicPacket.Length)
$UdpClient.Close()

 

Edited by jasch
Link to post

Sorry, ich bin erst jetzt dazu gekommen, mir den Code anzuschauen. Die für WOL zuständige Datei wurde zuletzt im März 2013 geändert, also bevor mir der DVBViewer Pro-Code zugefallen ist. Einen eventuellen Bug gibt es also schon mindestens seit dem Datum.

 

Ich habe von der Sache keine Ahnung, kann aber zwecks Abgleich angeben, was der DVBViewer laut Code macht. Er füllt einen 116 Byte großen Puffer mit folgenden Daten:

Byte 1..6:     MAC Adresse (6 Bytes)
Byte 7..14:    00 74 FF FF FF FF FF FF (8 Bytes)
Byte 15..110   16 x MAC Adresse (96 Bytes)
Byte 111..116  40 00 90 90 40 00 (6 Bytes)

Dann wird der Puffer auf folgende Weise als Broadcast abgeschickt:

  WSocket.Proto := 'udp';
  WSocket.Addr := '255.255.255.255';
  WSocket.Port := '80';
  WSocket.LocalPort := '0';
  WSocket.Connect;
  WSocket.Send(Buffer, 116);
  WSocket.Close;

Nun erzähl mir mal jemand, was daran falsch ist und wie es richtig sein müsste...

 

Link to post
vor 1 Stunde schrieb Griga:

Byte 7..14: 00 74 FF FF FF FF FF FF (8 Bytes)

das scheint mir nicht korrekt zu sein.

 

Aus dem englischen Wikiartikel:

The magic packet is a broadcast frame containing anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes.

Byte 1..6:    FF FF FF FF FF FF
Byte 7..102   16 x MAC Adresse (96 Bytes)

 

 

Link to post

Das habe ich auch gefunden, frage mich aber, warum der DVBViewer Code so ist, wie er ist. Irgendjemand wird sich dabei doch was gedacht haben? Und es auch getestet haben? Oder es wurde von irgendwo kopiert und nie überprüft?

 

Kannst du WOL testen?

Link to post

Ja, aber erst am Nachmittag.

Feedback gibts später.

 

vor 34 Minuten schrieb Griga:

..frage mich aber, warum der DVBViewer Code so ist, wie er ist. Irgendjemand wird sich dabei doch was gedacht haben? Und es auch getestet haben? Oder es wurde von irgendwo kopiert und nie überprüft?

Der Code scheint so in älteren Biliotheken genutzt worden zu sein. siehe hier

 

Link to post
1 hour ago, janee said:

Der Code scheint so in älteren Biliotheken genutzt worden zu sein. siehe hier

 

Dann hat WOL früher anders funktioniert als heutzutage? Der Code in Post #2 sieht schon eher nach 6 x FF und dann 16 x MAC-Adresse aus.

 

1 hour ago, janee said:

Ja, aber erst am Nachmittag.

Feedback gibts später.

 

Ich habe vor allem wegen einer (korrigierten) Testversion gefragt, die ich dann hochlade.

Link to post
On 12/1/2017 at 7:13 AM, Griga said:

Sorry, ich bin erst jetzt dazu gekommen, mir den Code anzuschauen. Die für WOL zuständige Datei wurde zuletzt im März 2013 geändert, also bevor mir der DVBViewer Pro-Code zugefallen ist. Einen eventuellen Bug gibt es also schon mindestens seit dem Datum.

 

 

Das ist natürlich Strange, ich behaupte jetzt mal, das ich 2014/2015 das aktiv genutzt habe(mit Win 8 hatte ich da nie Probleme).(danach nur sporadisch behaupte, aber es ging).

Ich werde mal mit 2 Vms für client und Server testen, um mögliche externe Fehlerquellen auszuschalten.

Danke schonmal für anschauen, mit Delphi kann ich euch leider nicht wirklich helfen.

Allerdings gibt es außer Magic Packet(quasi standard) noch andere exo. Methoden für WOL, Pattern Match...., nicht das da mal was genommen wurde.

 

Edited by jasch
Link to post

@janee hat das inzwischen getestet und ermittelt, dass es bei seinem Intel NUC sowohl mit der 6.0.4.0 als auch mit einer DVBViewer-Test-Variante funktioniert., die auf den von dir bemängelten Daten-Vor- und Nachspann verzichtet. Wir werden wahrscheinlich bei der neuen Variante bleiben, da sie mehr dem allgemeinen Usus zu entsprechen scheint.

 

Bei Bedarf kann ich dir eine Testversion zur Verfügung stellen.

 

Link to post

Teste mal bitte, ob diese Einstellungen bei dir was bringen. Intel Netzwerkkarten haben unter Windows 10 so ihre Probleme mit WOL. Andere Netzwerkkarten kann ich derzeit nicht testen.

Am 1.12.2017 um 17:07 schrieb janee:

Das Problem in  diesen Fall ist Windows 10.

Man muss den „Schnellstart“ in den Energieoptionen von Windows abschalten (zu finden unter Systemsteuerung → Hardware und Sound → Energieoptionen → Systemeinstellungen).

Nun sollte WOL funktionieren. Einstellungen bei der Netzwerkkarte, dass diese auf WoL-Pakete reagiert, setze ich jetzt mal vorraus.

 

Ist die Schnellstartoption aktiv, schafft es mein NUC nur aus dem Ruhezustand aufgeweckt zu werden.

Ist er aus, bleibt er es auch:)

 

image.thumb.png.ccb38d0b8bb194e6a95a274865ff3d30.png

 

Edited by janee
Link to post

Ich glaube nicht, dass es am Schnellstart liegt, denn @jasch hat es ja mit anderen Mitteln gegengetestet:

 

On 28.11.2017 at 2:53 PM, jasch said:

Mit Wol2 Tool oder anderen Sachen funktionert das Ganze.

 

Link to post

Liegt nicht am schnellstart, meine alten Probleme waren das sich seit Windows 10 der Pc zwar aufwecken lies, aber nur in einem kurzen Zeitraum ca 1h.

Nach längerer Zeit, über Nacht zb. half immer nur der  Powertaster.

Gibt da wohl Probleme mit der ME.(hab nen Q77 Board mit vpro).

 

Über eine Testversion würde ich mich sehr freuen Griga.

Edited by jasch
Link to post

So getestet, funktioniert einwandfrei, WOL Packet wird jetzt auch sauber als Magic Packet erkannt.

 

Mir ist noch aufgefallen, das das Ganze nur bedingt funktionert, wenn man mehr als 1 Lan Karte aktiv hat, die unterschiedliche subnets haben.

Denke mal, ihr macht da keine Zuordnung sondern greift einfach die erste (in meiner WS musste ich meine 10Gbe Karte deaktivieren, damit das Wol Packet richtig raus geht).

Das ist aber eher nen Sonderfall, sollte beim normalen Htpc Betrieb nicht ins Gewicht fallen.

 

Danke  Alex

Link to post

Ok, danke für den Test, dann bleiben wir jetzt bei dem geänderten Paketinhalt.

 

1 hour ago, jasch said:

Mir ist noch aufgefallen, das das Ganze nur bedingt funktionert, wenn man mehr als 1 Lan Karte aktiv hat, die unterschiedliche subnets haben.

 

Der Code, der das Paket absendet, sieht so aus:

 

  Socket.Proto := 'udp';
  Socket.Addr := '255.255.255.255'; //broadcast
  Socket.Port := '80';
  Socket.LocalPort := '0';

  Socket.LocalAddr := '0.0.0.0';

  Socket.Connect;
  Socket.Send(@Buffer, SizeOf(Buffer));
  Socket.Close;

 

ich nehme an, dass es damit dem OS überlassen bleibt, über welchen Adapter und Port das Paket rausgeht. Es wäre wahrscheinlich auch möglich, es über sämtliche verfügbaren Adapter zu verteilen.

 

Link to post

Ich habe in meinem PC auch mehrere Netzwerkkarten und zum Aufwachen des DVB RS Server auf einem anderen Rechner nutze ich mc-wol MAC_RS /a 192.168.137.255.

Der RS hat eine IP in diesem Subnetz. mc-wol ist ein Tool von Matcode. Ohne Angabe der Adresse tut sich nichts.

Link to post

Mit 255.255.255.255 anstatt 192.168.137.255  tut sich nichts? Das kann eigentlich nicht sein ... bitte nochmal gegentesten. :)

Link to post
vor 20 Stunden schrieb Griga:

Ist 192.168.137.255 die Adresse des sendenden Netzwerkadapters auf dem DVBViewer-PC, oder die Empfänger-Adresse des PCs, auf dem der RS läuft?

Weder noch. 192.168.137.255 ist die Broadcast Adresse des Netzes in dem sich die beiden Rechner befinden. Der Rechner von dem aus der WOL losgeschickt wird hat die .1, den RS Rechner habe ich auf IP 254 gesetzt.

Vielleicht liegt das ja auch an meinem besonderen Netzwerk Aufbau: der WOL Rechner hat über WLAN Verbindung ins Internet, der RS Rechner hängt an der Lan Karte des WOL Rechners und kann über Internet Conection Sharing ins Internet. Auf dem WOL Rechner läuft auch Hyper-V und es gibt noch zwei weitere virtuelle Netzwerkkarten. Das sieht so aus:

image.png.a36806f004e7bd59228e27eb6c26d746.png

Link to post

Ich gebe zu, dass ich jetzt nicht alles hier ausführlich gelesen habe aber auf die Schnelle mal folgende Randinformation: ich suche bei meiner eigenen Software gerade ein identisches Problem und konnte es zumindest soweit einkreisen, dass es funktioniert, wenn ich auf dem das WOL Paket sendenden Rechner den virtuellen Netzwerkadapter von der Virtual Box abschalte (es läuft zurzeit keine aktive VM). Vermutlich wird das UDP Send (ich verwende .NET, aber im Endeffekt geht das ja eh alles auf die Win API) über die falsche Karte geroutet. Ich habe mir für's Wochenende mal vorgenommen zu schauen, ob man das in irgendeiner Form aus .NET heraus beeinflussen kann (e.g. Auflisten und auswählen). Entweder wie oben aufgeführt dann über alle Karten das Broadcast (ich verwende FF FF FF FF) senden oder die Konfiguration zur Auswahl erweitern (das allerdings wäre für den Endanwender sehr lästig).

 

Ich schaue auf jeden Fall mal, was ihr so herausbekommt :-)

 

Jochen

Link to post

Soweit ich das verstehe, gibt es ein Problem, wenn verschiedene Netzwerkadapter verschiedene Subnetze bedienen. Wenn man als Adapteradresse 0.0.0.0 angibt, sucht sich das OS einen aus, den es für geeignet hält, und der Broadcast geht dann halt nur in das jeweilige Subnetz. Um das zu ändern, muss man entweder den Anwender den Adapater anhand seiner IP auswählen lassen, oder der Code muss sich eine Liste der vorhandenen Adapter IPs besorgen und den Broadcast in einer Schleife nacheinander über alle rausschicken.

 

Ein Ansatzpunkt für eine solche Liste wäre der folgende API-Aufruf, der je nach übergebenem Socket sowohl IPv4 als auch IPv6 liefern kann:

 

WSAIoCtl(s, SIO_GET_INTERFACE_LIST, nil, 0, Buffer, BufSize, @BytesReturned, nil, nil);

 

https://msdn.microsoft.com/de-de/library/windows/desktop/ms741621(v=vs.85).aspx

 

sofern nicht irgendeine Bibliothek etwas brauchbares bereitstellt.

 

Eine auf IPv4 beschränkte Alternative ist GetAdaptersInfo:

 

https://msdn.microsoft.com/de-de/library/windows/desktop/aa365917(v=vs.85).aspx

 

Link to post
  • 2 weeks later...

Danke für die Info. B) In meiner Software kann ich die Broadcast Adresse einstellen und das tut dann bei mir auch genau das gewünschte (bisher). Ich habe im .NET Framework tatsächlich auch eine API gefunden, um alle Netzwerkkarten aufzulisten aber zumindest über .NET Sockets war mir nicht so direkt ersichtlich, wie ich einen Socket zwinge, eine dedizierte Karte zu verwenden. Ich denke, mit etwas Recherche würde ich das herausbekommen, aber mir reicht meine Lösung.

 

Ich hoffe, Ihr bekommt Euer Problem auch so relativ einfach in den Griff.

 

Jochen

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...