jasch Posted November 28, 2017 Share Posted November 28, 2017 (edited) 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). 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 0 funktionierender Wol ( Synchronization Stream (FF..) gefolgt von 16x MAC Adresse) 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 November 28, 2017 by jasch Quote Link to comment
jasch Posted November 28, 2017 Author Share Posted November 28, 2017 (edited) 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 November 28, 2017 by jasch Quote Link to comment
Griga Posted December 1, 2017 Share Posted December 1, 2017 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... Quote Link to comment
janee Posted December 1, 2017 Share Posted December 1, 2017 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) Quote Link to comment
Griga Posted December 1, 2017 Share Posted December 1, 2017 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? Quote Link to comment
janee Posted December 1, 2017 Share Posted December 1, 2017 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 Quote Link to comment
Griga Posted December 1, 2017 Share Posted December 1, 2017 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. Quote Link to comment
jasch Posted December 4, 2017 Author Share Posted December 4, 2017 (edited) 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 December 4, 2017 by jasch Quote Link to comment
Griga Posted December 4, 2017 Share Posted December 4, 2017 @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. Quote Link to comment
janee Posted December 4, 2017 Share Posted December 4, 2017 (edited) 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 Edited December 4, 2017 by janee Quote Link to comment
Griga Posted December 4, 2017 Share Posted December 4, 2017 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. Quote Link to comment
jasch Posted December 5, 2017 Author Share Posted December 5, 2017 (edited) 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 December 5, 2017 by jasch Quote Link to comment
jasch Posted December 5, 2017 Author Share Posted December 5, 2017 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 Quote Link to comment
Griga Posted December 5, 2017 Share Posted December 5, 2017 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. Quote Link to comment
x112 Posted December 6, 2017 Share Posted December 6, 2017 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. Quote Link to comment
nuts Posted December 6, 2017 Share Posted December 6, 2017 Mit 255.255.255.255 anstatt 192.168.137.255 tut sich nichts? Das kann eigentlich nicht sein ... bitte nochmal gegentesten. Quote Link to comment
x112 Posted December 7, 2017 Share Posted December 7, 2017 Mit 255.255.255.255 wacht der RS Rechner nicht auf, nur mit 192.168.137.255. Kann natürlich auch an dem verwendeten Programm mc-wol liegen. Quote Link to comment
Griga Posted December 7, 2017 Share Posted December 7, 2017 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? Quote Link to comment
x112 Posted December 8, 2017 Share Posted December 8, 2017 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: Quote Link to comment
JMS Posted December 14, 2017 Share Posted December 14, 2017 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 Quote Link to comment
Griga Posted December 14, 2017 Share Posted December 14, 2017 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 Quote Link to comment
JMS Posted December 23, 2017 Share Posted December 23, 2017 Danke für die Info. 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.