Fritzbox 7490 , Wake-on-Lan über UDP Port 9 klappt nicht mehr

palast

Neuer User
Mitglied seit
11 Okt 2008
Beiträge
76
Punkte für Reaktionen
3
Punkte
8
Hallo,

ich habe bisher einen Rechner meines Heimnetzwerks per Magic Packet auf UDP-Port 9 per LAN und per Internet aufwecken können.
Auf der Fritzbox habe ich einen permanenten ARP-Eintrag für diesen Rechner eingerichtet und in der Fritzbox eine Portweiterleitung von UDP 9 auf UDP 9 eingerichtet.

Seit ca. 1 Woche erreicht das Magic Packet per öffentliche IP oder per DYNDNS den aufzuweckenden Rechner nicht mehr, auch nicht aus dem LAN. Per LAN und lokale IP klappt es nach wie vor.

Wenn ich allerdings UDP Port 7 verwende (Fritzbox-Portweiterleitungen entsprechend angepasst), klappt es wie bisher problemlos. Anscheinend kann nur der Port 9 nicht mehr verwendet werden.
Außerdem war das Verhalten nach meiner Erinnerung bei Verwendung einer DYNDNS-Adresse bisher so, dass wenn sie lokal aufgerufen wurde, dies durch einen Loop intern verarbeitet wurde, also gar nicht über die öffentliche IP ging.

Da ich vor 1 Woche auf die Firmware 6.51 (von davor 6.31) ugdedated habe, liegt der Verdacht nahe, dass für diese Verhaltensänderung die neue Firmware zuständig ist.
Kann das jemand bestätigen oder muss ich nach einer anderen Ursache suchen?
 
Es liegt an der Firmware-Version, bei dieser wird ein (unsichtbares) Forward für UDP 9 (das ist ja eigentlich ein Service, der per Definition "discard" heißt und das auch so macht/machen sollte/machen darf) auf die interne IP-Adresse der FRITZ!Box angelegt:
Code:
$ cat /proc/kdsld/dsliface/internet/ipmasq/pcp44
[...]
MAP  TCP [192.168.178.1]:9 [217.7.yyy.zzz]:9, lifetime 120 secs, expire in 85 secs
     nonce 364c0ff98cc24d84f23f7713
     "IGDPROBE4"
     filter version 1
     <= [255.255.255.255]/128 port 9
     wanted_lifetime 120 lifetime 120
     pid 3341 caddr [192.168.178.1] inuse 0
[...]
Ob der Port jetzt wirklich irgendwie im Zusammenhang mit dem "Port Control Protocol" benötigt wird (als so eine Art "Not-Ping" für ein Provider-Gateway, das seinerseits prüfen will, ob ein PCP-Client noch reagiert und eine Reservierung damit weiterhin aufrecht zu erhalten ist - IGD dürfte ein "Internet Gateway Device" sein und "PROBE" ist eigentlich auch klar, so ein Forwarding dürfte ein "ICMP destination unreachable" verhindern), weiß ich auch noch nicht ... aber da dieses Forwarding nicht einstellbar ist, kann man es auch nicht deaktivieren und damit mußt Du entweder einen anderen Port nehmen oder einen anderen Mechanismus, bei dem das "magic packet" nicht aus dem Internet kommt, sondern erst auf der FRITZ!Box erzeugt wird - so wie es die WOL-Funktion der FRITZ!Box am Ende macht.
 
Danke Peter Pawn.
Ich nehme mal so mit, dass diese Änderung in der Firmware den Port 9 für meine Zwecke dauerhaft unnutzbar macht.

oder einen anderen Mechanismus, bei dem das "magic packet" nicht aus dem Internet kommt, sondern erst auf der FRITZ!Box erzeugt wird - so wie es die WOL-Funktion der FRITZ!Box am Ende macht.
Hat sich mit dem Thema schon mal jemand beschäftigt?
Die jetzige Lösung der Fritzbox ist für meine Zwecke nicht wirklich geeignet, denn dort kann man nur einstellen, dass jegliches Ansprechen aus dem Internet den betreffenden PC aufweckt. Da ist meine Lösung mit dem Magic Packet, wo der Aufwecker zumindest die MAC-Adresse des Gerätes wissen und mitgeben muss, schon etwas restriktiver.

Wie weckt eigentlich die Fritzbox, mit einem Magic Packet? Mein Magic-Packet-Monitor auf dem Rechner protokolliert jedenfalls kein eingehendes Magic Packet, wenn ich im Web-Interface der Fritzbox den Befehl zum Wecken anklicke. Aber vielleicht wird durch die Software der Box das Magic-Packet gar nicht abgesendet, wenn der Rechner schon an ist?

Habe ich Dich so richtig verstanden, dass eine Lösung möglich ist, bei der man extern die Fritzbox veranlassen kann, den internen Aufweckmechanismus für einen Rechner zu triggern?
 
Zuletzt bearbeitet:
Im Prinzip ist das richtig verstanden ... wobei ich nicht so richtig verstehe, wo das "Sicherheitsproblem" liegt (die Anführungszeichen nicht als Relativierung verstehen, nur als Hervorheben des Kritikpunktes an der AVM-Lösung, wie ich ihn verstanden habe).

Will man seinen Netzwerk-Cilient automatisiert starten, sowie aus dem Internet darauf zugegriffen wird, nimmt man eben die "Computer starten"-Einstellung aus der Portweiterleitung für diesen Client.

Will man nicht, daß jeder eingehende Verkehr den Client weckt, benutzt man eben das Webinterface (das wäre dann am Ende meinetwegen "curl" oder "PowerShell" oder was auch immer man beherrscht) und man greift einfach direkt auf die Funktion zu, die sich hinter dem "Computer starten"-Button "verbirgt".

Hier ersetzt der richtige Account zum Zugriff auf das GUI dann die Kenntnis der MAC-Adresse und - im Gegensatz zur Lösung mit dem "discard"-Port - ist das auch tatsächlich verschlüsselt und damit bleibt die MAC-Adresse dann auch "geheim".

Das hat dann sogar noch den Vorteil (so jedenfalls meine Interpretation), daß man anstelle irgendeines Programms zum Senden von "magic packets" (die deutlich rarer sind und eher selten auf anderen PCs als den eigenen zu finden sein dürften) auch mal mit einem beliebigen (aktuellen) HTTP-Browser manuell zugreifen kann, wenn man keinen Rechner mit dem "automatisierten HTTP-Start" bei der Hand hat.

Ansonsten stimmt vermutlich irgendetwas mit Deinem Packet-Dump nicht, die FRITZ!Box setzt jedenfalls bei jedem Druck auf den "Computer starten"-Button (bei mir jedenfalls) ein "magic packet" als Broadcast ab, egal ob der Client läuft oder nicht. Ob das beim automatischen Wecken bei Traffic-Eingang auch so ist (oder bei TCP nur bei SYN-Paketen, wobei die Frage wäre, wie es dann bei UDP aussieht), wollte ich schon lange mal wieder testen ... es gibt halt so viel zu tun und so wenig Zeit dafür.
 
... (bei mir jedenfalls) ein "magic packet" als Broadcast ab, ...

BTW: Bei meiner FB auch so. Z. B.:
Code:
:~$ sudo tcpdump -vvveni any ether proto 0x0842
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:43:11.082889   [color=red][b]B[/b][/color] <MAC-Adresse-FritzBox> ethertype Unknown ([color=red]0x0842[/color]), length 118: 
	...
 
Im Prinzip ist das richtig verstanden ... wobei ich nicht so richtig verstehe, wo das "Sicherheitsproblem" liegt (die Anführungszeichen nicht als Relativierung verstehen, nur als Hervorheben des Kritikpunktes an der AVM-Lösung, wie ich ihn verstanden habe).
Ich würde mir da eine weitere Option wünschen, dass nur der Eingang eines Magic Packet das Aufwecken einleitet.

Auf dem Rechner läuft ein Webserver mit Accountabfrage. Darauf hat nur ein kleiner Kreis von Freunden Zugriff, die absolut nicht PC-affin sind und denen ich eine Aufruffunktion mit Desktop-Icon und eingebauter Weckfunktion zur Verfügung gestellt habe. Sie sind halt so nur einen Doppelklick von der Benutzerabfrage des Webservers entfernt.

Nach einiger Zeit der Inaktivität legt sich der Rechner schlafen und der Zugriff durch externe autorisierte Personen erfolgt im Schnitt nur 10x/Woche. Seit ich das neuerliche Portproblem festgestellt habe, habe ich übergangsweise die interne Fritzbox-Funktion aktiviert mit der Konsequenz, dass der Rechner viel häufiger geweckt wird.

Will man nicht, daß jeder eingehende Verkehr den Client weckt, benutzt man eben das Webinterface (das wäre dann am Ende meinetwegen "curl" oder "PowerShell" oder was auch immer man beherrscht) und man greift einfach direkt auf die Funktion zu, die sich hinter dem "Computer starten"-Button "verbirgt".
Das erfordert aber doch Passwortkenntnis des Routers und auch meinen Freunden möchte ich solche Daten nicht zur Verfügung stellen.
 
Angesichts des bereits betriebenen Aufwands (Skript und Icon bei den Benutzern), ist es ja nur noch ein kleiner Schritt zu einem gesonderten Webserver auf der FRITZ!Box (oder einem nachgeschalteten Einplatinen-Computer, wenn man sich an die FRITZ!OS-Firmware nicht heranwagen will), der seinerseits bereits die Credentials der zulässigen Benutzer abfragt und dann nur bei einem gültigen Zugriff ein "magic packet" aussendet.

Wenn Du das nicht mit (zusätzlichen) Credentials absichern willst (die die Benutzer dann angeben müßten), nimm einfach "stunnel" oder irgendeinen anderen TLS-Wrapper und gib an die berechtigten Clients ein passendes Client-Zertifikat aus, damit macht dieser Wrapper die Authentifizierung (und gleichzeitig die Sicherung gegen Replays) und der kann dann auch wieder das Ethernet-Paket zum Wecken des eigentlichen Servers absetzen.

Dein Anwendungsfall ist halt so speziell, daß (meiner Meinung nach jedenfalls) eine entsprechende Implementierung im FRITZ!OS keinen wirklichen Sinn ergibt, zumal es als wirksamer "Schutz" gegen absichtliches fremdes "Einschalten" eben vollkommen unzureichend ist, nur auf eine MAC-Adresse als "secret" zu setzen ... so ein Paket wäre ja ohne zusätzliche Maßnahmen jederzeit abzufangen und zu duplizieren. Wenn der Server bei der AVM-Lösung zu oft "geweckt" wird auch von eigentlich nicht autorisiertem/erwünschten Traffic, hilft ja event. schon das Verschieben auf einen anderen Port, der in einem normalen Scan eher nicht abgefragt wird.

Ich kann in dem (neuen) Verhalten der FRITZ!Box jedenfalls nicht unbedingt ein "Fehlverhalten" erkennen, denn diese Pakete kommen eben bei ihr an und enthalten ja auch ihre eigene (externe) IP-Adresse. Damit hat sie (per Definition) jedes Recht, diese Pakete auch zu verarbeiten und die definierte "Verarbeitung" dafür ist halt "discard" und nicht "forward to client", noch dazu, wenn dieser Mechanismus (von einem Protokoll zu sprechen, wäre schon etwas hochgegriffen, das ist fast überall direkt im IP-Stack oder spätestens in einem "super server" wie inetd intern realisiert) ggf. für eigene Zwecke benötigt wird.

Wenn es Dir nur um die Lösung des beschriebenen Problems geht, nimm halt irgendeinen anderen (externen) Port und schicke Deine "magic packets" dorthin (Du schreibst ja, da werden sie dann an den Client weitergereicht mit "reverse NAT") - wenn Du willst, kann das ja dann intern auch wieder an UDP/9 gehen.
 
Meine ursprüngliche Frage ging ja auch mehr in die Richtung, was die Ursache der plötzlichen Verhaltensänderung ist und ob ich mit der Firmwareänderung als Grund richtig liege.
Der Wechsel auf einen anderen Port stellt für mich kein wirkliches Problem dar und wurde bereits vorgenommen.

Die Beschränkung auf das Magic Packet und die MAC-Kenntnis habe ich auch weniger als Sicherheitsschranke gesehen als einfach eine praktische Beschränkung, die verhindert, dass der PC öfters als nötig aufwacht.
In der Praxis kann ich mich jedenfalls nicht an ein unauthorisiertes Aufwecken in den letzten Jahren erinnern.

Zum fehlerhaften Packet-Dump in Zusammenhzang mit dem internen Magic-Packet der Fritz!box..
Ich habe noch nicht mit einem generellen Sniffer getestet sondern mit dem "Spezialisten WOLSniffer" (https://www.apreltech.com/Free/Wake_on_lan_Packet_Sniffer)
Mit dem bekomme ich keinen Eingang eines Magic Packets auf dem Zielrechner angezeigt, wenn ich die Fritz!Box-Aufweck-Funktion betätige.
 
Ok, ehe wir aneinander vorbei schreiben, fasse ich für spätere Leser mal zusammen, was ich bisher geschrieben habe bzw. ausdrücken wollte:

1. Es gibt eine Änderung in der Firmware ab 06.50 (hier in Punkt 14 festgehalten), deren eigentlicher Sinn (es ist wohl ein Broadcast an die externe IP-Adresse der Box erforderlich, damit das nicht weggefiltert wird und der kann ja eigentlich nur vom DSLAM kommen bzw. von einem direkt mit dem WAN-Interface verbundenen Router oder dieser "filter" besagt sogar, daß das Paket als Absenderadresse eine (IP-)Broadcast-Adresse haben soll - was dann noch unverständlicher für mich wäre) nicht ganz klar ist.

2. Ob diese Änderung jetzt dazu führt, daß keine Pakete mit einer "unicast"-Adresse mehr bis zum LAN-Interface der FRITZ!Box vordringen können, weiß ich auch nicht definitiv - ich halte es aber für wahrscheinlich ... ohne eigenen DSLAM ist das aber privat kaum zuverlässig zu testen, weil schon die Umschaltung auf "LAN1-Modus" das Ergebnis verfälschen könnte.

3. Wer "nur" eine WoL-Funktion braucht und bisher jahrelang die hier mal beschriebene Version (die auch bei heise.de mal als "Wake on WAN" vor fast 10 Jahren beschrieben wurde) verwendet hat, bekommt Probleme, wenn Nr. 2 zutreffend sein sollte.

4. Für "normale" Fälle ist es unproblematisch, dann auf die AVM-Funktionen zu setzen - braucht man eine "anonyme" Startmöglichkeit, greift man zur Portweiterleitung mit automatischem Wecken des Servers und legt das zur Minimierung der Unterbrechungen von Tiefschlafphasen auf einen "unusual port", wenn es kein "öffentlicher Dienst" sein soll (das empfahl der heise.de-Artikel schon vor Jahren auch für die externe Benutzung von "discard", weil man sich nicht auf ein definiertes Verhalten bei der Weiterleitung dieses Ports verlassen sollte, zumindest nicht bei unterschiedlichen Modellen/Herstellern) - bei einem solchen "public service" macht dann aber auch die Forderung "nur starten bei zulässigem Benutzer" generell Probleme ohne passenden Auth-Proxy. Aber für "private services" ist das nach wie vor eine praktikable Lösung, denn selbst in der heutigen Zeit umfaßt ein Portscan nur selten irgendwelche "Phantasie"-Ports, einfach weil ein Scan von > 60.000 Ports auch so seine Zeit braucht - vor allem dann, wenn da keine "unreachable"-ICMP-Pakete zurückkommen und der Scanner auf "timeout" warten muß für die Entscheidung. Wer solche Ports dann auch ohne Credentials gegen unabsichtliche/unberechtigte Nutzung absichern will, kann z.B. zum guten alten "Hausmittel" in Form von "port knocking" greifen - das geht notfalls mit einem "nc" und einer "shell" auf der Serverseite und läßt sich auch clientseitig i.d.R. ohne (allzu) spezielle Programme umsetzen.

Zur Frage des Packet-Dumps ... ich kann natürlich mangels Angaben nur raten, aber da würde ich trotzdem am anderen Ende der "Verbindung" mit der Suche beginnen, weil mir mehrere Gründe einfallen würden, woran dieses Anzeigeprogramm scheitern könnte.

Einige davon können durch vorher schon mal erfolgreiche Anzeige von Paketen mit demselben Aufbau (es gibt ja mehrere Arten der "Adressierung" solcher Pakete und UDP/9 ist ja genau wegen "discard" und der damit einhergehenden "Unmöglichkeit" einer mißverständlichen Kommunikation für diesen Zweck so beliebt, die FRITZ!Box sendet einen L2-Broadcast und muß damit nicht "wissen", an welchem Port der Server hängt) tatsächlich von Beginn an ausgeschlossen werden, wenn das Programm auf genau demselben Rechner (damit nicht der Netzwerkkarten-Treiber ein erfolgreich erkanntes WoL-Paket vielleicht seinerseits schon "konsumiert") und mit genau derselben Windows-Version (die unterstelle ich, weil es sich um ein Windows-Programm handeln dürfte dem Screenshot nach zu urteilen und auch der IP-Stack käme als "Konsument" in Frage) die passenden Pakete (siehe Beginn dieses Satzes) früher anzeigen konnte.

Auch der Aufbau des Netzwerks kann da noch eine Rolle spielen, weil ja so ein WoL-Paket tatsächlich nur dann den Adressaten erreichen kann, wenn alle auf dem Weg zwischen FRITZ!Box und Server liegenden Geräte die MAC-Adresse des ausgeschalteten Servers (bei einem UC-Paket, wie es vermutlich von der bisher verwendeten Lösung erzeugt wird, sonst bräuchte es ja den in #1 erwähnten ARP-Eintrag gar nicht) auch dem richtigen Port zuordnen können. Wenn irgendein Switch seinerseits an einen Port, der mit dem schlafenden Server verbunden ist (und in gewisser Weise damit für den Switch "down" ist), nur UC-Pakete weiterreicht und keine BC-Pakete, dann kann auch der natürlich verantwortlich sein - in diesem Falle aber wohl eher nicht.

Schon der Einsatz dieses Scanners auf dem Zielgerät (das in diesem Falle ja dann schon eingeschaltet ist), verfälscht in gewisser Weise das Meßergebnis ... auch wenn das bei mir (und wohl auch bei sf3978) keine Rolle für das Aussenden des Broadcast-Paketes (da ist schon mal ein Unterschied zum angenommenen UC) spielt.
EDIT: Ich habe gerade noch einmal nachgesehen, die FRITZ!Box sendet natürlich ein Ethernet-Broadcast-Paket an den Host und das hat absolut nichts mit einem IP-Paket zu tun - und schon gar nichts mit einem UDP-Paket an Port 9.
Code:
14:50:55.091362 08:96:d7:6e:9a:31 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x0842), length 116:
        0x0000:  ffff ffff ffff 0001 2e41 9577 0001 2e41  .........A.w...A
        0x0010:  9577 0001 2e41 9577 0001 2e41 9577 0001  .w...A.w...A.w..
        0x0020:  2e41 9577 0001 2e41 9577 0001 2e41 9577  .A.w...A.w...A.w
        0x0030:  0001 2e41 9577 0001 2e41 9577 0001 2e41  ...A.w...A.w...A
        0x0040:  9577 0001 2e41 9577 0001 2e41 9577 0001  .w...A.w...A.w..
        0x0050:  2e41 9577 0001 2e41 9577 0001 2e41 9577  .A.w...A.w...A.w
        0x0060:  0001 2e41 9577                           ...A.w
Wenn der verwendete WoL-Sniffer da nicht praktisch direkt an der Netzwerk-Karte "lauscht" (da, wo die libpcap auch ansetzen würde), dann sieht der von diesem Paket logischerweise nichts ... aber das weißt Du sicherlich besser bzw. kannst es ergründen, ob das Programm das überhaupt könnte - ich installiere bei mir keine Programme aus dem Internet für solche Tests (weil ich sie in dieser "spezialisierten Form" nie bräuchte und dann lohnt sich die Recherche nach der Reputation solcher Programme nicht).
 
Zuletzt bearbeitet:
Bei keinem in Deutschland üblichen Provider macht der DSLAM IP für Internet, daher kann auch er kein Broadcast an die FB schicken.
 
Du hast mich erwischt ... da will ich mich mal etwas kürzer fassen und setze an die Stelle einer weitschweifigen Erklärung, was sich alles "hinter" dem DSLAM noch an Komponenten anschließen kann, bevor das AS des Providers in Richtung "Internet" verlassen wird, nur die den meisten geläufige Bezeichnung "DSLAM", da ist das dann schon so "unpräzise", daß es Widerspruch heraufbeschwört. :mrgreen:

Der gezeigte Eintrag in der FRITZ!Box befindet sich ja in "trauter Nachbarschaft" mit jeder anderen in der FRITZ!Box vorgenommenen "Portfreigabe", egal ob benutzerdefiniert oder im FRITZ!OS festgelegt. Diese beschreiben ja auch alle eine "Weiterleitung" auf L3 (oder höher) des OSI-Modells ... die Tatsache, daß auf der Transportstrecke zwischen B(R)AS und FRITZ!Box die IP-Pakete überwiegend in PPPoE gekapselt werden in D, ändert ja nichts daran, daß diese PPPoE-Pakete zum Zeitpunkt der "Anwendung" der Forwardings bereits wieder "decapsulated" sind (sonst würden ja die gleichberechtigt neben der gezeigten Weiterleitung existierenden Einträge für SIP/RTP, HTTPS, FTP, usw. irgendwie auch keinen Sinn/Effekt ergeben) und da ein Paket mit einer Broadcast-Adresse (ich schrieb ja mehr oder weniger deutlich, daß ich auch nicht genau einschätzen kann, ob sich
Code:
filter version 1
<= [255.255.255.255]/128 port 9
nun auch die Quell- oder Zieladresse eines Paketes bezieht - da BC-Adressen als Absender schon sehr gewöhnungsbedürftig sind, tippe ich auf Zieladressen) nur irgendwo aus dem Netz nach dem letzten Router stammen kann, wo dann die Adressierung auf anderen Protokollen basiert (ansonsten würde ein Broadcast-Paket im RZ von Google ggf. bis zu meinem eigenen Internetanschluß "durchschlagen" und auch den Router als "Domänengrenze" habe ich schon vorher noch einmal explizit erwähnt), wäre ich viel mehr daran interessiert, wenn mir jemand erklären kann, wozu dieser Eintrag tatsächlich benutzt wird.

Eine Internet-Recherche nach einem Protokoll oder einer -Erweiterung, die auf die Verwendung des "discard"-Services baut, war leider erfolglos - so bin ich zum Spekulieren gezwungen, wofür das gut sein könnte und das würde ich gerne ändern.

Solltest Du dazu hilfreiche Informationen haben, wäre mir das viel lieber ... ich gestehe aber unumwunden ein, daß die Aussage zum "DSLAM" sehr ungenau und stark vereinfacht war.

Aber auch nur unter den Bedingungen in Deutschland und auf der anderen Seite bin ich mir gar nicht 100%ig sicher, daß diese gezeigte Weiterleitung überhaupt in D beim DSL-Betrieb einer FRITZ!Box benutzt wird - auch wenn sie in einer 7490 am VDSL-Anschluß (feste IPv4 über PPPoE) sichtbar ist ... offenbar bei anderen ja auch, wenn die Probleme von @palast damit zusammenhängen.

Andererseits wieder bin ich mir gar nicht so sicher, wie Du es offenbar bist, daß auch jeder Stadtnetzbetreiber, der für die letzte Meile dann wieder auf DSL setzt, dafür tatsächlich immer PPP als Kapselung für IP verwendet und nicht sogar immer mehr "native IP" an dieser Stelle eingesetzt wird ... ich bilde mir sogar ein, daß ich es an einem komDSL-Anschluß mal gesehen hätte, daß dort ganz normales IP verwendet wurde. Leider habe ich keine derartige Box aktuell im Zugriff, aber das sähe dann in etwa so aus (hier ein Swisscom-VDSL-Anschluß in der Schweiz):
Anhang anzeigen 85700Anhang anzeigen 85701
Nun schreibst Du ja von einem "üblichen Provider" in Deutschland ... insofern könnte so eine Benutzung von DSL für die letzte Meile ja auch als "unüblich" gelten. Wenn das aber auch bei EWETEL oder NetCologne oder HanseNet z.B. so laufen sollte (ich weiß es zugegebenermaßen nicht), verlassen wir den Bereich des "Unüblichen" eigentlich schon wieder.

Ansonsten wird auch die Abgrenzung der Komponenten auf der Serverseite einer DSL-Verbindung immer schwerer, ich finde die "Zusammenfassung" hier ganz gelungen: http://cp.literature.agilent.com/litweb/pdf/5989-4766EN.pdf

Da aber gerade die kleineren Stadtnetzbetreiber auch gerne mal DS-Lite verwenden zum Anschluß der Kunden, weil ihnen die IPv4-Adressen fehlen und das "port control protocol" nach RFC 6970 ja u.a. dazu dienen soll, daß ein IGD über einen PCP-Server beim Provider solche Mappings einrichten kann, halte ich die mögliche Erklärung, daß das als eine Art "ping" benutzt wird, ob das IGD noch aktiv ist (der "Name" IGDPROBE4 bringt mich auf diese Idee) bzw. ggf. auch nur als (ungerichteten) "Trigger" für die Erneuerung solcher Reservierungen nach wie vor für denkbar. Auch die Verwendung des "discard"-Services in diesem Zusammenhang würde Sinn ergeben, denn der würde eben den Rest der Kommunikation nicht beeinflussen/verändern. Schön wäre es aber eben, wenn man an die Stelle dieser denkbaren Erklärung eine setzen könnte, die auf Wissen beruht - insofern "sauge" ich jede andere denkbare Erklärung dankbar auf.
 
Zuletzt bearbeitet:
@palast

funktioniert bei dir WOL über Internet (z.B. von unterwegs per WOL-App vom Smartphone aus) auch dann noch, wenn du nur die entsprechende Port-Weiterleitung (in deinem Fall aktuell UDP Port 7) in der Fritzbox konfiguriert hast und die Option "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird". deaktiviert ist?
 
funktioniert bei dir WOL über Internet (z.B. von unterwegs per WOL-App vom Smartphone aus) auch dann noch, wenn du nur die entsprechende Port-Weiterleitung (in deinem Fall aktuell UDP Port 7) in der Fritzbox konfiguriert hast und die Option "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird". deaktiviert ist?

Das funktioniert bei mir und ich nutze diese Variante bei mir schon seit Jahren mit verschiedenen Fritzbox-Modellen. Dein "nur" bezogen auf die Portweiterleitung muss jedoch um die generellen Voraussetzungen für WOL und Besonderheiten für die Fritzboxen erweitert werden.

Um nicht zu viel schreiben zu müssen und vielleicht ist Dir das auch alles bekannt, füge ich mal für die generellen Voraussetzungen bei Windows diesen Link an:
https://oette.wordpress.com/2013/01/25/den-pc-fur-wake-on-lan-wake-on-wlan-konfigurieren-windows/

Damit das auch aus dem Internet klappt muss jedoch der Router permanente ARP-Einträge ermöglichen, was die mir bekannten Heimgeräte zumindest über ein Menü nicht bereitstellen.
Dieser permanente ARP-Eintrag bedeutet die dauerhafte Zuordnung der IP-Adresse eines Clients mit seiner MAC-Adresse. Dies ist erforderlich, da diese Zuordnung normalerweise nur im ARP-Cache landet und wenn der Client heruntergefahren ist, nach einiger Zeit gelöscht wird. Das führt dann zu dem Effekt, dass das Aufwecken per WOL aus dem Internet zwar nach dem Herunterfahren des Rechners für etliche Minuten klappt, nach einiger Zeit jedoch nicht mehr.
Natürlich ist auch ein dynamischer DNS-Dienst von Nutzen, wenn man keine feste öffentliche IP-Adresse hat.

Bei den Fritzbox (eingebaut zumindest bei neueren Modellen und neueren Firmwares) kann man einen permanenten ARP-Eintrag mit der Busybox setzen. Früher musste ich den entsprechenden Busybox-Befehl nachrüsten, weil die von AVM verwendeten Busyboxen den ARP-Befehl nicht enthielten.
arp -s IP-Adresse Mac-Adresse
Das Absetzen des Befehls kann innerhalb einer Telnet-Session geschehen. Ich habe ihn in die debug.cfg der Fritzbox eingebaut, damit er bei jedem Neustart wieder abgesetzt wird.

Die neueren Firmwares meiner 7490 verfügen nicht mehr über ein Aktivieren von Telnet und auch nicht mehr über eine debug.cfg.
Um dennoch weiterhin auf gewohnte Weise WOL über meine Fritzbox nutzen zu können, habe ich das Projekt von PeterPawn verwendet:
http://www.ip-phone-forum.de/showthread.php?t=273304
 
Ok, also die Option "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird." ist und war bei dir schon immer deaktiviert?

Das Problem bei meiner Fritzbox 7360 ist, dass ich diese von meinem ISP (wilhelm.tel) bekommen habe und ich an ihr keine Modifikationen vornehmen kann (also auch keine Firmware-Updates).
 
Ok, also die Option "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird." ist und war bei dir schon immer deaktiviert?
Bei Firmwares meiner früheren Boxen gab es dieses Feature gar nicht. Ansonsten habe ich von dieser Lösung über das Fritzbox-Menü nie Gebrauch gemacht und statt dessen die klassiche Lösung der Versendung eines Magic Packets von außen genutzt.

Das Problem bei meiner Fritzbox 7360 ist, dass ich diese von meinem ISP (wilhelm.tel) bekommen habe und ich an ihr keine Modifikationen vornehmen kann (also auch keine Firmware-Updates).
Heißt das, dass Deine Box dieses Feature gar nicht bietet bzw. Du es nicht aktivieren kannst, es gerne aber tätest?
 
Ja, also ich würde gerne WOL über Internet nutzen können, ohne die Option "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird." aktivieren zu müssen.
Denn das Problem, das ich habe ist, dass sobald ich eine Port-Weiterleitung (z.B. TCP Port 21, weil mein Rechner zuhause u.A. als FTP-Server fungiert) eingerichtet habe und gleichzeitig diese Option "Diesen Computer automatisch starten, sobald..." aktiviere, dass dann zwar WOL über Internet funktioniert, aber mein Rechner auch mehrmals am Tag willkürlich, ohne dass ich es wünsche, von der Fritzbox geweckt wird.

Deaktiviere ich entweder die Port-Weiterleitung oder die besagte WOL Funktion in der Fritzbox, dann wird mein Rechner zwar nicht mehr willkürlich geweckt, aber es funktioniert dann eben auch kein WOL über Internet mehr (und ohne Port-Weiterleitung ist mein FTP-Server natürlich auch nicht mehr erreichbar).

Ich hatte mich wegen dieser Problematik auch schon an den AVM-Support gewendet, aber die sehen keinen Fehler bei sich bzw. der Fritzbox.
Fakt ist aber, dass mit anderen Routern (z.B. Linksys WRT54G) es problemlos möglich ist, Port-Weiterleitungen und WOL über Internet zu nutzen, ohne dass der entsprechende Rechner ungewollt geweckt wird.
Ich bin mit dieser Problematik ja auch kein Einzelfall. Wenn man die google-Suche bemüht, findet man sehr viele Leute mit genau dem gleichen Problem. Alle mit Fritzboxen.
 
Zuletzt bearbeitet:
Ich bin mit dieser Problematik ja auch kein Einzelfall. Wenn man die google-Suche bemüht, findet man sehr viele Leute mit genau dem gleichen Problem. Alle mit Fritzboxen.
Ich fände es auch sinnvoll, wenn AVM (zumindest als Alternative) es ermöglichen würde, dass nur auf ein Magic Packet von außerhalb reagiert würde. Schließlich gibt es diese Option auch in Windows, wo man beim in den Ernegieeinstellungen des LAN-Adapters getrennt einstellen kann, ob auf ein "Magic Packet" oder auf "Any Packet" reagiert werden soll.
Im Moment funktioniert das ja in Fritzboxen offenbar so, dass jeder Zugriff von außen auf den Rechner die Weckfunktion innerhalb der Fritzbox aufruft.

Bevor ich Fritzboxen hatte habe ich WOL in anderen Routern über Broadcast statt über die konkrete IP-Mac des aufzuweckenden Rechners realisiert.
www.heise.de/netze/artikel/Port-Forwarding-224180.html
Viele Router blockieren allerdings diesen Weg, u.a. die Fritzboxen. So bin ich dann auf den Weg über den permanenten ARP-Eintrag gekommen, dem allerdings AVM mit neueren Firmwares Steine in den Weg lädt. Sinnvoll wäre eigentlich auch die Möglichkeit, per Menü permanente ARP-Einträge zu erzeugen. Die vorhandene Option "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen" erledigt das offenbar nicht.
 
Zuletzt bearbeitet:
:) Endlich jemand, der mich versteht, und sich das Gleiche wünscht wie ich.
Es müssten sich noch viel mehr Fritzbox-User diesen Wünschen anschließen, damit AVM endlich mal reagiert.
Ich sehe es genauso wie du. AVM sollte in den Fritzboxen eine dieser beiden Möglichkeiten (nur auf Magic Packet von außerhalb reagieren oder Erzeugen von permanenten ARP-Einträgen) implementieren.

Wie kann man AVM dazu bringen, das zu tun?

Es reicht ja eine dieser beiden Möglichkeiten.
Welche würdest du persönlich präferieren?



Update:
Ich habe mal ein wenig im Bekannten-Kreis herumgefragt und ich habe da Jemanden, der einen kennt, der wiederrum einen ziemlich guten Draht zu AVM hat.
Ich soll das Ganze jetzt in einer Mail zusammenschreiben und das wird dann dorthin weitergereicht. Mit etwas Glück könnte das dann in einer neuen Firmware implementiert werden :)

Kann mir einer von euch vielleicht bei der Formulierung/Beschreibung der Problematik helfen?
 
Zuletzt bearbeitet:
Ich hingegen hoffe ganz stark, daß das so nicht umgesetzt wird.

Warum?

Es verkompliziert das GUI mit einer (weiteren) Einstellmöglichkeit, die kein "normaler Benutzer" braucht und für deren Verständnis schon etwas tiefergehende Netzwerk-Kenntnisse notwendig wären ... von der Problematik der verschiedenen Formen der Adressierung von WoL-Paketen fange ich jetzt lieber nicht an, das geht dann bis zum BIOS bei PCs und/oder sogar bis zum eingesetzten Betriebssystem auf dem zu weckenden Client.

Das, was AVM da im Moment umsetzt, ist das richtige "ursprüngliche" Magic-Packet nach AMD-Vorschlag (da kann man auch die "Infrastructure Implications" für verschiedene Topologien nachlesen), da wird nichts auf L2 (oder darüber) vorausgesetzt oder benutzt und dank Broadcast ist es (bei standardkonformer Technik im LAN, die L2-Broadcasts an alle Switch-Ports ausliefert, wobei auch da ja Anti-Flooding-Techniken wie Broadcast-Limits noch einen Strich durch die Rechnung machen können und der AMD-Vorschlag auch L2-Unicast berücksichtigt) auch weitgehend egal, wie die Topologie im LAN am Ende aussieht. Stellt man das dann wieder auf irgendwelche L3-Geschichten um, wird es auf einen Schlag komplizierter und fehleranfälliger ... und das soll ja nicht nur bei Kunden mit Netzwerk-KnowHow möglichst reibungslos funktionieren, sondern bei allen.

Das Erzeugen eines statischen ARP-Eintrags auf einer modifizierten FRITZ!Box ist ja nun alles andere als ein Kunststück (aber vollkommen ausreichend, damit das Wecken über "magic packets" per Weiterleitung funktioniert) und der spezielle Fall von @joinski in diesem Thread, der "seine" FRITZ!Box nicht modifizieren kann, ist ja nun auch eher untypisch bzw. sollte nicht als Begründung genommen werden, die Firmware für alle Benutzer komplizierter zu gestalten.

Für den "normalen Benutzer" reicht entweder das automatische Starten beim Zugriff auf das Gerät (natürlich über einen "Nicht-Standard-Port", wer das auf TCP/21 laufen läßt oder gar auf TCP/80, der muß sich nun wirklich nicht wundern), was auch ohne jedes zusätzliche Programm und ohne weitere Vorkehrungen (ggf. mit einem kleinen Delay zwischen dem ersten und weiteren Versuchen, damit das Gerät erst einmal starten kann) funktioniert.

Wer hingegen nur "bei Bedarf" (für sich selbst) starten will, der benutzt halt den Fernzugriff auf das GUI zum Starten (den Nachteil, daß der "Computer starten"-Button wohl nur mit administrativem Zugriff erreichbar ist, sehe ich tatsächlich auch, da wäre ggf. ein passender Button unter "MyFRITZ!" noch hilfreich, wobei auch da dann wieder die Frage nach den Berechtigungen auftaucht, die ja merkwürdigerweise beim Senden eines Magic-Packets über das Internet gar nicht gestellt wird) und wem das auch noch nicht reicht, der nimmt eben den sparsamen Einplatinen-Computer hinter der FRITZ!Box oder modifiziert die FRITZ!Box selbst, um sein Ziel zu erreichen, daß dann ja sicherlich auch nicht nur in irgendeinem simplen Datenzugriff bestehen wird, wenn schon das Szenario zum Starten des Servers so komplex ist.

Ich stelle mir bei solchen "Wünschen" (die zu äußern durchaus legitim ist, damit wir uns da nicht mißverstehen) immer die Frage, was das der Mehrheit der Kunden bringt bzw. ob es ihnen überhaupt etwas gibt und es sich nicht mehr oder weniger nur um sehr individuelle Bedürfnisse handelt. Wo sollte man dann eigentlich die Grenzen ziehen? Ich könnte mir z.B. auch vorstellen, daß man so ein Netzwerk-Gerät dann nicht nur per GUI oder automatisch (wie jetzt) oder per "magic packet" (wie hier diskutiert) wecken will, sondern auch noch mit einem Anruf (auf einer speziellen Nummer oder per IVR selektiert) oder gar einer SMS (oder irgendeiner XMPP-Message) ... das läßt sich nach Belieben fortsetzen und meines Erachtens sollte man dann entweder den Mumm haben, solche Wünsche selbst umzusetzen (wie @palast es ja macht) oder von den eigenen Bedürfnissen auf die der Allgemeinheit abstrahieren und seine eigenen Wünsche dann auch mal in dieser Richtung hinterfragen.

Aber solche Fragen wie
joinski schrieb:
Wie kann man AVM dazu bringen, das zu tun?
halte ich dann doch für übertrieben (und hier auch fehl am Platze) ... auch wenn der dafür eingerichtete "Firmware-Wünsche"-Thread eine erkleckliche Länge erreicht hat.

Bevor sich AVM jedenfalls an die Realisierung dieses Wunsches machen sollte, gäbe es (wieder nur aus meiner Position heraus - logischerweise -, aber auch ich könnte da einige "Unterstützer" auftreiben) noch viele weit wichtigere Baustellen.

Insofern stellt sich mir dann die Frage, warum man sich nicht einfach an das Modifizieren der 7360 macht (das ist u.U. sogar schneller erledigt, als so eine Mail an AVM zusammengeschrieben wäre) oder - wenn das mit einem Linksys WRT54G so problemlos machbar ist - nicht einfach ein kaskadierter Router (ggf. auch nur zum "Aufwecken" des Servers, man könnte dessen LAN ja sogar wieder zum FRITZ!Box-Switch zurückführen) verwendet wird.

Daraus jetzt einen "feature request" zu machen, der in den allerseltensten Fällen benutzt werden würde (zumindest beim durchschnittlichen Kunden), ist m.E. der falsche Weg ... schon die dann notwendige Auswahlmöglichkeit des "WoL-Verfahrens" (und die notwendige Erklärung der Optionen) verkompliziert die Bedienung der FRITZ!Box (und das für die - meines Erachtens - eben sehr seltenen Fälle, wo kein anderer Workaround ebenso eine Lösung wäre).
 
Welche würdest du persönlich präferieren?
Ich denke für die Allgemeinheit wäre eine einfache Option analog der Realisierung bei den Energieoptionen der Windows-Treiber die beste Lösung.
Dort hat man die Einschränkungsoption, dass nur ein Magic Packet den PC aufwecken kann. Analog würde eine Einstellungsoption bedeuten, dass die Fritzbox auf Wunsch nur durch ein Magic Packet veranlasst wird, den Weckbefehl loszulassen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.