Archiv verlassen und diese Seite im Standarddesign anzeigen : Problem mit Wake-on-LAN, aber beim aufrufenden Rechner
blackbox
2021-06-01, 18:38:52
sondern beim PC, der den anderen aufwecken soll.
Ziel: PC1 weckt PC2 auf
- Problem: PC1 wird immer nur in den Standby geschickt, nach unterschiedlichen Betriebsstunden (mal 1 Tag, mal 3 Tage, man weiß es nicht so genau) kann dieser PC2 mithilfe von MagicPacket nicht mehr aufwecken. Erst nach einem Neustart von PC1 kann man PC2 aufwecken
- es ist alles aktuell, PC1 macht sonst keine Probleme
Habt ihr einen Tipp?
myMind
2021-06-02, 00:02:08
Probier mal ein Waketool, dass ohne IP-Angabe auskommt, so wie etherwake unter Linux.
Meiner Meinung nach hat WoL ein Problem, wenn ich die WoL-Pakete einpacke - z.B. mit UDP - dann aber die MAC des zu weckenden Rechners aus den arp-Caches der Router verschwinden. Ausgeschaltete Rechner reagieren soweit ich weiß nicht auf arp Anfragen. D.h. die Zustellung scheitert dann bei der Zuordnung von L3 auf L2.
Für Wake-on-Wan müsste man dann einen statischen arp-Eintrag machen. Für Wake-on-Lan sollte es reichen einfach auf IP zu verzichten. Also direkt das WoL Paket im LAN raushauen.
blackbox
2021-06-02, 18:43:07
Ich weiß nicht, ob ich dich richtig verstanden habe und du mich missvertanden hast.
Es geht nicht um den Rechner, der aufgeweckt werden soll, sondern um den, der das Magic Packet verschickt. Dazu nutze ich auch das Programm Magic Packet. Das nutzt die Mac-Adresse des Ziel-PCs.
Das Problem ist, dass nach einiger Betriebszeit des Senders (also PC1) des Magic Packet den Zielrechner nicht mehr aufwecken kann. Warum, das weiß ich nicht. Erst nach einem Neustart des PCs kann ich den anderen PC wieder aufwecken.
Ich vermute ein Treiberproblem beim Realtek LAN Treiber.
PatkIllA
2021-06-02, 18:51:03
Die Rechner sind einfach per Switch verbunden? Mit anderen PCs/Handy geht das Aufwecken noch
Ansonsten mal mit Wireshark auf den PCs nachschauen.
Erstmal ob es vermeintlich aus PC1 rausgeht. Und als zweites falls das Aufwecken nicht mehr klappt, den PC2 manuell aufwecken und dann sniffen während du weiter das MagicPacket von PC1 verschickst.
myMind
2021-06-02, 19:55:50
Ich weiß nicht, ob ich dich richtig verstanden habe und du mich missvertanden hast.
Es geht nicht um den Rechner, der aufgeweckt werden soll, sondern um den, der das Magic Packet verschickt. Dazu nutze ich auch das Programm Magic Packet. Das nutzt die Mac-Adresse des Ziel-PCs.
Das Problem ist, dass nach einiger Betriebszeit des Senders (also PC1) des Magic Packet den Zielrechner nicht mehr aufwecken kann. Warum, das weiß ich nicht. Erst nach einem Neustart des PCs kann ich den anderen PC wieder aufwecken.
Da habe ich mich vermutlich etwas unglücklich ausgedrückt. Verstanden habe ich das Szenario schon.
Ich erkläre nochmal wo ich bei bestimmten Programmen eine Lücke sehe. Es gibt bei WoL zwei Varianten. Einmal a) direkt auf L2 und einmal b) geroutet über L3 (z.B. in UDP eingepackt).
a) Bei einem Programm das geradeaus die erste Variante macht, kann Netzwerktechnisch fast nichts schiefgehen. Das Verfahren klappt aber nur im LAN, da es kein L3-Routing gibt. Ist aber das was du brauchst.
b) Bei Programmen die per UDP versenden, gibt es unter Umständen die Lücke, dass das Paket nicht mehr zustellbar ist, sobald der für die L3-L2 zuordnung verwendete Arp-Cache die IP nicht mehr hat. Solange PC2 aus ist, werden Arp-Anfragen nicht mehr beantwortet, weshalb alles was auf L3 den Rechner erreichen soll scheitert, sobald die Caches leergelaufen sind. Variante b) ist aber die einzige Möglichkeit, wenn man WakeOnWAN machen möchte.
Du könntest das auch testen, indem Du auf PC1 einen statischen Arp-Eintrag machst:
arp -s <IP des Zielrechners> <MAC des Zielrechners>
Wenn es dann dauerhaft geht, liegt es genau daran.
Mit dem Sniffer - wie von PatkIllA vorgeschlagen - würdest Du auch sehen, wie das Magic Paket versendet wird. Ob mit oder ohne UDP.
Ich vermute ein Treiberproblem beim Realtek LAN Treiber.
Die sind definitiv immer für einen Bug gut. Mich haben hier neulich zwei Realtek USB-LAN-Adapter wahnsinnig gemacht. Treiber-Update-Mechanismus komplett kaputt.
blackbox
2021-07-04, 23:49:35
Ich habe den Fehler übrigens endlich gefunden, weil ich die Schnauze voll hatte.
Also habe ich den Netzwerkverkehr beobachtet in dem Moment, als ich das WOL-Signal verschickt habe. Und zwar ging das Paket an eine mir unbekannte IP-Adresse. Letztendlich habe ich heraus gefunden, dass das der eigene PC war! Und zwar ging das Signal an den HyperV Netzwerkadapter. Dabei habe ich gar keine virtuelle Maschine am Laufen. Den HyperV Netzwerkadapter habe ich dann deaktiviert. Jetzt klappt wieder alles, auch nach dem Standby.
Muss wohl ein Bug sein in Windows.
myMind
2021-07-05, 19:54:10
Ich habe den Fehler übrigens endlich gefunden, weil ich die Schnauze voll hatte.
Also habe ich den Netzwerkverkehr beobachtet in dem Moment, als ich das WOL-Signal verschickt habe. Und zwar ging das Paket an eine mir unbekannte IP-Adresse. Letztendlich habe ich heraus gefunden, dass das der eigene PC war! Und zwar ging das Signal an den HyperV Netzwerkadapter. Dabei habe ich gar keine virtuelle Maschine am Laufen. Den HyperV Netzwerkadapter habe ich dann deaktiviert. Jetzt klappt wieder alles, auch nach dem Standby.
Muss wohl ein Bug sein in Windows.
Schön, dass Du eine Lösung gefunden hast und danke auch für die Rückmeldung. Das muss man sich echt mal merken, dass in der Virtualisierungsecke auch immer was rumzicken kann.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.