- Mitglied seit
- 7 Okt 2015
- Beiträge
- 9,187
- Punkte für Reaktionen
- 1,432
- Punkte
- 113
Fritzbox 7490 , Wake-on-Lan über UDP Port 9 klappt nicht mehr
- Ersteller palast
- Erstellt am
Danke für den Link.
Leider verstehe ich da nur einen Bruchteil.
Also müsste Port 9 ja der ideale Port sein, die magic packets kommen an der Netzwerkkarte an und wecken den Rechner auf. Sollte der laufen und ein (vielleicht böser) Dienst auf dem Rechner auf diesem Port lauern, bekommt der Dienst die Daten aber nie zu sehen, da ab "L3" ja alles entsorgt wird? Oder kommen die Daten nur bis zur FritzBox?
Na, bleibt der Weg über
Ich hätte das Ding halt gerne von der Ferne via Teamviewer geweckt, über die Fritzoberfläche muss man sich schon eine Weile erst mal zum Ziel durchklicken ...
Leider verstehe ich da nur einen Bruchteil.
Also müsste Port 9 ja der ideale Port sein, die magic packets kommen an der Netzwerkkarte an und wecken den Rechner auf. Sollte der laufen und ein (vielleicht böser) Dienst auf dem Rechner auf diesem Port lauern, bekommt der Dienst die Daten aber nie zu sehen, da ab "L3" ja alles entsorgt wird? Oder kommen die Daten nur bis zur FritzBox?
wol -i DynDNS_Adresse.com -p 9 xx:yy:yy:xx:yy:yy
oder
wakeonlan -i DynDNS_Adresse.com -p 9 xx:yy:yy:xx:yy:yy
bleiben folgenlos, auch mit -p 7 und entsprechender Änderung der Portfreigabe in der FritzBox.oder
wakeonlan -i DynDNS_Adresse.com -p 9 xx:yy:yy:xx:yy:yy
Na, bleibt der Weg über
Ich hätte das Ding halt gerne von der Ferne via Teamviewer geweckt, über die Fritzoberfläche muss man sich schon eine Weile erst mal zum Ziel durchklicken ...
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Wo ist das Problem?
Läuft das zu weckende Gerät nicht, weckt dieses Paket es auf - dabei interessiert es kein Aas, was da im Paket als IP-Header oder was auch immer steht (der "magic content" ist halt entscheidend und der kann irgendwo und irgendwie im Paket stehen - einfach mal googlen, was so ein "magic packet" eigentlich ausmacht) ... das Paket wird auch nicht "aufgehoben" und dann irgendwann vom System doch noch verarbeitet, wenn es erst einmal läuft.
Ist das System hingegen bereits aktiv, stört auch ein weiteres Paket an TCP- oder UDP-Port 9 nicht ... das laufende System wirft dieses Paket nämlich einfach weg. Damit kann man so oft ein solches "magic packet" schicken, wie man will - man braucht zuvor nicht erst nachsehen, ob das System schon arbeitet und ggf. so ein Paket zum Wecken, wenn es an einen anderen Port gehen würde (z.B. an Port 80, wo ein HTTP-Server wartet), am Ende irgendwelche anderen Dienste auf dem zu weckenden Gerät stört oder beeinflußt.
Der Port 9 ist also tatsächlich der "ideale Port" für so einen Zweck wie WoL (vermutlich wird er deshalb auch so gerne benutzt, aber es ginge problemlos auch der "echo"-Service oder irgendein anderer dieser "basic services", die praktisch jeder IP-Stack implementiert) ... aber das heißt ja noch nicht zwangsläufig, daß der externe Port 9 der FRITZ!Box (von der WAN-Seite) jetzt 1:1 auf das Gerät im LAN durchgeleitet werden muß. Das kann extern ohne weiteres extern auch 54321 sein ... entscheidend ist, was die FRITZ!Box daraus macht und das sollte so eingestellt sein, daß dieses Paket an den (internen) Port 9 des betreffenden LAN-Clients gesendet wird.
Vernünftige Programme für (externes) WakeOnLan erlauben dann neben der Angabe des Domain-Namens oder der öffentlichen IP-Adresse des Routers auch noch die Angabe einer entsprechenden Port-Nummer.
Der Port 9 auf der WAN-Seite der FRITZ!Box ist jedenfalls bereits "in Benutzung", wenn es eine FRITZ!OS-Version mit PCP ist ... das kann jeder gerne in den Support-Daten der eigenen Box überprüfen, dort sollte immer ein solcher Eintrag für Port 9 (bereits) vorhanden sein - wobei AVM den auch in der Diagnose-Seite ausblendet, vermutlich um keine unnötigen (und unmöglichen) Aktionen seitens des Besitzers zu provozieren, weil der den Port "irgendwie schließen" will - schon beim TR-069-Knocking gab es da ja die wildesten Theorien und Aktionen, nur um das "listen" auf diesem Port irgendwie abzustellen.
Läuft das zu weckende Gerät nicht, weckt dieses Paket es auf - dabei interessiert es kein Aas, was da im Paket als IP-Header oder was auch immer steht (der "magic content" ist halt entscheidend und der kann irgendwo und irgendwie im Paket stehen - einfach mal googlen, was so ein "magic packet" eigentlich ausmacht) ... das Paket wird auch nicht "aufgehoben" und dann irgendwann vom System doch noch verarbeitet, wenn es erst einmal läuft.
Ist das System hingegen bereits aktiv, stört auch ein weiteres Paket an TCP- oder UDP-Port 9 nicht ... das laufende System wirft dieses Paket nämlich einfach weg. Damit kann man so oft ein solches "magic packet" schicken, wie man will - man braucht zuvor nicht erst nachsehen, ob das System schon arbeitet und ggf. so ein Paket zum Wecken, wenn es an einen anderen Port gehen würde (z.B. an Port 80, wo ein HTTP-Server wartet), am Ende irgendwelche anderen Dienste auf dem zu weckenden Gerät stört oder beeinflußt.
Der Port 9 ist also tatsächlich der "ideale Port" für so einen Zweck wie WoL (vermutlich wird er deshalb auch so gerne benutzt, aber es ginge problemlos auch der "echo"-Service oder irgendein anderer dieser "basic services", die praktisch jeder IP-Stack implementiert) ... aber das heißt ja noch nicht zwangsläufig, daß der externe Port 9 der FRITZ!Box (von der WAN-Seite) jetzt 1:1 auf das Gerät im LAN durchgeleitet werden muß. Das kann extern ohne weiteres extern auch 54321 sein ... entscheidend ist, was die FRITZ!Box daraus macht und das sollte so eingestellt sein, daß dieses Paket an den (internen) Port 9 des betreffenden LAN-Clients gesendet wird.
Vernünftige Programme für (externes) WakeOnLan erlauben dann neben der Angabe des Domain-Namens oder der öffentlichen IP-Adresse des Routers auch noch die Angabe einer entsprechenden Port-Nummer.
Der Port 9 auf der WAN-Seite der FRITZ!Box ist jedenfalls bereits "in Benutzung", wenn es eine FRITZ!OS-Version mit PCP ist ... das kann jeder gerne in den Support-Daten der eigenen Box überprüfen, dort sollte immer ein solcher Eintrag für Port 9 (bereits) vorhanden sein - wobei AVM den auch in der Diagnose-Seite ausblendet, vermutlich um keine unnötigen (und unmöglichen) Aktionen seitens des Besitzers zu provozieren, weil der den Port "irgendwie schließen" will - schon beim TR-069-Knocking gab es da ja die wildesten Theorien und Aktionen, nur um das "listen" auf diesem Port irgendwie abzustellen.
Hat denn Dein aufzuweckendes Gerät auch einen permanenten ARP-Eintrag in der Fritzbox?
Wenn das Gerät eine Zeitlang aus ist, verwirft die Fritzbox die Zuordnung der MAC-Adresse zur lokalen IP.
O.K, ich sehe meine Ahnungen damit bestätigt.
In meinen Beispielen habe ich offenbar solche vernünftige Programme verwendet, die über die Option "-p" genau das erlauben.
Gut, ich verwende als externen Port künftig sicherheitshalber nicht die 9, wobei das bisher auch nicht half.
Also das Problem bleibt: Mit dem Button "Computer starten" aus der Fritz-Box Gui klappt Wake on Lan - immerhin - , mit allen anderen Hilfsprogrammen nicht.
Fitzbox: 7412 (die "ohne" WLAN von 1&1)
FRITZ!OS: 06.83
Hier könnte der Hund begraben liegen. Ich habe dem Gerät via Haken in der GUI zwar eine permanente Adresse zugeordnet, die die Box in der Heimnetzübersicht auch anzeigt, wenn das Gerät tagelang aus war, aber das ist offenbar nicht genug.
Für solch einen ARP-Eintrag braucht man telnet-Zugang (was wohl seit längerem nicht mehr geht,) oder gar eine alternative Firmware?
Zuletzt bearbeitet:
Ich habe das Problem der neueren Firmwares von AVM über Peter Pawns Projekt gelöst:
https://www.ip-phone-forum.de/threa...-ändern-für-nand-basierte-fritz-boxen.273304/
Bei jedem Start meiner Fritzbox wird mit dem arp-Befehl ein permanenter ARP-Eintrag erstellt.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Braucht man eigentlich nicht ... schon das Einstellen einer Portfreigabe für einen Host und das Aktivieren von "automatisch starten" sollte ausreichen, damit das Mapping aus der "ar7.cfg" nicht mehr gelöscht wird.
Selbst wenn dieses automatische Wecken in einigen neueren FRITZ!OS-Versionen ggf. nicht funktioniert, bleibt doch das Mapping erhalten - schon damit das FRITZ!OS selbst wüßte, für welche MAC-Adresse ein WOL-Paket zu senden wäre, wobei die L2-Adresse für das WOL-Paket bei AVM tatsächlich eine Broadcast-Adresse ist (aber die MAC im Payload muß ja trotzdem stimmen).
Wenn das WOL auch mit einem abweichenden Port auf der WAN-Seite nicht funktioniert (auf der LAN-Seite würde ich wieder Port 9 verwenden, aus den oben genannten Gründen), würde ich mal einen Paket-Mitschnitt im Netzwerk machen (bzw. auf der Box selbst und zwar sowohl für die "1. Internetverbindung" als auch für "LAN") und die eingehenden Pakete aus dem WAN mit ihren Pendants auf dem LAN-Interface vergleichen.
Wie gesagt ... Port 9 (auf dem WAN-Interface) kann bei neuer Firmware nicht funktionieren, bei anderer Portnummer liegt das Problem vermutlich doch eher woanders. Wenn aus dem eingehenden Paket kein Paket im LAN entsteht, weil wirklich kein ARP-Eintrag vorhanden ist und die Box damit nicht weiß, an welche MAC-Adresse sie das umgeschriebene Paket senden soll, dann muß da ja zumindest eine passende ARP-Abfrage als Broadcast zu sehen sein, die natürlich vom "schlafenden" Gerät nicht selbst beantwortet wird. Dann - aber nur dann - könnte man auch schlußfolgern, daß die fehlende Kenntnis der MAC-Adresse für die IPv4-Adresse des LAN-Gerätes die Ursache für das Versanden des WOL-Pakets von extern ist.
EDIT:
@palast:
Heißt das, die Ursache für dieses Versagen des automatischen Aufweckens ist von Dir bis zum Fehlen der MAC-Adresse zurückverfolgt? Ich hatte den Rest oben schon zuvor geschrieben, war nur durch ein Telefonat abgelenkt und habe erst jetzt auf "Post Reply" gedrückt ... #47 hatte ich da noch nicht gesehen.
Selbst wenn dieses automatische Wecken in einigen neueren FRITZ!OS-Versionen ggf. nicht funktioniert, bleibt doch das Mapping erhalten - schon damit das FRITZ!OS selbst wüßte, für welche MAC-Adresse ein WOL-Paket zu senden wäre, wobei die L2-Adresse für das WOL-Paket bei AVM tatsächlich eine Broadcast-Adresse ist (aber die MAC im Payload muß ja trotzdem stimmen).
Wenn das WOL auch mit einem abweichenden Port auf der WAN-Seite nicht funktioniert (auf der LAN-Seite würde ich wieder Port 9 verwenden, aus den oben genannten Gründen), würde ich mal einen Paket-Mitschnitt im Netzwerk machen (bzw. auf der Box selbst und zwar sowohl für die "1. Internetverbindung" als auch für "LAN") und die eingehenden Pakete aus dem WAN mit ihren Pendants auf dem LAN-Interface vergleichen.
Wie gesagt ... Port 9 (auf dem WAN-Interface) kann bei neuer Firmware nicht funktionieren, bei anderer Portnummer liegt das Problem vermutlich doch eher woanders. Wenn aus dem eingehenden Paket kein Paket im LAN entsteht, weil wirklich kein ARP-Eintrag vorhanden ist und die Box damit nicht weiß, an welche MAC-Adresse sie das umgeschriebene Paket senden soll, dann muß da ja zumindest eine passende ARP-Abfrage als Broadcast zu sehen sein, die natürlich vom "schlafenden" Gerät nicht selbst beantwortet wird. Dann - aber nur dann - könnte man auch schlußfolgern, daß die fehlende Kenntnis der MAC-Adresse für die IPv4-Adresse des LAN-Gerätes die Ursache für das Versanden des WOL-Pakets von extern ist.
EDIT:
@palast:
Heißt das, die Ursache für dieses Versagen des automatischen Aufweckens ist von Dir bis zum Fehlen der MAC-Adresse zurückverfolgt? Ich hatte den Rest oben schon zuvor geschrieben, war nur durch ein Telefonat abgelenkt und habe erst jetzt auf "Post Reply" gedrückt ... #47 hatte ich da noch nicht gesehen.
Ich denke mir fehlt Dein Know-How, um dies letztendlich beurteilen zu können.
Ich schildere mal, wie ich es nach meiner Auffassung empirisch festgestellt habe:
- Der aufzuweckende Rechner ist an. Die Fritzbox meldet bei arp -v für den betreffenden Rechner
"(IP-Adresse) at MAC-Adresse [ether] on lan". Das WOL-Paket kommt an (Sniffer).
- Der aufzuweckende Rechner ist im Standby. Die Fritzbox meldet bei arp -v
"(IP-Adresse) at <incomplete> on lan". Das abgesandte WOL-Paket weckt den Rechner nicht aus dem Standby.
- Setzen eines permanenten ARP-Eintrags per
"arp -s IP-Adresse MAC-Adresse."
Meldung Fritzbox bei arp -v: "(IP-Adresse) at MAC-Adresse [ether] PERM on lan"
Das abgesandte WOL-Paket weckt den Rechner aus dem Standby.
Dass die Fritzbox auf jeglichen Netzwerktraffic selbst den aufzuweckenden Rechner aufwecken soll habe ich bei mir in der Fritzbox nicht aktiviert.
Zuletzt bearbeitet:
15Eleven_no7
Mitglied
- Mitglied seit
- 6 Okt 2014
- Beiträge
- 281
- Punkte für Reaktionen
- 8
- Punkte
- 18
Ich wollte mich mal kurz einklinken: Und zwar funktionierte bei mir WOL mit der Fritzbox 3370 bisher ohne Probleme. Zuerst über Port 9, dann nach dem Update musste ich auf Port 7 umstellen damit es weiterhin ging. Sowohl im Netzwerk als auch übers Internet konnte ich meinen Rechner aufwecken.
Seit ich WIN 10 Update 1709 installiert habe geht mein WOL über das Internet nicht mehr. Habe sonst nichts am System geändert.
Teilweise funktioniert es einige Sekunden nach Abschalten des PCs noch aber spätestens nach ein paar Minuten nicht mehr (was ja auf den ARP cache schließen lässt, jedoch dem widerspricht, dass es ja vor dem 1709 Update exakt mit unveränderten Settings ging).
Ich wollte das nur mal hier mit einwerfen, da es evtl. bei deiner Problemlösung helfen könnte.
Ich starte den PC nun über die "Wecken" Funktion der Fritzbox, da ich die Hoffnung habe, dass es am Update 1709 lag und es mit einem zukünftigen Update wieder funktioniert.
Seit ich WIN 10 Update 1709 installiert habe geht mein WOL über das Internet nicht mehr. Habe sonst nichts am System geändert.
Teilweise funktioniert es einige Sekunden nach Abschalten des PCs noch aber spätestens nach ein paar Minuten nicht mehr (was ja auf den ARP cache schließen lässt, jedoch dem widerspricht, dass es ja vor dem 1709 Update exakt mit unveränderten Settings ging).
Ich wollte das nur mal hier mit einwerfen, da es evtl. bei deiner Problemlösung helfen könnte.
Ich starte den PC nun über die "Wecken" Funktion der Fritzbox, da ich die Hoffnung habe, dass es am Update 1709 lag und es mit einem zukünftigen Update wieder funktioniert.
Geht es denn sonst noch?
Bei mir habe ich festgestellt, dass seit 1709ff auch bei den älteren Boards (z.B. H55M) jetzt WOL nur noch funktioniert, wenn der Schnellstart abgeschaltet ist, was u.a. auch einer allg. Pflicht zur SSD gleichkommt. ;-)
Dafür durfte ich endlich das unsägliche "Computer kann das Gerät ausschalten um Energie zu sparen" für den LAN-Adapter deaktivieren, ohne dass Windows gleich vollkommen bescheuert zusammen mit dem ausgegrauten "Gerät kann Computer aus dem Ruhezustand aktivieren" auch nebenbei WOL total verhindert.
15Eleven_no7
Mitglied
- Mitglied seit
- 6 Okt 2014
- Beiträge
- 281
- Punkte für Reaktionen
- 8
- Punkte
- 18
Wie meinst du das? Also WOL übers Netzwerk funktioniert und das Wecken über die Fritzbox-Funktion "Computer aufwecken" funktioniert. Nur übers Internet geht es nicht mehr bzw. ging es nicht mehr denn:
Ich habe das ganze heut nochmal getestet: und oh Wunder, es geht wieder. Ich verstehe es nicht. Ich habe mich vor zwei Wochen schon intensiv damit auseinandergesetzt und diverse Varianten versucht; Ohne Erfolg.
Das einzige was ich noch heute gemacht habe war, die Portweiterleitung von "Port 7 an Port 7" auf "Port 7 an Port 9" zu ändern, da ich das hier im Thread gelesen habe, dass das wohl auch geht. Wollte ich nur mal testen. Dann habe ich das auch wieder zurück gestellt auf "Port 7 an Port 7" und auch dann funktoniert alles wieder korrekt.
Ich verstehe es nicht. Vielleicht lief auch ein neues WIN 10 Update im Hintergrund, welches dafür verantwortlich ist? Keine Ahnung. Es steht zumindest ein "Qualitätsupdate für WIN 10" am 17.12. im Updateverlauf.
Lierum larum, es funktioniert wieder
Mit folgender Konfiguration:
Fritzbox: "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird." AKTIV
Netzwerkkarte: "Gerät kann den Computer...." INAKTIV
Netzwerkkarte: "Nur Magic Packet kann..." INAKTIV
Schnellstart: AKTIV
--> WOL übers Internet funktioniert
Fritzbox: "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird." INAKTIV
Netzwerkkarte: "Gerät kann den Computer...." INAKTIV
Netzwerkkarte: "Nur Magic Packet kann..." INAKTIV
Schnellstart: AKTIV
--> WOL übers Internet funktioniert NICHT
Also ausschlaggebend ist wohl die Einstellung in der Fritzbox "Diesen Computer automatisch starten...."
Einstellungen der Netzwerkkarte spielen bei mir keine Rolle.
Schnellstart spielt auch keine Rolle.
Pom-Fritz!
Aktives Mitglied
- Mitglied seit
- 12 Nov 2016
- Beiträge
- 1,519
- Punkte für Reaktionen
- 148
- Punkte
- 63
Kunststück! Hierbei handelt es sich garantiert NICHT um WOL über Magic Packet
. Bei deiner jetzigen Konfiguration weckt jeder Zugriff auf Port 7 (von außen) den Client!! Da wird durch Portscans viel Unruhe beim Client herrschen!
15Eleven_no7
Mitglied
- Mitglied seit
- 6 Okt 2014
- Beiträge
- 281
- Punkte für Reaktionen
- 8
- Punkte
- 18
Das nützt Dir nichts, weil die Fritzbox diese Einstellung nicht hat und die Einstellung der Netzwerkkarte in diesem Punkt (zumindest bei mir) die Fritzbox nicht davon abhält, den Rechner zu wecken.
15Eleven_no7
Mitglied
- Mitglied seit
- 6 Okt 2014
- Beiträge
- 281
- Punkte für Reaktionen
- 8
- Punkte
- 18
Äh ok, was schlägst du stattdessen vor? Ich hatte vorher ja auch WOL aktiviert (also bevor das ganze Problem überhaupt auftrat durch - meine Vermutung - WIN 10 1709 UPdate).
Und der Rechner war eigentlich selbständig gestartet. Und das seit Jahren. Da hatte ih auch die Portweiterleitung auf Port 7 aktiv.
Von daher würde es mich interessieren, ob du generell meinst, dass WOL auf diese Art betrieben unsicher für Portscans ist.
Und der Rechner war eigentlich selbständig gestartet. Und das seit Jahren. Da hatte ih auch die Portweiterleitung auf Port 7 aktiv.
Von daher würde es mich interessieren, ob du generell meinst, dass WOL auf diese Art betrieben unsicher für Portscans ist.
Ohne bei der Fritzbox die Option zu setzen, dass diese bei jedem Traffic aus dem Internet hin den Client aufwecken soll, hat es bei mir nie ohne weitere Klimmzüge geklappt. Die Klimmzüge habe ich ja weiter oben beschrieben:
- Setzen eines permanenten ARP-Eintrags
- Durch Beschränkungen neuerer Firmwares der Fritzbox durch AVM darüberhinaus (um den ARP-Eingtrag überhaupt Setzen zu können) Verändern der Firmware z.B. durch
https://www.ip-phone-forum.de/threa...-ändern-für-nand-basierte-fritz-boxen.273304/
was bei meiner Fritzbox 7490 geht.
Die Einstellung der Fritzbox "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird." ist ja eigentlich kein Sicherheitsproblem, sie konterkariert eventuell nur die Absicht, den betreffenden Rechner meistens außer Betrieb zu haben.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Es gibt auch einige FRITZ!OS-Versionen von AVM, wo das automatische Wecken beim Zugriff auf einen freigegebenen Port eben nicht funktioniert ... steht irgendwo in den Changelogs, daß es mal (und iirc nicht so weit in der Vergangenheit, daß bereits für alle Modelle eine korrigierte Version zur Verfügung steht) behoben wurde. M.E. gab es sogar irgendwo in der KB einen Artikel, der sich mit diesem "klappt nicht, liegt an der Version und wird mit dem nächsten Update behoben" beschäftigte.
Es spielt für diese Einstellung mit dem automatischen Wecken auch keine Rolle, ob da von außen ein "magic packet" kommt oder nicht ... das generiert die Firmware schon selbst (genauso wie beim Drücken des Buttons im GUI). Die Frage ist nur, ob sie ohne die Auswahl dieser Einstellung zum "automatischen Wecken" auch die MAC-Adresse des Clients an der korrekten Stelle dauerhaft "vorhält" ... auch wenn das "magic packet" von ihr als Broadcast gesendet wird (kann man jederzeit mit dem "Paketmitschnitt" überprüfen), muß der Payload ja die richtige MAC enthalten.
Wenn die FRITZ!Box nicht selbst dafür zuständig sein soll, das Gerät beim Zugriff auf den freigegebenen Port zu wecken, müßte sie sich diese MAC-Adresse ja nicht merken (jedenfalls nicht für diesen Zweck) ... sie könnte jederzeit davon ausgehen, daß sie bei einem eingehenden Paket für den freigegebenen Port (bei einer nicht bereits vorhandenen ausgehenden Verbindung) die MAC-Adresse des Clients mit der freigegebenen LAN-Adresse per ARP-Request auflösen kann. Zwar wird die Firmware die MAC trotzdem noch "kennen", aber in vielen anderen Zusammenhängen (von DHCP bis "leichteres Eintragen/Auswählen im GUI") ... aber das muß eben nicht zwangsläufig auch für die Tabellen für die Umsetzung des NAT gelten.
Vielleicht macht es hier sogar wieder einen Unterschied, ob man die Hardware-Beschleunigung aktiviert hat oder nicht ... eine bereits aktive Verbindung (bei TCP über den 3-way-handshake eingeleitet, den man am ersten Paket mit einem SYN-Flag sehr gut erkennen kann - bei UDP geht das aber nicht und man muß eher darauf schauen, ob es schon eine passende "Verbindung" durch vorhergehenden Traffic innerhalb einer "timeout period" gab) wird bei aktivierter Hardware-Beschleunigung einen Eintrag in der entsprechenden Tabelle haben, so daß das FRITZ!OS mit der Behandlung weiterer Pakete gar nichts mehr zu tun hat - dort ist dann m.W. sogar das automatische Umschreiben der MAC-Adresse enthalten. Aber so ein (Hardware-)Eintrag existiert (bei PCP jedenfalls) m.W. nicht ständig und wenn die Box ihn auch für ein "schlafendes" Gerät sofort beim Eintreffen des ersten Pakets in einer Verbindung einrichten wollte, braucht sie dafür die MAC-Adresse schon zu einem Zeitpunkt, wo das Gerät selbst noch nicht antworten kann ... auch dafür müßte sie die MAC-Adresse also (genau wie für das Generieren eines "magic packets") irgendwie zur Hand haben. Wird aber die Hardware-Beschleunigung nicht verwendet (und ggf. auch die Software-Variante nicht, wo das dann nicht mehr in Hardware, aber immer noch "unterhalb" des normalen Punkts im IP-Stack abläuft mit dem "Umschreiben" von Paketen), muß ein eingehendes Paket den IP-Stack ganz normal durchlaufen und da könnte es tatsächlich sein, daß die Box spätestens an dieser Stelle dann wieder auf den ARP-Cache zurückgreift bzw. mit ARP-Requests die Auflösung versucht. Will sagen ... je nach der Ursache für das Fehlschlagen des WOL (ob automatisch oder mit externem WOL-Paket) könnte auch eine andere Einstellung zur "Paketbeschleunigung" (bei den mesh-fähigen Firmwares ja irgendwo unter Support verfügbar) eine Veränderung bewirken.
Und in irgendwelchen Seiteneffekten bei den verschiedenen möglichen Zuständen für eingehende Verbindungen, die sich aus der Kombination von Einstellungen ergeben, vermute ich auch die Ursache für Probleme mit dem automatischen Wecken durch die Box - das Wecken durch die Portweiterleitung für ein "magic packet" ist hingegen keine von AVM bereitgestellte Funktion und wenn die Firmware die MAC-Adresse tatsächlich nicht kennt bzw. nicht findet, kann sie auch das Paket nicht ausliefern ... im Gegensatz zu den von ihr selbst generierten WOL-Paketen, die als L2-Broadcast gesendet werden, braucht es dafür eine L2-Adresse. Vielleicht gelingt es ja jemandem, (über Änderungen in der "ar7.cfg") einen LAN-Client mit der MAC- oder IP-Adresse für einen Broadcast einzurichten und die Portweiterleitung an diesen zu aktivieren (wobei die Box eher selten per ARP-Request nach dieser Adresse suchen wird) - mit einem solchen Eintrag könnte man dann tatsächlich rein anhand der MAC-Adresse im Payload des "magic packets" eine Auswahl des zu weckenden Gerätes treffen. Andererseits eröffnet das dann auch wieder eine Angriffsfläche, wenn man darüber Pakete an beliebige Port bzw. mit beliebigem Payload senden könnte und die nicht wirklich ignoriert werden von den Clients.
Vielleicht wäre das ja auch noch eine Idee für AVM ... einfach die Einrichtung einer "WOL-Portweiterleitung" an eine Broadcast-Adresse anbieten (wobei die IP-Pakete dann auf L3 an die BC-Adresse im Segment mit Port 9 gehen, was automatisch eine L2-BC-Adresse zur Folge haben sollte) - dann kann der Besitzer wieder auswählen, welchen (externen) "hidden port" er für das Wecken seiner Geräte verwenden will und sicher bliebe das auch noch, solange dort wirklich zwangsweise ein IP-Header (ob TCP oder UDP wäre egal, aber es sollte schon definitiv der "discard"-Service sein und damit TCP oder UDP auf L4) für Port 9 vorhanden sein muß bzw. notfalls eingefügt wird. Damit würde so ein Gerät auch nicht mehr automatisch mit einem Port-Scan geweckt (was bei der automatischen AVM-Lösung ja noch der Fall wäre, egal ob man den Port versteckt oder nicht) und die Kenntnis der richtigen MAC-Adresse würde die Kenntnis von GUI-Credentials (für das Wecken per (externem) GUI) ersetzen - aber Sinn macht das auch nur als zusätzliche Option, denn die AVM-Lösung per GUI ist auch wieder nicht soo schlecht und eigentlich auch ganz gut zu automatisieren über die TLS-Verbindung zum GUI (solange sich da nicht ständig etwas ändert, aber das ist schon einige Zeit recht stabil).
EDIT:
BTW ... das habe ich glatt vergessen zu erwähnen: Es gibt natürlich auch bei AVM eine passende TR-064-Funktion, die dem Senden eines solchen "magic packet" bzw. dem Drücken des Buttons im GUI entspricht. Das wäre dann die Funktion "X_AVM-DE_WakeOnLANByMACAddress()" auf dem "hosts"-Interface und mit dieser kann man sich natürlich problemlos auch sein eigenes Programm zum (externen) Wecken basteln und auf die Automatik ebenso verzichten wie auf jeden Kopfstand mit WOL-Paketen (eine passende Firmware-Version des FRITZ!OS unterstelle ich jetzt mal).
Wem die App dafür zu kompliziert ist, der verwendet einfach eine HTML-Seite, die dann (mit oder ohne Authentifizierung des Aufrufenden) ihrerseits die entsprechende TR-064-Funktion der Box aufruft ... die kann ja auch extern gehostet sein (es gibt genug Hoster für solche "Mini-Anwendungen", bis hin zu den Cloud-Angeboten für IoT).
Nur getrennte Credentials (bzw. genauer getrennte Rechte) für das Wecken per TR-064 wären hier noch hilfreich ... m.W. dürfen das bisher nur "administrative Benutzer"(?) und deren Namen und Kennwörter möchte man sicherlich auch nicht an "vertrauenswürdige Personen" herausgeben, denen man aber den Zugriff auf irgendeinen ansonsten schlafenden Service im eigenen LAN gerne anbieten möchte.
Da bliebe dann nur noch das automatische Wecken (für anonyme Dienste ohnehin erforderlich) ... aber eben mit dem "Risiko", daß auch andere den betreffenden Server aus dem Schlaf reißen können. Will man bereits vorher klären, ob derjenige auch berechtigt ist, ist die Automatik nutzlos ... aber nicht jeder Zugriffsberechtigte muß auch gleich noch ein Administrator sein.
Es spielt für diese Einstellung mit dem automatischen Wecken auch keine Rolle, ob da von außen ein "magic packet" kommt oder nicht ... das generiert die Firmware schon selbst (genauso wie beim Drücken des Buttons im GUI). Die Frage ist nur, ob sie ohne die Auswahl dieser Einstellung zum "automatischen Wecken" auch die MAC-Adresse des Clients an der korrekten Stelle dauerhaft "vorhält" ... auch wenn das "magic packet" von ihr als Broadcast gesendet wird (kann man jederzeit mit dem "Paketmitschnitt" überprüfen), muß der Payload ja die richtige MAC enthalten.
Wenn die FRITZ!Box nicht selbst dafür zuständig sein soll, das Gerät beim Zugriff auf den freigegebenen Port zu wecken, müßte sie sich diese MAC-Adresse ja nicht merken (jedenfalls nicht für diesen Zweck) ... sie könnte jederzeit davon ausgehen, daß sie bei einem eingehenden Paket für den freigegebenen Port (bei einer nicht bereits vorhandenen ausgehenden Verbindung) die MAC-Adresse des Clients mit der freigegebenen LAN-Adresse per ARP-Request auflösen kann. Zwar wird die Firmware die MAC trotzdem noch "kennen", aber in vielen anderen Zusammenhängen (von DHCP bis "leichteres Eintragen/Auswählen im GUI") ... aber das muß eben nicht zwangsläufig auch für die Tabellen für die Umsetzung des NAT gelten.
Vielleicht macht es hier sogar wieder einen Unterschied, ob man die Hardware-Beschleunigung aktiviert hat oder nicht ... eine bereits aktive Verbindung (bei TCP über den 3-way-handshake eingeleitet, den man am ersten Paket mit einem SYN-Flag sehr gut erkennen kann - bei UDP geht das aber nicht und man muß eher darauf schauen, ob es schon eine passende "Verbindung" durch vorhergehenden Traffic innerhalb einer "timeout period" gab) wird bei aktivierter Hardware-Beschleunigung einen Eintrag in der entsprechenden Tabelle haben, so daß das FRITZ!OS mit der Behandlung weiterer Pakete gar nichts mehr zu tun hat - dort ist dann m.W. sogar das automatische Umschreiben der MAC-Adresse enthalten. Aber so ein (Hardware-)Eintrag existiert (bei PCP jedenfalls) m.W. nicht ständig und wenn die Box ihn auch für ein "schlafendes" Gerät sofort beim Eintreffen des ersten Pakets in einer Verbindung einrichten wollte, braucht sie dafür die MAC-Adresse schon zu einem Zeitpunkt, wo das Gerät selbst noch nicht antworten kann ... auch dafür müßte sie die MAC-Adresse also (genau wie für das Generieren eines "magic packets") irgendwie zur Hand haben. Wird aber die Hardware-Beschleunigung nicht verwendet (und ggf. auch die Software-Variante nicht, wo das dann nicht mehr in Hardware, aber immer noch "unterhalb" des normalen Punkts im IP-Stack abläuft mit dem "Umschreiben" von Paketen), muß ein eingehendes Paket den IP-Stack ganz normal durchlaufen und da könnte es tatsächlich sein, daß die Box spätestens an dieser Stelle dann wieder auf den ARP-Cache zurückgreift bzw. mit ARP-Requests die Auflösung versucht. Will sagen ... je nach der Ursache für das Fehlschlagen des WOL (ob automatisch oder mit externem WOL-Paket) könnte auch eine andere Einstellung zur "Paketbeschleunigung" (bei den mesh-fähigen Firmwares ja irgendwo unter Support verfügbar) eine Veränderung bewirken.
Und in irgendwelchen Seiteneffekten bei den verschiedenen möglichen Zuständen für eingehende Verbindungen, die sich aus der Kombination von Einstellungen ergeben, vermute ich auch die Ursache für Probleme mit dem automatischen Wecken durch die Box - das Wecken durch die Portweiterleitung für ein "magic packet" ist hingegen keine von AVM bereitgestellte Funktion und wenn die Firmware die MAC-Adresse tatsächlich nicht kennt bzw. nicht findet, kann sie auch das Paket nicht ausliefern ... im Gegensatz zu den von ihr selbst generierten WOL-Paketen, die als L2-Broadcast gesendet werden, braucht es dafür eine L2-Adresse. Vielleicht gelingt es ja jemandem, (über Änderungen in der "ar7.cfg") einen LAN-Client mit der MAC- oder IP-Adresse für einen Broadcast einzurichten und die Portweiterleitung an diesen zu aktivieren (wobei die Box eher selten per ARP-Request nach dieser Adresse suchen wird) - mit einem solchen Eintrag könnte man dann tatsächlich rein anhand der MAC-Adresse im Payload des "magic packets" eine Auswahl des zu weckenden Gerätes treffen. Andererseits eröffnet das dann auch wieder eine Angriffsfläche, wenn man darüber Pakete an beliebige Port bzw. mit beliebigem Payload senden könnte und die nicht wirklich ignoriert werden von den Clients.
Vielleicht wäre das ja auch noch eine Idee für AVM ... einfach die Einrichtung einer "WOL-Portweiterleitung" an eine Broadcast-Adresse anbieten (wobei die IP-Pakete dann auf L3 an die BC-Adresse im Segment mit Port 9 gehen, was automatisch eine L2-BC-Adresse zur Folge haben sollte) - dann kann der Besitzer wieder auswählen, welchen (externen) "hidden port" er für das Wecken seiner Geräte verwenden will und sicher bliebe das auch noch, solange dort wirklich zwangsweise ein IP-Header (ob TCP oder UDP wäre egal, aber es sollte schon definitiv der "discard"-Service sein und damit TCP oder UDP auf L4) für Port 9 vorhanden sein muß bzw. notfalls eingefügt wird. Damit würde so ein Gerät auch nicht mehr automatisch mit einem Port-Scan geweckt (was bei der automatischen AVM-Lösung ja noch der Fall wäre, egal ob man den Port versteckt oder nicht) und die Kenntnis der richtigen MAC-Adresse würde die Kenntnis von GUI-Credentials (für das Wecken per (externem) GUI) ersetzen - aber Sinn macht das auch nur als zusätzliche Option, denn die AVM-Lösung per GUI ist auch wieder nicht soo schlecht und eigentlich auch ganz gut zu automatisieren über die TLS-Verbindung zum GUI (solange sich da nicht ständig etwas ändert, aber das ist schon einige Zeit recht stabil).
EDIT:
BTW ... das habe ich glatt vergessen zu erwähnen: Es gibt natürlich auch bei AVM eine passende TR-064-Funktion, die dem Senden eines solchen "magic packet" bzw. dem Drücken des Buttons im GUI entspricht. Das wäre dann die Funktion "X_AVM-DE_WakeOnLANByMACAddress()" auf dem "hosts"-Interface und mit dieser kann man sich natürlich problemlos auch sein eigenes Programm zum (externen) Wecken basteln und auf die Automatik ebenso verzichten wie auf jeden Kopfstand mit WOL-Paketen (eine passende Firmware-Version des FRITZ!OS unterstelle ich jetzt mal).
Wem die App dafür zu kompliziert ist, der verwendet einfach eine HTML-Seite, die dann (mit oder ohne Authentifizierung des Aufrufenden) ihrerseits die entsprechende TR-064-Funktion der Box aufruft ... die kann ja auch extern gehostet sein (es gibt genug Hoster für solche "Mini-Anwendungen", bis hin zu den Cloud-Angeboten für IoT).
Nur getrennte Credentials (bzw. genauer getrennte Rechte) für das Wecken per TR-064 wären hier noch hilfreich ... m.W. dürfen das bisher nur "administrative Benutzer"(?) und deren Namen und Kennwörter möchte man sicherlich auch nicht an "vertrauenswürdige Personen" herausgeben, denen man aber den Zugriff auf irgendeinen ansonsten schlafenden Service im eigenen LAN gerne anbieten möchte.
Da bliebe dann nur noch das automatische Wecken (für anonyme Dienste ohnehin erforderlich) ... aber eben mit dem "Risiko", daß auch andere den betreffenden Server aus dem Schlaf reißen können. Will man bereits vorher klären, ob derjenige auch berechtigt ist, ist die Automatik nutzlos ... aber nicht jeder Zugriffsberechtigte muß auch gleich noch ein Administrator sein.
Zuletzt bearbeitet:
Das hat mir der AVM Support geschrieben:
Für mich heißt das wohl, damit leben oder downgrade auf 6.50 (FritzBox 7412). Ein Update der 6.83 lässt jedenfalls schon Monate auf sich warten.
Ich nehme an, mit "automatisch" meinen die genau das, was hier diskutiert wird, also das Senden eines magic packet via Portweiterleitung an den Rechner, den man von "außen", also via Internetverbindung, wecken will. Manuell ist dann eben via Klick auf den Button in der FirtzOS-GUI.
Für mich heißt das wohl, damit leben oder downgrade auf 6.50 (FritzBox 7412). Ein Update der 6.83 lässt jedenfalls schon Monate auf sich warten.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Nein, das meinen die eben gerade nicht. Das automatische Senden eines WOL-Pakets durch die FRITZ!Box (was eben nicht funktioniert, wie der Support Dir für die 06.83 geschrieben hat) ist etwas vollkommen anderes als das Weiterleiten eines extern eintreffenden WOL-Pakets an einen internen Client.
Dieser Automatismus würde nämlich bei jedem beliebigen eingehenden Paket auf dem freigegebenen Port den Client aufwecken (wenn er denn funktionieren würde), weil das WOL-Paket dafür von der Box selbst generiert wird - während es bei der Portweiterleitung (mal angenommen, die MAC-Adresse zur IP(v4)-Adresse ist bekannt - wobei WOL natürlich auch mit einem IPv6-Paket ginge, solange das als L2-Adresse die MAC des Clienten oder eben eine BC-Adresse hätte) genau darauf ankommt, daß das weitergeleitete Paket selbst "magic" ist.
Wenn dessen Inhalt (also der "magic payload") aber z.B. eine andere MAC-Adresse enthält (weil die Eingabe in das Programm zum Wecken und die Freigabe in der Box nicht übereinstimmen bei der MAC-Adresse), dann bewirkt so ein Paket von außen absolut gar nicht ... der Client schläft einfach weiter, weil der Zauberstab zum Wecken nicht funktioniert.
Dieser Automatismus würde nämlich bei jedem beliebigen eingehenden Paket auf dem freigegebenen Port den Client aufwecken (wenn er denn funktionieren würde), weil das WOL-Paket dafür von der Box selbst generiert wird - während es bei der Portweiterleitung (mal angenommen, die MAC-Adresse zur IP(v4)-Adresse ist bekannt - wobei WOL natürlich auch mit einem IPv6-Paket ginge, solange das als L2-Adresse die MAC des Clienten oder eben eine BC-Adresse hätte) genau darauf ankommt, daß das weitergeleitete Paket selbst "magic" ist.
Wenn dessen Inhalt (also der "magic payload") aber z.B. eine andere MAC-Adresse enthält (weil die Eingabe in das Programm zum Wecken und die Freigabe in der Box nicht übereinstimmen bei der MAC-Adresse), dann bewirkt so ein Paket von außen absolut gar nicht ... der Client schläft einfach weiter, weil der Zauberstab zum Wecken nicht funktioniert.
Hallo ..und gleich mal entschuldigung das ich hier vielleicht noch mal nen kleinen Twist hereinbringe.
Ich stehe vor einem sehr ähnlichen ´Problem´, wie eben WOL aus dem Internet.
Bin hier auch schon komplett durch den Thread...aber kann dabei nur bestätigen, dass ich einen schnell zugänglichen Button zum Starten des Pcs in der GUI echt gut fände.
Also gleich auf der Übersichtsseite neben den aufgelisteten Netzwerkgeräten oder ähnlich.
Es ist furchtbar, selbst bei dauerhaft bestehender VPN-Verbindung und im Browser hinterlegten Passwörtern sich bis ´PC-Starten´ durchzuklicken!
Nun zu meinem genauen Problem:
Bei mir besteht wie bereits geschr. die VPN-Verbindung zwischen zwei FBs dauerhaft.
Bei angeschalteter Option ´PC automatisch bei Zugriff aus dem Internet starten´ und aktivem VPN startet die FB den entfernten Rechner bei JEGLICHEM Zugriff auf diesen.
Sprich eigentlich dauernd wenn man zum Beispiel ein Netzlaufwerk verbunden hat, oder Windows nach dem externen Rechner im Netzwerk sucht.
(also Zugriffe aus dem ´externen Internet´ sind mir eigentlich egal)
Wie ist es hinzubekommen, dass man eben ein Netzlaufwerk auf einen Rechner der externen FB verbindet, dieser aber halt nur zur Verfügung steht, wenn der dortige PC sowieso läuft
oder wenn ich ihn EXPLIZIT anschalte.
Es geht mir also um das ausführen des Starvorgangs von einem externen Rechner, der aber bereits im gleichen VPN ist.
Ich könnte sogar mit einer art HTML-Skript oder ähnlichem leben.
Irgendwas auf dem Desktop... Doppelclick--externer Rechner startet.
Auch durch die bereits bestehende VPN-Verbindung blockt die entfernte FB Programme wie WOL2 oder die WOL-Möglichkeiten vom Teamviewer oder UVNC komplett ab.
Eigentlich finde ich es sogar ziemlich unsinnig von AVM geregelt, dass bei bestehender VPN(!!!) eben JEDE(!!!) Anfrage auf das entfernte Gerät die FB zum Versand des Magic-Packets anregt, wenn die Option ´Starten bei Internetzugrif´ aktiviert ist. Ich will ja eben nicht das der Rechner dauernd aufwacht, sondern ihn nur SCHNELL anschalten wenn ich ihn brauche oder er eh läuft.
Per GUI is aber nix mit schnell mal anschalten.
Das ist doch ne Funktion die ich tausend mal öfters benötige als ein DECT-Tel neu anzumelden.
Die gehört gleich auf die Startseite gelegt (von mir aus als anschaltbare Option).
Und die gehört auch gleich ganz DICK auf die erste ganz externe Loginseite..und auch auf die Übersichtsseite der MY-Fritz-Website...einfach überall hin
Aber Platz für irgendwelche doofen Schemazeichnungen is mittlerweile genug..
von der kommt man ja sogar auf Web-Guis der Gerate per einem Klick - wenn das GErät eins hat...aber auf die GEräteeinstellungen und Staretn komm ich erst im hundertsten Untermenü. ts..
A bisserl mehr sein als Schein würde der GUI langsam mal wieder gut tun...
Verschlimmbesserung ist ein Phänomen unserer Zeit!
Zurück zum Thema... so muss also die Option ´start bei zugr. aus Inet´ bei mir ausgeschaltet bleiben, bei den betreffenden Pcs.
Noch unsinniger ist es allerdings die Magic-Packets von extern in dem bestehende VPN abzublocken.
Durch das VPN sollte eigentlich möglichst ALLES frei durchgeschleust werden - incl. Arbeitsgruppen-PCs und dort enthaltenen Freigaben und Druckern (wirklich wie als ob es alles im lokalen LAN wäre)
Gut, DAS ist dann vielleicht etwas viel verlangt... eine SCHNELLE (One-Click-)Lösung zum schnellen starten einzelner Rechner im VPN reichte mir aktuell schon.
Wenn mir jemand sagen kann, wie ich das per z.Bsp. Link zum PC-Starten-Button incl Login in de entfernte GUI. hinbekommen könnte...wäre schon echt viel
Oder bekommt man das Magic-Packet irgendwie durch, wenn das VPN ja bereits steht??
Danke für Eure Tipps..und Euren Aufwand den Ihr bisher bei dem Thema bereits betrieben habt)
PS:Nur weils vorhin mal im Thread war.....soll jetzt kein Thema werden....hat nicht hier im Forum vor Jahren sich schon mal jemand per Freetz ein ´Wake-On-Call´ gebaut? da war irgendwas mit Telnet und ähnlich wie Tr-064
Ich stehe vor einem sehr ähnlichen ´Problem´, wie eben WOL aus dem Internet.
Bin hier auch schon komplett durch den Thread...aber kann dabei nur bestätigen, dass ich einen schnell zugänglichen Button zum Starten des Pcs in der GUI echt gut fände.
Also gleich auf der Übersichtsseite neben den aufgelisteten Netzwerkgeräten oder ähnlich.
Es ist furchtbar, selbst bei dauerhaft bestehender VPN-Verbindung und im Browser hinterlegten Passwörtern sich bis ´PC-Starten´ durchzuklicken!
Nun zu meinem genauen Problem:
Bei mir besteht wie bereits geschr. die VPN-Verbindung zwischen zwei FBs dauerhaft.
Bei angeschalteter Option ´PC automatisch bei Zugriff aus dem Internet starten´ und aktivem VPN startet die FB den entfernten Rechner bei JEGLICHEM Zugriff auf diesen.
Sprich eigentlich dauernd wenn man zum Beispiel ein Netzlaufwerk verbunden hat, oder Windows nach dem externen Rechner im Netzwerk sucht.
(also Zugriffe aus dem ´externen Internet´ sind mir eigentlich egal)
Wie ist es hinzubekommen, dass man eben ein Netzlaufwerk auf einen Rechner der externen FB verbindet, dieser aber halt nur zur Verfügung steht, wenn der dortige PC sowieso läuft
oder wenn ich ihn EXPLIZIT anschalte.
Es geht mir also um das ausführen des Starvorgangs von einem externen Rechner, der aber bereits im gleichen VPN ist.
Ich könnte sogar mit einer art HTML-Skript oder ähnlichem leben.
Irgendwas auf dem Desktop... Doppelclick--externer Rechner startet.
Auch durch die bereits bestehende VPN-Verbindung blockt die entfernte FB Programme wie WOL2 oder die WOL-Möglichkeiten vom Teamviewer oder UVNC komplett ab.
Eigentlich finde ich es sogar ziemlich unsinnig von AVM geregelt, dass bei bestehender VPN(!!!) eben JEDE(!!!) Anfrage auf das entfernte Gerät die FB zum Versand des Magic-Packets anregt, wenn die Option ´Starten bei Internetzugrif´ aktiviert ist. Ich will ja eben nicht das der Rechner dauernd aufwacht, sondern ihn nur SCHNELL anschalten wenn ich ihn brauche oder er eh läuft.
Per GUI is aber nix mit schnell mal anschalten.
Das ist doch ne Funktion die ich tausend mal öfters benötige als ein DECT-Tel neu anzumelden.
Die gehört gleich auf die Startseite gelegt (von mir aus als anschaltbare Option).
Und die gehört auch gleich ganz DICK auf die erste ganz externe Loginseite..und auch auf die Übersichtsseite der MY-Fritz-Website...einfach überall hin
Aber Platz für irgendwelche doofen Schemazeichnungen is mittlerweile genug..
von der kommt man ja sogar auf Web-Guis der Gerate per einem Klick - wenn das GErät eins hat...aber auf die GEräteeinstellungen und Staretn komm ich erst im hundertsten Untermenü. ts..
A bisserl mehr sein als Schein würde der GUI langsam mal wieder gut tun...
Verschlimmbesserung ist ein Phänomen unserer Zeit!
Zurück zum Thema... so muss also die Option ´start bei zugr. aus Inet´ bei mir ausgeschaltet bleiben, bei den betreffenden Pcs.
Noch unsinniger ist es allerdings die Magic-Packets von extern in dem bestehende VPN abzublocken.
Durch das VPN sollte eigentlich möglichst ALLES frei durchgeschleust werden - incl. Arbeitsgruppen-PCs und dort enthaltenen Freigaben und Druckern (wirklich wie als ob es alles im lokalen LAN wäre)
Gut, DAS ist dann vielleicht etwas viel verlangt... eine SCHNELLE (One-Click-)Lösung zum schnellen starten einzelner Rechner im VPN reichte mir aktuell schon.
Wenn mir jemand sagen kann, wie ich das per z.Bsp. Link zum PC-Starten-Button incl Login in de entfernte GUI. hinbekommen könnte...wäre schon echt viel
Oder bekommt man das Magic-Packet irgendwie durch, wenn das VPN ja bereits steht??
Danke für Eure Tipps..und Euren Aufwand den Ihr bisher bei dem Thema bereits betrieben habt)
PS:Nur weils vorhin mal im Thread war.....soll jetzt kein Thema werden....hat nicht hier im Forum vor Jahren sich schon mal jemand per Freetz ein ´Wake-On-Call´ gebaut? da war irgendwas mit Telnet und ähnlich wie Tr-064
Zuletzt bearbeitet:
Neueste Beiträge
-
FRITZ!Box 7590 / FRITZ!OS 8.00 vom 31.10.2024- Letzte: Gildehauser
-
Kann mir jemand sagen was das ist ?- Letzte: stoney
-
Mesh System- schlechter Empfang
- Letzte: frank.lennert20
-
[Sammlung] FRITZ!Smart Thermo 302 - Firmware 0.22 - 5.xx- Letzte: Jstessi
-
FRITZ!Box 7590 bootet nicht.
- Letzte: Paulschx
