Per Link direkt in die LAN Seite eines Netzwerkgerätes springen

Also, hier noch mal ganz ausführlich:

Abruf der Infos klappt: https://???.myfritz.net:44097/tr064/tr64desc.xml
Der Inhalt der XML sagt mir sehr wenig aber immerhin kommt da was...

Dann lasse ich das Sript laufen:

Code:
# SPDX-License-Identifier: GPL-2.0-or-later
###################################################################################
#                                                                                 #
# Wake-on-LAN for a known device via TR-064 function from FRITZ!OS                #
#                                                                                 #
###################################################################################
#                                                                                 #
# You need the MAC address of a LAN device, which must be known to your FRITZ!OS- #
# based router, and an user account with administrative rights, to wake up a LAN  #
# client from sleeping, using this script.                                        #
#                                                                                 #
###################################################################################
Param([Parameter(Mandatory = $False, Position = 0, HelpMessage = 'the username to login to TR-064')][string]$Username,
      [Parameter(Mandatory = $True, Position = 1, HelpMessage = 'the password to login to TR-064')][string]$Password,
      [Parameter(Mandatory = $False, Position = 2, HelpMessage = 'the MAC address of device to wake up')][string]$MAC,
      [Parameter(Mandatory = $False, Position = 3, HelpMessage = 'the internal TR-064 (TLS protected) port, defaults to 49443')][string]$Port = 49443,
      [Parameter(Mandatory = $False, Position = 4, HelpMessage = 'the IP address of the FRITZ!Box, defaults to 192.168.178.1')][string]$Address = "192.168.178.1")

$WebClient = New-Object System.Net.WebClient
$xml_query='<?xml version="1.0"?><s:Envelope xmlns:s="http:#schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http:#schemas.xmlsoap.org/soap/encoding/"><s:Body><u:X_AVM-DE_WakeOnLANByMACAddress xmlns:u="urn:dslforum-org:service:Hosts:1"><NewMACAddress>' + "??meineMAC??" + '</NewMACAddress></u:X_AVM-DE_WakeOnLANByMACAddress></s:Body></s:Envelope>'

$WebClient.Encoding = [System.Text.Encoding]::UTF8
$WebClient.Credentials = New-Object System.Net.NetworkCredential("???", $Password)
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:Hosts:1#X_AVM-DE_WakeOnLANByMACAddress')
$response = [xml]$WebClient.UploadString("https://" + "???.myfritz.net" + ":" + "44097" + "/upnp/control/hosts", $xml_query)

$response.Envelope.Body.InnerXml

und bekomme das hier:

Ausnahme beim Aufrufen von "UploadString" mit 2 Argument(en): "Der Remoteserver hat einen Fehler zurückgegeben: (404)
Nicht gefunden."
In C:\Temp\Rechner wecken.ps1:30 Zeichen:1
+ $response = [xml]$WebClient.UploadString("https://" + "??? ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WebException
 
Zuletzt bearbeitet:
Nun gut, das ist ja schon mal KEIN Timeout mehr. Nur stimmt jetzt eben der Pfad in der aufgerufenen URL NICHT, denn da fehlt jetzt das tr064 - somit ist die Reaktion der Box ("page not found") absolut plausibel.

Und eine MAC-Adresse ist per Definition im Netzwerk nur auf Layer 2 gültig, die muß man also nicht verschleiern, weil sie jenseits des eigenen Netzwerks ohnehin nicht erreichbar ist (bei Kabelnetzen gibt es da ggf. Ausnahmen, was solche Ersetzungen angeht).

Wenn man dann noch die Parameter/Variablen NICHT durch feste Zeichenketten an den jeweiligen Stellen, wo sie - u.U. auch mehrfach - benutzt werden, ersetzt, sondern - sofern tatsächlich notwendig, weil man's als Parameter beim Aufruf nicht angeben KANN - einfach am Beginn die eigenen Werte an diese Variablen zuweist, dann läuft man auch weniger Gefahr, bei den eigenen Anpassungen irgendetwas zu übersehen.

EDIT: Um es noch einmal ganz, ganz deutlich zu machen - die einzige NOTWENDIGE Änderung am Skript wäre das Hinzufügen von tr064 zum Pfad beim UploadString (was ja aber gar nicht vorhanden ist). Alles andere ist bereits als Parameter "nach außen gelegt" und müßte nur korrekt angegeben werden beim Aufruf. Wer das Skript sowohl aus dem LAN, als auch von extern nutzen will, der definiert einfach einen weiteren Parameter beim Aufruf, mit dem dann entschieden wird, ob das tr064 im Pfad enthalten sein soll/muß oder nicht.
 
Zuletzt bearbeitet:

Zudem ermöglicht es TR-069 auch, andere Geräte zu konfigurieren, die sich im „sicheren Bereich“ hinter der Box oder dem Modem befinden, also hinter der Firewall. durch Fernzugriff könnten so auch Daten auf bestimmten Kundengeräten, auf die der Netzbetreiber Zugriff hat, geändert oder gelöscht werden. Durch sein Funktionsprinzip stellt TR-069 daher eine Backdoor dar, deren Existenz vielen Endkunden nicht bekannt ist und über deren Möglichkeiten sie sich nicht bewusst sind.


In welcher Ebene ist die TR-069 bzw. TR-064 Funktion einzuordnen?


Edit:

@Erforderlich
WOLAgent:
WolCmd:

Die Lösungen sind beide aus ca. 2020.
Gibt es da nicht Sicherheitsprobleme?
 
Zuletzt bearbeitet:
Nun gut, das ist ja schon mal KEIN Timeout mehr. Nur stimmt jetzt eben der Pfad in der aufgerufenen URL NICHT, denn da fehlt jetzt das tr064 - somit ist die Reaktion der Box ("page not found") absolut plausibel.

Das stimmt natürlich - ärgerlich dass ich das übersehen habe....

Ich habe die betreffende Zeile nun korrigiert (Rest unverändert):

Code:
$response = [xml]$WebClient.UploadString("https://" + "???.myfritz.net" + ":" + "44097" + "/tr064/upnp/control/hosts", $xml_query)

aber dann kommt wieder der Timeout.... habe ich den Syntax der Powershellscrips nicht durchblickt und es falsch gemacht?

Code:
Ausnahme beim Aufrufen von "UploadString" mit 2 Argument(en):  "Timeout für Vorgang überschritten"
In C:\Temp\Rechner wecken.ps1:30 Zeichen:1
+ $response = [xml]$WebClient.UploadString("https://" + "???? ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : WebException

Immerhin ist es eine FullyQualifiedErrorID... das muss doch helfen... ;)

Ich könnte mir noch vorstellen dass ich bei der xml_query-Zeile mit der MAC unqualifizierterweise einen Syntaxfehler eingebaut hatte daher nun die nochmal hier ohne Verschleierung....

Code:
$xml_query='<?xml version="1.0"?><s:Envelope xmlns:s="http:#schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http:#schemas.xmlsoap.org/soap/encoding/"><s:Body><u:X_AVM-DE_WakeOnLANByMACAddress xmlns:u="urn:dslforum-org:service:Hosts:1"><NewMACAddress>' + "90:1B:0E:59:9A:CD" + '</NewMACAddress></u:X_AVM-DE_WakeOnLANByMACAddress></s:Body></s:Envelope>'
 
Zuletzt bearbeitet:
Ich werde bei Gelegenheit (aber nicht vor dem Wochenende) mal selbst testen, ob bei der 08.03 die Funktion von intern und extern noch so arbeitet, wie von AVM dokumentiert - allerdings habe ich keine 7590 (mehr) und auch kein anderes GRX-basiertes Modell, wofür es eine 08.03 gäbe.

Allerdings könntest Du auch selbst testen (mit anderen TR-064-Funktionen), ob es da doch ein grundlegenderes Problem gibt - es sollten ja viele andere Aufrufe noch zum Test verfügbar sein (außer das Auslesen der Konfigurationsdatei), z.B. GetDeviceLog.

Denn auch die Frage, ob der Aufruf überhaupt bei der Box ankommt oder nicht, ist ja weiterhin offen - wie schon zuvor geschrieben, kann man ja auch mal einen Aufruf mit absichtlich ungültigen Credentials starten und schauen, ob man dabei einen Authentifizierungsfehler kriegt oder weiterhin ein Timeout. Bisher ist ja nur klar, daß der Download der SD funktioniert hat - dazu braucht(e) es noch keine Anmeldung.

Ebenso kann (nein: sollte) man das Ganze mal von der LAN-Seite testen … worin der einzige (notwendige) Unterschied zwischen LAN und WAN läge, habe ich schon geschrieben. Wenn es auch aus dem LAN nicht klappt, braucht man nicht nach Ursachen zu suchen, die nur beim Zugriff aus dem WAN infrage kommen. Und wie schon mehrfach in anderen Threads festgestellt - AVM baut auch immer wieder Fehler in seine TR-064-Implementierung (und auch nicht nur dort) ein … es KANN also auch sein, daß es nur mit anderen Versionen funktioniert(e).

EDIT: Und ganz nebenbei - meines Wissens werden inzwischen auch TR-064-Requests von AVM in einem Ringbuffer protokolliert; es könnte also einen Versuch wert sein, mal in die Support-Datei zu schauen, ob darin nicht auch dieser Ringbuffer angezeigt wird (nicht alles, was intern protokolliert wird, wird auch in die Support-Datei übernommen).
 
Zuletzt bearbeitet:
Danke dafür! Ich habe drei Sachen eben nochmal getestet:

1. Abruf der Description (dafür muss ich aber meine Credentials korrekt angeben!) - klappt
2. Log der entfernten Box überprüft: das Abrufen der Description wird der als Zugriff einer "App" korrekt geloggt.
3. Script mit ungültigem Passwort losgeschickt: Timeout-Meldung siehe oben.

von meinen anderen Zugriffsversuchen mit dem Script ist kein Eintrag im Log zu finden obwohl ich vermute die sollten wenn alles richtig gelaufen ist auch als "App" Zugriff erscheinen. Das Problem muss vor dem erfolgreichen Einloggen liegen.

Die Zusammenstellung des querystrings der dann an die /tr064/upnp/control/hosts/ Funktion übergeben wird ist für mich allerdings extremst undurchsichtig - ich habe wirklich gar keine Ahnung was da genau passiert und was schließlich an die FB geschickt wird und wie das dort verarbeitet wird. Ohne profunde Programmierkenntnisse scheint es hoffnungslos da irgendwas zusammenzuspaxen...
 
Zuletzt bearbeitet:
Nochmal von mir der Hinweis - derselbe Vorgang ließe sich auch von der LAN-Seite testen, womit man erstens sicher geht, daß die Parameter passen und zweitens sowohl die Protokollierung zu sehen sein sollte, als auch geprüft werden kann, ob das Aufwecken per TR-064 überhaupt (wie dokumentiert) funktioniert in dieser Version. Das Event-Log ist auch etwas anderes als die Support-Datei - wenn im Event-Log jeder einzelne Zugriff protokolliert würde, würde das sehr schnell sehr unübersichtlich.

Ich würde an Deiner Stelle (vorerst) auf jede Änderung am Skript verzichten(!) und zunächst mal von intern mit den richtigen Parametern bei Aufruf feststellen, daß es (a) klappt und wie genau (b) die Parameter (bei Dir) aussehen müssen. DANACH kann man dann weiter versuchen, über die WAN-Seite auf die TR-064-Funktionen zuzugreifen - die einzige erforderliche Änderung (jenseits der anderen Adresse und der anderen Portnummer) wäre dann der Zusatz im Pfad. Damit sollten dann auch keine Zweifel mehr bestehen, ob deine Änderungen am Skript ein Problem darstellen - weil es außer dem geänderten Pfad gar keine gäbe.
 
Das kann ich erst am Wochenende machen wenn ich wieder dort bin. Muss dann meinen Laptop mitnehmen da es aktuell nur diesen einen (Aufzuweckenden Rechner dort gibt). Damit ich das auch ganz sicher richtig verstanden habe (bin nicht regelmäßig vor Ort daher sollte es dann stimmen...):

Ich kann genau mein jetziges Script nehmen und im LAN verwenden. Einzige Änderung:

Code:
$response = [xml]$WebClient.UploadString("https://" + "???.myfritz.net" + ":" + "44097" + "/tr064/upnp/control/hosts", $xml_query)

würde zu

Code:
$response = [xml]$WebClient.UploadString("https://" + 192.168.178.1" + ":" + "49443" + "/upnp/control/hosts", $xml_query)

Also "/tr064" entfernt und LAN-IP der FB als Zieladresse und der Standard TR064 Port wie im Script oben im Kommentar ausgeführt....
 
WOLAgent:
WolCmd:

Die Lösungen sind beide aus ca. 2020.
Gibt es da nicht Sicherheitsprobleme?
WolCmd ist sogar von 2005. Angst, Panik?
Bei WOLAgent kannst du selbst die Sourcen (von 2019) ausführlich durchforsten. Und es steht dir völlig frei, die eigentlich minimalen Funktionsumfänge von WOLAgent und WolCmd mit z.B. Powershell nachzubauen. Ich hatte damals genug zu tun, einen Batch für WolCmd zu bauen, der für's Homeoffice einen gut funktionierenden Ersatz für das zu der Zeit extrem dysfunktioniale AnyDesk-WOL darstellen konnte.

DANACH kann man dann weiter versuchen, über die WAN-Seite auf die TR-064-Funktionen zuzugreifen
Gute Strategie!
Dafür war eigentlich auch meine ps1-Version gedacht, wo man alles schon mal nicht jedes Mal irgendwas eintippen muss und auf LAN-Seite und über VPN funktioniert, wenn der User einfach nur angelegt worden ist. Soeben noch mal über VPN erfolgreich getestet und zwar mit einem User, der keinerlei (administrative) Berechtigungen benötigt (mit Fritzbox 5590, FRITZ!OS: 8.02).
Wie genau soll eigentlich der WAN-seitige Zugriff auf TR-064 erfolgen? Unter Diagnose / Sicherheit sind standardmäßig keine offenen Ports dafür zu sehen und sollten auch nicht.

Ansonsten kann man auch ein Browser-Lesezeichen wie https://sub.dyn-irgendwas.de:55555/#/network/device/115/lan anlegen.
Beim ersten Klick kommt die Anmeldung/Strartseite und beim zweiten landet man auf der Seite mit der WOL-Funktion. Mache ich seit längerer Zeit mit /#uleoverview.
 
Zuletzt bearbeitet:
Ansonsten kann man auch ein Browser-Lesezeichen wie https://sub.dyn-irgendwas.de:55555/#/network/device/115/lan anlegen.
Beim ersten Klick kommt die Anmeldung/Strartseite und beim zweiten landet man auf der Seite mit der WOL-Funktion. Mache ich seit längerer Zeit mit /#uleoverview.
Das wollte ich anfangs auch machen. Klappt aber bei mir nicht. Bei Aufruf von "https://???.myfritz.net:44097/#/network/device/1553417/lan" lande ich nach Eingabe des Passwortes stets auf der Anfangs-Übersichtsseite.... :(
 
daher sollte es dann stimmen
Das ist zwar nicht das, was ich meinerseits geschrieben (oder auch nur angedacht) habe, aber auch das wäre ja eine Möglichkeit, sofern Deine Änderungen am Skript ansonsten passen - nur war das ja bisher nicht sicher.

Ich schrieb eigentlich davon, daß man das erst mal mit dem originalen Skript unter Angabe der richtigen Parameter testen sollte. Außerdem kann man das prinzipielle Funktionieren ja auch testen, ohne daß dafür der Rechner tatsächlich geweckt werden oder man dorthin fahren muß - man kann also eben so gut auch diesen Rechner aus der Ferne für "erste Tests" benutzen, zumal ja wohl der Zugriff über RDP möglich wäre. Wenn der Aufruf erst mal fehlerfrei durchläuft, kann man das am Wochenende immer noch so testen, daß dann tatsächlich der PC gestartet wird; sofern man bis dahin nicht schon deutlich weiter ist.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Wie genau soll eigentlich der WAN-seitige Zugriff auf TR-064 erfolgen?
Das erfordert die Freigabe für das GUI auf der WAN-Seite.

EDIT: Tatsächlich ist bei AVM auch dokumentiert, daß für das Aufwecken per TR-064 KEINE Admin-Rechte (mehr?) erforderlich sind: https://fritz.com/fileadmin/user_upload/Global/Service/Schnittstellen/AVM_TR-064_first_steps.pdf, Seite 18
 
Zuletzt bearbeitet von einem Moderator:
So ich habe nun mal folgendes Script lokal laufen lassen und damit erfolgreich den Rechner aufgeweckt:

Code:
# SPDX-License-Identifier: GPL-2.0-or-later
###################################################################################
#                                                                                 #
# Wake-on-LAN for a known device via TR-064 function from FRITZ!OS                #
#                                                                                 #
###################################################################################
#                                                                                 #
# You need the MAC address of a LAN device, which must be known to your FRITZ!OS- #
# based router, and an user account with administrative rights, to wake up a LAN  #
# client from sleeping, using this script.                                        #
#                                                                                 #
###################################################################################
Param([Parameter(Mandatory = $False, Position = 0, HelpMessage = 'the username to login to TR-064')][string]$Username,
      [Parameter(Mandatory = $True, Position = 1, HelpMessage = 'the password to login to TR-064')][string]$Password,
      [Parameter(Mandatory = $False, Position = 2, HelpMessage = 'the MAC address of device to wake up')][string]$MAC,
      [Parameter(Mandatory = $False, Position = 3, HelpMessage = 'the internal TR-064 (TLS protected) port, defaults to 49443')][string]$Port = 49443,
      [Parameter(Mandatory = $False, Position = 4, HelpMessage = 'the IP address of the FRITZ!Box, defaults to 192.168.178.1')][string]$Address = "192.168.178.1")

$WebClient = New-Object System.Net.WebClient
$xml_query='<?xml version="1.0"?><s:Envelope xmlns:s="http:#schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http:#schemas.xmlsoap.org/soap/encoding/"><s:Body><u:X_AVM-DE_WakeOnLANByMACAddress xmlns:u="urn:dslforum-org:service:Hosts:1"><NewMACAddress>' + "???????????" + '</NewMACAddress></u:X_AVM-DE_WakeOnLANByMACAddress></s:Body></s:Envelope>'

$WebClient.Encoding = [System.Text.Encoding]::UTF8
$WebClient.Credentials = New-Object System.Net.NetworkCredential("?????", $Password)
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:Hosts:1#X_AVM-DE_WakeOnLANByMACAddress')
$response = [xml]$WebClient.UploadString("https://" + "192.168.178.1" + ":" + "49443" + "/upnp/control/hosts", $xml_query)

$response.Envelope.Body.InnerXml

Also prinzipiell sollte das funktionieren. Ich habe mein Script genommen das vorher vom WAN aus trotz der Anpassungen (unterste Zeile) nicht richtig funktioniert hatte.... Ich muss also trotz allem (s.o.) einen Fehler bei der Anpassung des Scripts eingebaut haben... nur wo??

die entscheidende letzte Zeile für vom WAN aus war bei mir vorher

Code:
$response = [xml]$WebClient.UploadString("https://" + "???????.myfritz.net" + ":" + "44097" + "/tr064/upnp/control/hosts", $xml_query)
 
Zuletzt bearbeitet:
$response = [xml]$WebClient.UploadString("https://" + "https://???????.myfritz.net" + ":" + "44097" + "/tr064/upnp/control/hosts", $xml_query)
Da taucht doch in der Anweisung zweimal der Teil-String "https://" auf. Das ist doch wohl einer zu viel?
 
Das stimmt! Ist aber ein dummer "copy paste Fehler" meinerseits hier im Forumeditor gewesen den ich eben korrigiert habe (sorry). In meinem richtigen Script habe ich das korrekt. Daran liegt es also leider nicht...
 
Zuletzt bearbeitet:
Hat vielleicht jemand sonst die TR064 WoL Funktion erfolgreich über WAN getestet? Dann wüsste ich das es irgendwie an meinem Setup liegt...
 
Kostenlos!

Neueste Beiträge

Statistik des Forums

Themen
248,873
Beiträge
2,303,516
Mitglieder
378,533
Neuestes Mitglied
PatrickSt91