RouterControl für D-Link DSL-G664T
Anbei eine neue RouterControl.exe, diese führt das HTTP-POST jetzt so aus, wie es der Internet Explorer tut. Probiert mal ob es damit besser läuft.
Download wieder gelöscht, neuere Version in anderem Beitrag.
Download wieder gelöscht, neuere Version in anderem Beitrag.
Zuletzt geändert von mirko am 25.01.2005, 00:56, insgesamt 2-mal geändert.
Ja, ich glaube genau das ist der Knackpunkt. Beispiel: Die 4 folgenden Eingaben in die Adresszeile des Browsers - ich habe den Aufruf der HTML-Seite (getpage=) absichtlich ans Ende der Zeile gesetzt und einmal die deutsche und einmal die englische Seite aufgerufen:Original von shuvuu:
Und wahrscheinlich kommen die Login Daten per GET (aus dem Browser) nicht dort an, wo sie vom CGI zur Weiterverarbeitung erwartet werden.
http://<Router>/cgi-bin/webcm?var:language=gm&getpage=../html/status_gm/connstatus.htm
http://<Router>/cgi-bin/webcm?var:language=en&getpage=../html/status_en/connstatus.htm
http://<Router>/cgi-bin/webcm?var:language=gm&login:command/username=admin&login:command/password=MeinPassword&getpage=../html/status_gm/connstatus.htm
Die 4 Aufrufe funktionieren, wenn man schon eingeloggt ist.http://<Router>/cgi-bin/webcm?var:language=en&login:command/username=admin&login:command/password=MeinPassword&getpage=../html/status_en/connstatus.htm
Die 4 Aufrufe funktionieren nicht, wenn man nicht eingeloogt ist.
Das scheint genau deine Aussage zu untermaueren, daß \"die Login Daten per GET (aus dem Browser) nicht dort ankommen, wo sie vom CGI zur Weiterverarbeitung erwartet werden\". Es scheint sich also wirklich nur auf die Login-Daten und nur auf GET zu beziehen. Denn:
a) per POST aus einer HTML-Datei werden die Login-Daten akzeptiert
b) die anderen Daten \"getpage=\" und \"var:language=\" werden auch per GET akzeptiert
Hallo CSS,
Mirko hat eigentlich schon auf deine Frage wieso geht es mit POST aus dem Formular aber nicht aus der Browser Adresseingabe geantwortet. Aus der Browser Adresseingabe können Daten nur per GET übergeben werden. Die anderen Übergaben mit getpage=..\\html\\.... werden auch per GET übergeben, deshalb geht das im Browser.
Ich habe in SelfHTML und ein paar Büchern zum Thema GET und POST bei CGI\'s gelesen. Was ich verstanden habe, wird dabei aus unterschiedlichen Übergabebereichen die Daten vom CGI ausgelesen werden. Und wahrscheinlich kommen die Login Daten per GET (aus dem Browser) nicht dort an, wo sie vom CGI zur Weiterverarbeitung erwartet werden.
Mirko hat eigentlich schon auf deine Frage wieso geht es mit POST aus dem Formular aber nicht aus der Browser Adresseingabe geantwortet. Aus der Browser Adresseingabe können Daten nur per GET übergeben werden. Die anderen Übergaben mit getpage=..\\html\\.... werden auch per GET übergeben, deshalb geht das im Browser.
Ich habe in SelfHTML und ein paar Büchern zum Thema GET und POST bei CGI\'s gelesen. Was ich verstanden habe, wird dabei aus unterschiedlichen Übergabebereichen die Daten vom CGI ausgelesen werden. Und wahrscheinlich kommen die Login Daten per GET (aus dem Browser) nicht dort an, wo sie vom CGI zur Weiterverarbeitung erwartet werden.
Hallo,
aus den \"gesnifften\" Daten kann man erkennen, dass der Router anscheinend nicht mit den Daten zurecht kommt, die per POST übermittelt werden. Ich werde es mal auf ein \"einfaches\" POST ändern.
Der Hersteller des Routers bzw. der Support weiß auch nicht wie das geht. Der Support ist nur zur Lösung einfacher User-Anfragen gedacht, die wissen ansonsten nichts. Man darf dem Support aber keinen Vorwurf machen, denn die bekommen auch keine Infos dazu.
Die Firmware eins Routers wird entweder extern eingekauft und an das Layout angepasst (sind alles die gleichen Chips in den Routern) oder eine Entwicklungsabteilung irgendwo in China, Taiwan usw. entwickelt diese für alle Router des Unternehmens. Bei D-Link denke ich mal wird dies in einer eigenen Entwicklungabteilung gemacht, das stand mal vor Monaten (oder Jahren) irgendwo im D-Link Forum, also ich nach einer Problemlösung für meinen alten D-Link-Router gesucht habe.
aus den \"gesnifften\" Daten kann man erkennen, dass der Router anscheinend nicht mit den Daten zurecht kommt, die per POST übermittelt werden. Ich werde es mal auf ein \"einfaches\" POST ändern.
Der Hersteller des Routers bzw. der Support weiß auch nicht wie das geht. Der Support ist nur zur Lösung einfacher User-Anfragen gedacht, die wissen ansonsten nichts. Man darf dem Support aber keinen Vorwurf machen, denn die bekommen auch keine Infos dazu.
Die Firmware eins Routers wird entweder extern eingekauft und an das Layout angepasst (sind alles die gleichen Chips in den Routern) oder eine Entwicklungsabteilung irgendwo in China, Taiwan usw. entwickelt diese für alle Router des Unternehmens. Bei D-Link denke ich mal wird dies in einer eigenen Entwicklungabteilung gemacht, das stand mal vor Monaten (oder Jahren) irgendwo im D-Link Forum, also ich nach einer Problemlösung für meinen alten D-Link-Router gesucht habe.
Obwohl ich zu bedenken gebe: Wenn ich die folgende HTML-Datei von meiner Festplatte starte, dann funktioniert der Login und es wird gleich die Staus-Seite des Routers angezeigt:Original von shuvuu:
ich habe gesnifft und habe doch einige Unterschiede zwischen dem, was CSS Login Script bzw, das Login vom Router übertragen und dem was RoterControl überträgt festgestellt.
Wenn ich hingegen die folgende Zeile in die Adress-Zeile meines Browsers eingebe, dann sollte eigentlich das gleiche rauskommen - tut es aber nicht: Damit ist ein Login nicht möglich.<html>
<head>
</head>
<body>
<form>
<input>
<input>
<input>
<input>
</form>
</body>
</html>
Vielleicht solltest du mal den Unterschied zwischen diesen beiden Varianten heraussniffen. Denn unter Umständen macht RouterControl lediglich genau das gleiche wie die Eingabe per Browser-Adresszeile.http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm&var:language=gm&login:command/username=admin&login:command/password=meinPasswort
Anmerkung: Ich habe die gleiche Frage (\"Was ist der Unterschied zwischen der HTML-Datei und der Eingabe in die Adresszeile des Browsers\") an den D-Link-Support gestellt.
Antwort vom D-Link-Support (sinngemäß):
\"Wir denken, das ist ein Problem mit einem Cookie, das nicht gesetzt werden kann oder etwas ähnlichem. Entschuldigung, aber wir können ihnen keine Lösung für ihr Problem liefern.\"
Ich habe ihnen dann geschrieben, daß es in meinem Fall nicht an den Cookies liegen kann und daß ich eine Aussage wie: \"… oder etwas ähnlichem\" für sehr Wischiwaschi halte. Und ich habe sie gefragt, ob ich ihre Aussage in diversen Foren und Newsgroups zitieren könnte, weil ich meine, daß es bestimmt für viele Anwender interessant ist zu erfahren, daß nicht einmal der Hersteller eine Lösung für dieses Problem kennt. Bisher noch keine Antwort.
Zuletzt geändert von CCS am 22.01.2005, 08:28, insgesamt 1-mal geändert.
Hallo Mirko, CSS
ich habe gesnifft und habe doch einige Unterschiede zwischen dem, was CSS Login Script bzw, das Login vom Router übertragen und dem was RoterControl überträgt festgestellt.
Ich werde das mal an Mirko per Mail schicken. Was ich auch bemerkt habe, ist, das bei gewissen Einträgen in der RC Router Datei für das Login per HTML, nichts geschickt wird. Es kommt dann gleich die Seite, die ich als Statusseite bzw. IP Abfrage eingetragen habe.
Mfg.
ich habe gesnifft und habe doch einige Unterschiede zwischen dem, was CSS Login Script bzw, das Login vom Router übertragen und dem was RoterControl überträgt festgestellt.
Ich werde das mal an Mirko per Mail schicken. Was ich auch bemerkt habe, ist, das bei gewissen Einträgen in der RC Router Datei für das Login per HTML, nichts geschickt wird. Es kommt dann gleich die Seite, die ich als Statusseite bzw. IP Abfrage eingetragen habe.
Mfg.
Ja, aber es war eine 0815 Antwort. Ich hatte zwischenzeitlich gesehen, daß der Status meiner Support-Anfrage auf \"Weitergeleitet\" stand. Scheinbar hat D-Link Seutschland keine Antwort finden können und sie haben es nach Taiwan weitergeleitet. Dort konnten sie mit meiner deutschen Frage wohl nichts anfangen und so erhielt ich diese deutsch-englische Antwort:Original von shuvuu:
CSS: Hat sich eigentlich D-Link gemeldet ?
Your Request has been answerd as follows:
Wir haben hierfür leider keine weiterführenden Informationen, Sie können sich aber denGPL Sourcecode von ftp.dlink.de laden.
We hope that this answers your question and that your request is now resolved.
Regards - your D-Link Support Team
P.S. If you have further questions regarding this request, please reply to this eMail without modifying the subject text.
Hier mal meine Zusammenfassung:
Ausgehend von dieser HTML-Datei – mit dieser Datei kann ich mich beim Router einloggen:
a) die Reihenfolge der Variablen verändern
b) zusätzliche Variablen einfügen
c) aber: Die Variablen-Namen NICHT verändern
Was passiert hier (teilweise Vermutung):
1. es wird das CGI-Programm \"webcm\" aufgerufen (action=\"http://<Router>/cgi-bin/webcm\")
2. An das CGI-Programm \"webcm\" wird ein Feld mit Variablen übergeben
3. Das CGI-Programm \"webcm\" untersucht die übergebenen Variablen:
a) Wird mit der Variablen \"getpage\" eine \"interne\" Seite aufgerufen, die ein Login voraussetzt ? (Wenn nein, z.b. index.html, dann zeige die entsprechende Seite.)
b) Wenn ja, ist der User schon eingeloggt ? (Wenn ja, dann zeige die entsprechende Seite)
c) Wenn nein, untersuche ob die Variablen \"login:command/username\" und \"login:command/password\" mit richtigen Werten zum Login übergeben wurden. (Wenn nein, dann zeige index.html)
d) Wenn ja, dann zeige die mit \"getpage\" angeforderte Seite.
Man kann somit auch die obige HTML-Datei so schreiben:
Wenn man nun im Web-Browser diese Zeile angibt, dann funktioniert die Anzeige ebenfalls - wenn man eingeloggt ist:
Nun zum Aufruf im Web-Browser MIT Login-Variablen :
Wenn man schon eingeloggt ist, dann funktionieren die folgenden Aufrufe im Web-Browser:
Also bisher dachte ich, daß irgendwie die Sonderzeichen \"/\" oder \":\" stören würden – aber das kann es nicht sein. Denn zum einen wird die Variable \"var:language=gm\" richtig erkannt (die enthält ja auch den \":\") und zum anderen enthält ja auch die Variable \"getpage=../html/status_gm/connstatus.htm\" drei \"/\" – wenn auch nicht im Variablen-Namen. Aber selbst wenn man den Aufruf absichtlich falsch schreibt, wird die Variable \"var:language=gm\" am Ende noch richtig erkannt:
Ausgehend von dieser HTML-Datei – mit dieser Datei kann ich mich beim Router einloggen:
In dieser HTML-Datei darf ich<html>
<head>
</head>
<body>
<form>
<input>
<input>
<input>
</form>
</body>
</html>
a) die Reihenfolge der Variablen verändern
b) zusätzliche Variablen einfügen
c) aber: Die Variablen-Namen NICHT verändern
Was passiert hier (teilweise Vermutung):
1. es wird das CGI-Programm \"webcm\" aufgerufen (action=\"http://<Router>/cgi-bin/webcm\")
2. An das CGI-Programm \"webcm\" wird ein Feld mit Variablen übergeben
3. Das CGI-Programm \"webcm\" untersucht die übergebenen Variablen:
a) Wird mit der Variablen \"getpage\" eine \"interne\" Seite aufgerufen, die ein Login voraussetzt ? (Wenn nein, z.b. index.html, dann zeige die entsprechende Seite.)
b) Wenn ja, ist der User schon eingeloggt ? (Wenn ja, dann zeige die entsprechende Seite)
c) Wenn nein, untersuche ob die Variablen \"login:command/username\" und \"login:command/password\" mit richtigen Werten zum Login übergeben wurden. (Wenn nein, dann zeige index.html)
d) Wenn ja, dann zeige die mit \"getpage\" angeforderte Seite.
Man kann somit auch die obige HTML-Datei so schreiben:
Hier wird dann nicht mehr die \"Home\"-Seite aufgerufen (\"home_gm.htm\") sondern gleich die Status-Seite (\"html/status_gm/connstatus.htm\") angefordert. In diesem Falle muß man aber auch noch die Variable name=\"var:language\" value=\"gm\" mit übergeben.<html>
<head>
</head>
<body>
<form>
<input>
<input>
<input>
<input>
</form>
</body>
</html>
Wenn man nun im Web-Browser diese Zeile angibt, dann funktioniert die Anzeige ebenfalls - wenn man eingeloggt ist:
Ohne die Variable var:language=gm sieht man hingegen nur eine weiße Seite:http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm&var:language=gm
Und mit dem folgenden kann man die entsprechende englische Seite aufrufen:http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm
Das interpretiere ich so, daß das CGI-Programm \"webcm\" sehrwohl die Variable var:language=gm oder var:language=en auswertet.http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm&var:language=en
Nun zum Aufruf im Web-Browser MIT Login-Variablen :
Wenn man schon eingeloggt ist, dann funktionieren die folgenden Aufrufe im Web-Browser:
oder:http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm&var:language=gm&login:command/username=admin&login:command/password=meinPasswort
Es ist also egal WO die Variable \"var:language=gm\" steht (am Anfang, oder am Ende). Und OHNE \"var:language=gm\" wird wiederum nur eine weiße Seite ausgegeben; bzw. mit \"var:language=en\" wird die englische Seite ausgegeben.http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm&login:command/username=admin&login:command/password= meinPasswort&var:language=gm
Also bisher dachte ich, daß irgendwie die Sonderzeichen \"/\" oder \":\" stören würden – aber das kann es nicht sein. Denn zum einen wird die Variable \"var:language=gm\" richtig erkannt (die enthält ja auch den \":\") und zum anderen enthält ja auch die Variable \"getpage=../html/status_gm/connstatus.htm\" drei \"/\" – wenn auch nicht im Variablen-Namen. Aber selbst wenn man den Aufruf absichtlich falsch schreibt, wird die Variable \"var:language=gm\" am Ende noch richtig erkannt:
Also ich weiß jetzt auch nicht weiter. Was macht meine Anfangs beschriebene HTML-Datei anders, wie diese Zeile im Web-Browser (die Variablen-Namen sind doch die gleichen) ?http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm&login:com/mand/user/name=admin&login:com:mand:pass:word=meinPasswort&var:language=gm
http://<Router>/cgi-bin/webcm?getpage=../html/status_gm/connstatus.htm&login:command/username=admin&login:command/password= meinPasswort&var:language=gm
Hallo,
ich erlaube mit, die Antwort von Mirko auf meine Anfrage zum Packet Treiber per PM zu veröffentlichen. Eigentlich sollte diese Frage ins Board:
ja natürlich kann man das aber die filter dürfen halt nicjt gesetzt sein.
+++ Original Nachricht von shuvuu, 10.01.05 19:41 +++
+++ Betreff: +++
Leider erst wieder am Wochenende. Kann ich damit auch die Pakete und im TrafficMonitor sehensniffen, die beim Login des Routers im Web Interface gesendet werden ?
Vielleicht hat CSS vorher Zeit oder Lust zu \"sniffen\".
ich erlaube mit, die Antwort von Mirko auf meine Anfrage zum Packet Treiber per PM zu veröffentlichen. Eigentlich sollte diese Frage ins Board:
ja natürlich kann man das aber die filter dürfen halt nicjt gesetzt sein.
+++ Original Nachricht von shuvuu, 10.01.05 19:41 +++
+++ Betreff: +++
Leider erst wieder am Wochenende. Kann ich damit auch die Pakete und im TrafficMonitor sehensniffen, die beim Login des Routers im Web Interface gesendet werden ?
Vielleicht hat CSS vorher Zeit oder Lust zu \"sniffen\".
Um festzustellen, ob es richtig übergeben wird, müsste man die Netzwerkpakete sniffen. Wenn einer von euch beiden TrafficMonitor mit Packet-Treiber nutzt, dann kann man das mit TrafficMonitor, dazu müssen aber alle gesetzten Filter entfernt werden, sonst werden diese Pakete weggefiltert und damit nicht aufgezeichnet.
Hallo Mirko, hallo CSS,
ich möchte mal zwei Dinge zur Diskussion stellen:
1. CSS hat für das LOGIN eine kleine HTML Seite mit dem Kernformular gebastelt und es tut. Er hat es auch schon implizit gefragt:
Kann es sein, dass RouterControl sich bei der Übergabe von \"login:command/username\" und \"login:command/password\" als Parameter an das CGI, was ja im HTML funktioniert, an den \":\" und \"/\" stört und diese nicht verarbeitet ? \"Leider\" sieht man das LOGIN nicht im DEBUG Fenster.
2. die login_gm.html hat zwei Formulare:
a) das Kernformular mit der Übergabe an das CGI Script --> die Übergabe funktioniert ja nicht (oder doch, denn es wird die HTML Seite zurückgegeben, die bei fehlerhafter Eingabe zurückkommt.)
b) das zweite Formular, welches die eigentliche Eingabe von Name und Passwort abfragt und zur Verfügung stelltund per DoLogin() an das Kernformular übergeben wird. Abgeschickt wird es mit Klick auf den Login Button oder durch ENTER. Kann man nicht diese Seite benutzen, um Name und Passwort zu übergeben? (Beim bisherigen probieren ging es auch nicht .) Die Namen der Inputs haben auch keinen \":\" oder \"/\".
CSS: Hat sich eigentlich D-Link gemeldet ?
ich möchte mal zwei Dinge zur Diskussion stellen:
1. CSS hat für das LOGIN eine kleine HTML Seite mit dem Kernformular gebastelt und es tut. Er hat es auch schon implizit gefragt:
Kann es sein, dass RouterControl sich bei der Übergabe von \"login:command/username\" und \"login:command/password\" als Parameter an das CGI, was ja im HTML funktioniert, an den \":\" und \"/\" stört und diese nicht verarbeitet ? \"Leider\" sieht man das LOGIN nicht im DEBUG Fenster.
2. die login_gm.html hat zwei Formulare:
a) das Kernformular mit der Übergabe an das CGI Script --> die Übergabe funktioniert ja nicht (oder doch, denn es wird die HTML Seite zurückgegeben, die bei fehlerhafter Eingabe zurückkommt.)
b) das zweite Formular, welches die eigentliche Eingabe von Name und Passwort abfragt und zur Verfügung stelltund per DoLogin() an das Kernformular übergeben wird. Abgeschickt wird es mit Klick auf den Login Button oder durch ENTER. Kann man nicht diese Seite benutzen, um Name und Passwort zu übergeben? (Beim bisherigen probieren ging es auch nicht .) Die Namen der Inputs haben auch keinen \":\" oder \"/\".
CSS: Hat sich eigentlich D-Link gemeldet ?
Hallo Mirko,
bei meinem Router besteht ja immer noch das Problem, daß RouterControl sich nicht selbständig beim Router anmelden kann. Der Anmeldestring müßte eigentlich so aussehen:
Die folgende selbsterstellte HTML-Seite funktioniert hingegen von meiner Festplatte:
Ich könnte nun für das Login diese HTML-Seite von meiner Festplatte aus starten – die restlichen \"Status\"-Seiten müßten dann aber mit den aktuellen Daten direkt vom Router geliefert werden. Nun wäre es schön, wenn RouterControl das selbst machen könnte. Das geht aber nicht, weil ich in RouterControl die IP-Adresse des Routers eingeben muß und RouterControl daraus den folgenden String generiert:
Zwei Vorschläge / Anregungen von mir:
1. Zusätzliche Option in RouterControl, die IP NICHT automatisch von RouterControl einzufügen. Ich müßte dann mit RCEdit die entsprechenden Felder mit kompletter Pfadangabe eingeben. Nachteil: JEDER Anwender, der diese Option nutzt, müßte mit RCEdit die Pfadangaben an seinem Router anpassen.
2.Option für zusätzliche IP-Adressen oder Pfaden mit Variablen-Namen – die in RCEdit ähnlich %USERNAME% und %PASSWORD% verwendet werden können; z.B. %IP2%, %IP3%. Mit RCEdit könnte man dann die entsprechenden Felder selbst anpassen:
Ich hoffe, du verstehst wie ich das meine.
Vielleicht könnte man im Zuge solcher Veränderungen auch noch eine Checkbox in RouterControl einfügen mit der Option: \"Null-Bytes am Anfang einer HTML-Seite entfernen\" – dann wäre das leidige Problem mit den beiden unterschiedlichen Versionen auch erschlagen.
bei meinem Router besteht ja immer noch das Problem, daß RouterControl sich nicht selbständig beim Router anmelden kann. Der Anmeldestring müßte eigentlich so aussehen:
Scheinbar funktioniert die Übergabe der Variablen-Namen \"login:command/username\" und \"login:command/password\" nicht - vielleicht wegen der Sonderzeichen \":\" und \"/\" im Variablen-Namen.<POST>cgi-bin/webcm?getpage=../html/home_gm.htm&login:command/username=%USERNAME%&login:command/password=%PASSWORD%
Die folgende selbsterstellte HTML-Seite funktioniert hingegen von meiner Festplatte:
Hier werden die Variablen ja im \"Formular-Feld\" übergeben (onload=\"JavaScript:document.formLogin.submit()\"<html>
<head>
</head>
<body>
<form>
<input>
<input>
<input>
</form>
</body>
</html>
Ich könnte nun für das Login diese HTML-Seite von meiner Festplatte aus starten – die restlichen \"Status\"-Seiten müßten dann aber mit den aktuellen Daten direkt vom Router geliefert werden. Nun wäre es schön, wenn RouterControl das selbst machen könnte. Das geht aber nicht, weil ich in RouterControl die IP-Adresse des Routers eingeben muß und RouterControl daraus den folgenden String generiert:
Wenn ich die Router-IP in RouterControl leer lasse und stattdessen in RCEdit den kompletten HTML-Pfad in das Feld \"Anmeldung über HTML-Formular\" eintrage, dann funktioniert das leider auch nicht, weil RouterControl mir dann das folgende zusammen bastelt:http://<Router>/cgi-bin/webcm?getpage=../html/home_gm.htm&login:command/username=%USERNAME%&login:command/password=%PASSWORD%
RouterControl setzt mir dann also immer ein \"http:///\" mit leerer IP vor den eigentlichen Aufruf.http:///C:/mein_login.html
Zwei Vorschläge / Anregungen von mir:
1. Zusätzliche Option in RouterControl, die IP NICHT automatisch von RouterControl einzufügen. Ich müßte dann mit RCEdit die entsprechenden Felder mit kompletter Pfadangabe eingeben. Nachteil: JEDER Anwender, der diese Option nutzt, müßte mit RCEdit die Pfadangaben an seinem Router anpassen.
2.Option für zusätzliche IP-Adressen oder Pfaden mit Variablen-Namen – die in RCEdit ähnlich %USERNAME% und %PASSWORD% verwendet werden können; z.B. %IP2%, %IP3%. Mit RCEdit könnte man dann die entsprechenden Felder selbst anpassen:
Wenn %IP2% auf den Pfad auf meinem lokalen Rechner verweist, könnte dann die selbsterstellte Login-Seite gestartet werden.%IP2%mein_login.html
Ich hoffe, du verstehst wie ich das meine.
Vielleicht könnte man im Zuge solcher Veränderungen auch noch eine Checkbox in RouterControl einfügen mit der Option: \"Null-Bytes am Anfang einer HTML-Seite entfernen\" – dann wäre das leidige Problem mit den beiden unterschiedlichen Versionen auch erschlagen.
Jein. Zum einen ist es natürlich problematisch, wenn man ein komplettes Firmware-Update aus dubiosen Quellen einspielt. Da weiß man nie, ob nicht eine Hintertür eingebaut wurde oder einfach nur ein Fehler.Auf keinen Fall würde ich etwas eigenes in den Router einspielen. Für meinen Linksys-Router gibt es auch alternative Linux-Betriebssysteme aber ich würde es nicht einspielen, wer weiß was dann passiert.
Zum anderen: Wenn es vertrauenswürdige Quellen sind, dann könnte man es in Erwägung ziehen - aber vielleicht nicht als erster, sondern erst nach einer gewissen Zeit - wenn es andere über längere Zeit hin getestet haben.
In meinem oben beschriebenen Fall ist es ja nur eine kleine Zusatzmodifikation, wo ich die Auswirkungen selbst übersehen und einschätzen kann. Zudem wären nach einem Abschalten (Stromlos) alle Änderungen verworfen.
Hallo,
Das RCEdit ist noch nicht korrigiert, d.h. die 0 (Null) muss man im Texteditor von Hand enfternen und danach kann man die Testseiten im RCEdit ausprobieren. Nur die RouterControl.exe selbst ist modifiziert, so dass die 0 (Null) durch Leerzeichen ersetzt wird.ich habe auch obigen Router von D-Link angeschafft und bin zwecks Volumenüberwachung beim TrafficMonitor und RouterController gelandet. Wie CSS habe ich mit dem Login gekämpft und diesen Thread von ihm gefunden und den im D-Link Forum. Leider habe ich auch keine Lösung. Ich denke, dass man die login_gm.html benutzen sollte, es sei, denn man erfährt von D-Link, wie das CGI webcm funktioniert. An das login_gm.html muss ausser Name und Password noch ein ENTER übergeben werden, aber wie ?
Leider wird man nach einem Timeout wieder ausgeloggt, so dass es nicht genügt, sich einmal mit dem autostart von Windows anzumelden.
Wie sieht es eigentlich aus, wenn man das Login auf den Rechner verlegt und die Abfrage der Statusseiten ebenfalls über HTML Seiten auf dem Rechner macht ? So dass man die IP Adresse des Rechners vorgibt.
Ich hätte gern das rcedit, wie es CSS bekommen hat, um mir auch die Abfragen zusammenbasteln zu können.