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

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:
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.

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.

PeterPawn schrieb:

... (bei mir jedenfalls) ein "magic packet" als Broadcast ab, ...

Zum Vergrößern anklicken....

BTW: Bei meiner FB auch so. Z. B.:

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.

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.
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).

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
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.

@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?

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).

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.

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?

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?

Zum Vergrößern anklicken....

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).