Es ist doch ziemlich einfach, mit den TR-064-Funktionen (habe ich oben auch erwähnt, denke ich - oder es war doch in einem anderen Thread zu diesem Thema) sich selbst ein passendes Skript zu bauen ... die schwierigste Frage dabei ist es noch, was man als "Basis" dafür nimmt (welches OS, welche Sprache). HTML (oder eher ja JS) im Browser könnte etwas unhandlich werden, wobei auch hier die "Antwort" vielleicht nicht wirklich interessiert und man das damit sogar "blind" per XHR anstoßen könnte.
Die simpelste Form wäre z.B. das hier in PowerShell:
Code:
Param([Parameter(Mandatory = $True, 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 = $True, 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>' + $MAC + '</NewMACAddress></u:X_AVM-DE_WakeOnLANByMACAddress></s:Body></s:Envelope>'
$WebClient.Encoding = [System.Text.Encoding]::UTF8
$WebClient.Credentials = New-Object System.Net.NetworkCredential($Username, $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://" + $Address + ":" + $Port + "/upnp/control/hosts", $xml_query)
$response.Envelope.Body.InnerXml
Allerdings kann diese AVM-Funktion tatsächlich auch nur Geräte wecken, deren MAC-Adressen der FRITZ!Box bekannt sind - die Angabe irgendeiner unbekannten MAC-Adresse führt zu einem Fehler:
Code:
PS C:\Users\***********************************> .\WOL.ps1 user password 11:22:33:44:55:66
Exception calling "UploadString" with "2" argument(s): "The remote server returned an error: (500) Internal Server
Error."
At C:\Users\***********************************\WOL.ps1:17 char:1
+ $response = [xml]$WebClient.UploadString("https://" + $Address + ":" + $Port + " ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WebException
Man kann sich natürlich auch problemlos eine komfortablere Version bauen, die zuerst mal im Netzwerk bzw. auf der Box nachsieht, ob die FRITZ!Box den Namen kennt (dann braucht man die MAC-Adresse nicht anzugeben), welche MAC-Adresse der hat und ob der Client schon läuft (dann auf den TR-064-Aufruf verzichten), usw. ... bis hin zur "Anzeige", ob/wann der Client dann läuft und bereit ist (z.B. auf ICMP-Echo-Requests reagiert) - alles nur eine Frage der zu investierenden Zeit. Das geht aber dann sogar "von extern", denn die TR-064-Funktionen sind ja auch über den externen GUI-Port (mit TLS) erreichbar.
Ansonsten ist das "Durchschleusen" von Funktionen durch das VPN, die auf lokalen Broad- und Multicast-Paketen basieren, bei der von AVM verwendeten Form der Implementierung nicht so einfach (auch noch mit unterschiedlichen Effekten, je nachdem, ob man LAN-LAN-Kopplung betreibt oder ein einzelnes Gerät (wie ein Smartphone) extern einbindet) ... zwar mit viel Aufwand (über entsprechende Proxy-Services) nicht "unmachbar", aber eher in keinem vernünftigen Verhältnis zur Häufigkeit entsprechender "use cases" bei SOHO-Routern stehend (meine Meinung).
Ich rege mich ja auch nicht darüber auf, daß die Box die WOL-Pakete per L2-Broadcast verschickt und damit ohnehin am nächsten Router wieder Schluß ist - hier könnte man sogar "routbare" Pakete verwenden, allerdings müßte dann der letzte Hop eben auch wieder irgendeine L3-Adresse in die passende MAC auf L2 für das "echte Paket" übersetzen können - sonst muß es doch wieder ein BC sein.
Jedenfalls kostet es vielleicht 10 Minuten, sich irgendwo einen passenden Icon auf den Desktop zu zaubern (egal ob der unter Linux, MacOS oder Windows arbeitet - das o.a.Tool braucht m.W. ja Windows), der bei (Doppel-)Klick direkt einen anderen LAN-Client startet - die dazu notwendigen Funktionen sind vorhanden (das AVM-GUI macht auch wenig anderes, außer daß das eben direkt mit den entsprechenden Komponenten kommuniziert und nicht über TR-064).
Selbst wenn AVM das "WakeonLANByMACAddress" wohl problemlos auch so hätte umsetzen können, daß man zusätzlich "unbekannte" MAC-Adressen wecken kann ... andererseits ist es so auch wieder sicherer, weil ein Parameter mehr gründlich geprüft wird (was eigentlich nie schaden kann) und ein "Seitenkanal" weniger vorhanden ist, über den man Informationen senden oder auslesen kann.
